Re: lug-bg: c/cpp incr/decr

[George Danchev <danchev@xxxxxxxxx>]

On Tuesday 18 January 2005 12:23, Peter Pentchev wrote:
> On Tue, Jan 18, 2005 at 11:59:36AM +0200, Zhasmin Zhelev wrote:
> > Vasil Kolev wrote:
> > >On вт, 2005-01-18 at 00:11 +0200, George Danchev wrote:
> > >>бърз въпрос: Разликата между x++ и ++x е безкрайно ясна (т.е. определя
> > >>дали променливата ще участва инкрементирана в израза, като тя самата
> > >> при всички случаи се инкрементира), но защо  когато участва и в лявата
> > >> страна на израза (втория случай) се получава един инкремент повече...
> > >
> > >....
> > >
> > >Нали знаеш вица "Докторе, като правя така, ме боли" "Ами не прави
> > >така" :) ...Смесването на префиксния и постфиксния оператор в/у една и
> > >съща променлива в един израз не е ясно какво дава, както например не е
> > >ясно какво прави
> > >a+++b (т.е. дали е (a++) +b  или a+(++b) ).
> >
> > Ами пак без да се заяждам, по принцип ++ е с по-голям приоритет от +, а
> > и изразите се разчитат от дясно наляво, което би следвало че ще е втория
> > вариант, демек a+(++b).
> >
> > Така би трябвало да е ( е поне според мен, и според това както са ме
> > учили )
>
> Хмм.. тук вече зависи :)
>
> Според стандартите за езика C наистина ++ има по-висок приоритет пред +,
> само че това с разчитането на изразите отдясно наляво не съм сигурен, че
> е стандартизирано наистина.  Част от проблема е, че според таблицата с
> приоритетите '++' се асоциира отдясно наляво, а '+' - отляво надясно,
> макар че това всъщност няма голямо значение за това точно как ще бъде
> разчетен (parsed) изразът.

асоциативните правила и приоритета са точно така и това е според ANSI C 
(гледам 2 книжлета тука). a+++b е напълно детерминиран и всеки компил който 
го мисли за различно от (a++) + b е с broken parser според мен. И въобще не е 
архитектурно зависимо (от писмото на Васил), ама грам.

> Въпросът наистина е в самото разчитане (parsing), и там вече нещата много
> зависят от това точно какъв компилатор се използва май :)  В момента нямам
> подръка копие на K&R, за да проверя дали те са дали BNF за синтаксиса, а по
> кажи-речи понятни, донякъде финансови, причини нямам подръка и ANSI X3J11,
> за да видя дали пък *те* не са дали BNF за синтаксиса.  Единственото, което
> имам, е компилатор, и то само GNU C 2.95.4 и 3.4.2 във FreeBSD вариантите.
>
> [roam@straylight ~/c/misc/foo]> ./prec
> (a++) + b = 6
> a + (++b) = 7
> a+++b = 6
> [roam@straylight ~/c/misc/foo]>
>
> Това е резултат от изпълнението на следната програма:
>
> #include <stdio.h>
>
> int main(void)
> {
>         int a, b, c;
>
>         a = 1; b = 5;
>         c = (a++) + b;
>         printf("(a++) + b = %d\n", c);
>
>         a = 1; b = 5;
>         c = a + (++b);
>         printf("a + (++b) = %d\n", c);
>
>         a = 1; b = 5;
>         c = a+++b;
>         printf("a+++b = %d\n", c);
>
>         return (0);
> }
>
> Явно поне при GCC се използва parser, който се опитва първо да навлезе в
> дълбочина, т.е. да намери най-дългото възможно съвпадение с валиден терм,
> така че поредицата от плюсове в 'a+++b' бива разбита първо на '++', защото
> е по-дълго.
>
> Ще се поровя да видя дали не мога да намеря някъде някакъв истински
> стандарт, който да дефинира това поведение, или пък ще си остане undefined
> behavior.

Обаче се отклонихме от темата и тази програма всичко й е синтактично вярно и с 
дефинирано поведение, но това (c = a+++b) е коренно различен пример от 
първоначалния даден от мен където карах компила една и съща променлива да 
участва в израза хем преди и хем след инкрем. Демек бъди на Марс и на Венера 
едновременно и защо не казваш, че не можеш да го направиш... (това по 
отношение на компила)

-- 
pub 4096R/0E4BD0AB 2003-03-18 <danchev.fccf.net/key pgp.mit.edu>
fingerprint    1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 
============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================