Użytkownik <s...@g...com> napisał w wiadomości
news:29f17d21-b0b0-4c39-accb-5f6e2410660c@googlegrou
ps.com...

>> int *a, b;
>> int* a, b;
>> Zatem skoro * dotyczy tylko elementu tuż za znakiem, to przytulajmy go
>> doń,
>> na pewno zyskujemy na czytelności.

> Nie wiem gdzie zyskujemy na czytelności..

Serio nie widzisz różnicy w czytelności?
Patrząc na wszystkie deklaracje w taki sposób:
typ coś1, coś2, coś3...
i wszystkie coś-e muszą mieć typ równy typ.
Jak masz napisane:
int *a, b;
To od razu widzisz, że zarówno *a jak i b są typu int.
A jak napiszesz:
int* a, b;
to możesz myśleć, że zarówno a jak i b są typu int*, co nie jest prawdą.
Dlatego pierwszy zapis jest czytelniejszy, choć oba poprawne.

Ja piszę tak, aby nie mieć nigdy takich wątpliwości. Jak nie jestem na 100%
pewien, jak co kompilator zinterpretuje, to nie stosuję takiego zapisu.
Moje deklaracje wyglądają np. tak:
int i,j,m,n,c;
int *p;
int *s;
int t[10];
Kiedyś jak na całym ekranie mieściło się 25 linijek, a w środowisku typu
Turbo C++ okienko dla źródła miało jeszcze mniej to takie marnowanie linijek
mogło boleć, ale to już dawno za nami.
Poza tym mało kiedy funkcja ma tyle zmiennych.

> Gwiazdka w lewo, prawo, pośrodku, znaki zapytania gdziebądź, wykrzykniki
> itd, itp..
> Nosz kurwa, wolę w assemblerze mov a,b - przynajmniej wiadomo o co chodzi.

Nigdy nie pisałem w assemblerze, ale czy "mov a, b" nie zadziała tak samo
jak "mov a ,b"?
Jeśli tak to zapytam: Dlaczego odmawiasz * prawa do takiego samego
zachowania się jak , ?

Wydaje mi się, że dawniej wszystkie deklaracje musiały być na początku bloku
funkcji (a może każdego bloku). Możliwość deklaracji typu for(int
i=0;i<10;i++) została wprowadzona dla wygody programistów, ale nie ma
przymusu.
P.G.