int i = 5;
cout << max(5, i++)

gdzie max jest oczywiście twoim makrem? :)

Aczkolwiek, jak sam pokazales, staly wskaznik na staly obiekt uchroni przed niektorymi dziwnymi „zabiegami” programistow korzystajacych z naszego kodu, ktore w wielu przypadkach sa poprostu „wypadkami” przy pracy.

const char* name = "dupa";

No i to jest ten częsty błąd, który często popełniają ludzie preferujący const nad #define. Powyższa deklaracja zapobiega tylko przed zmianą testu na który wskazuje wskaźnik – nie zapobiega natomiast nad zmianą wskaźnika. I tak – poniższy kod jest oczywiście nielegalny:

#include <iostream>
 
const char* NAME = "dupa";
 
int main () {
    NAME[2] = 't';
    std::cout << NAME << std::endl;
    return 0;
}

Ale co z tego, skoro programista może zrobić po prostu tak:

#include <iostream>
 
const char* NAME = "dupa";
 
int main () {
    const char* NAME2 = "duta";
    NAME = NAME2;
    std::cout << NAME << std::endl;
    return 0;
}

i już nasza „stała” jest czymś innym.

Jeżeli chcesz więc zadeklarować zmienną zawierającą łańcuch stałych, poprawna deklaracja wygląda tak:

const char* const name = "dupa";

Wtedy oba kody są nielegalne.

Pozdrawiam;)

Debugowanie nie rozni sie niczym od debugowania zwyklego kodu, ale wszelkie komunikaty bledow moga byc bardzo odstraszajace, choc coraz lepiej prezentuja je „nowe” kompilatory ;p

No i jak pisalem, wzorce podlegaja regulom jezyka co ma zasadnicza zalete nad makrami, w wiekszosci przypadkow pozwala szybciej wychwycic bledy, co w przypadku makr mogloby dac o sobie znac dopiero w run-time. Aczkolwiek zalezy to od kodu.

Co racja to racja, przyklad typowo pmodelowo-przykladowy, ludzie robia rozne dziwne rzeczy na makrach, zamiast uproscic sobie zycie i wykorzystac dedykowane do tego celu narzedzia jezyka.

Odnosnie Twojego kodu, to o ile to mozliwe i nie bedzie problemem, to chcialbym wykorzytac niektore fragmenty do notek z „tej” serii. Trafilem na kilka fragmentów, ktore sa idealnym przykladem pisania w C++ stylem C, i sie idealnie nadaja do pokazania, jak minimalne wykorzystanie kilku podstawowych nozliwosci jezyka C++ wplyneloby pozytywnie nie tylko na sama prezentacje kodu i wyrazenia idei, czy zamaiarow autora, ale przede wszystkim uproscilo kod, polepszylo dzialanie, i pozwolilo uchronic sie przed niektorymi potencjalnymi bledami.

Na początku zaznaczę, że rozumiem Twoje ‘ale’ do preprocesora, i faktycznie w większości przypadków się z tobą zgodzę.

Po za jednym ;>

Mianowicie zacytowane przez ciebie makro ‘max’. Osobiście wychodzę z założenia, że wszystkich chwyty dozwolone, które zwiększają czytelność, upraszczają kod, i upraszczają pisanie (przy utopijnym założeniu, że programiści czytający kod są na dobrym poziomie). Biorąc pod uwagę te 3 punkty, dokonam porównania dwóch stylów ‘max’:

#define max(x,y) (x < y ? x : y)
 
template<typename T>
inline T max(const T& x, const T& y) {
	return x > y ? x : y;
}

Czytelność: szczerze to jakoś 33 znakowe makro mnie bardziej przekonuje niż 3-liniowy template
Uproszczenie kodu: (chodzi o zastosowanie) w obu przypadkach wychodzi na to samo
Uproszczenie pisania: (chodzi o tworzenie kodu) dla wprawnego programisty to bez różnicy, niemniej jednak 33 znaki wklepie się szybciej niż 3 linie

Po za tym przy debugowaniu tego mogę sobie spokojnie preprocesor rozwinąć (gcc -E) i zobaczyć wtf. Template’y mi tego nie oferują (z tego co mi wiadomo).

Niemniej jednak oczywiście zdaje sobie sprawę że przykład z funkcją max może być akurat na granicy tego co wygląda OK w makrach i tego co lepiej zrobić na template’ach.

Z drugiej jednak strony, mój kod raczej nigdy nie służył do czytania ;DDD

Aczkolwiek biblioteka ta powstawala w dawnych czasach, przed standardem i duzo pzozostalosci nadal trzymanych jest w kodzie. Na szczescie od jakiegos czasu jestesmy na dobrej drodze zmian.
Makra mozemy tam podzielic na trzy grupy, rzeczy ktore nie da sie inaczej zrobic niz za pomoca makr, aby zachowac dotychczasowy wyglad (statyczne tablice eventow), makra bedace wrapperami na nowe rozwiazania (glownie na templatesy rozne),aby zachowac kompatybilnosc ze starzym kodem i rozne stare nalecialosci, ktorych nikt nie dotyka.

Ja mam nadzieje, ze z czasem, wiecej „nowoczesnych” (obecnie to juz standardowych) mechanizmow jezyka bedzie wykorzystane, jak namespace, template, exceptions…

Ostatanio dodano wsparcie dla „natywnego” RTTI, jakis czas temu caly system eventow oparto na wzorcach i dodano mozliwosc wspolpracy z boost.signals. Oby tak dalej ;)

Szlag mnie trafia, gdy widzę w kolejnym programie, czy projekcie używanie dyrektywy define preprocesora do definiowania stałych, rozwijanych funkcji [...] preprocesora

Hmm to co powiesz o wxWidgets? ;) programiści tej biblioteki raczej nie unikają stosowania #define w kodzie. ;)

Dla mnie lepszym pomyslem jest pozostawienie zwyklego for, a jak bardzo chcemy operowac na zakresie to std::for_each() lub poczekac na C++0x’owe for dla zakresow ;p