On Wed, 2005-09-28 at 14:16, Daniel Cordey wrote: > On Wednesday 28 September 2005 13:33, Marc Mongenet wrote: > > > > Le compilateur n'aime pas... > > > > Si si, on peut, et le compilateur (GCC) ne dit rien du tout si > > l'on insiste pas (-Wall). > > Quelle horreur... :-) Meme -ansi ?
Justement c'est pour cela que avec gcc j'utilise les options suivantes: CFLAGS="-O0 -g3 -std=gnu99 -pedantic -W -Wall -Wdiv-by-zero -Wmultichar -Wfloat-equal -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wconversion -Wsign-compare -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wpacked -Wredundant-decls -Wnested-externs -Wunreachable-code -Winline -Wlong-long -Wdisabled-optimization" Parfois j'en allume d'autres aussi, mais ceux la c'est la base pour travailler. Le -O0 c'est pour bien déboguer ensuite je passe en -O2. Le -g3 c'est pour le déboguage. Les autres options c'est pour bien voir tout ce qui ce passe. Le -std=gnu99 c'est parce que je programme normalement pour le gcc et donc les extensions gcc sont agréables, si on veut du code portable un beau -std=c99 c'est peut être mieux. Normalement j'essaie de corriger tous les warnings que j'obtiens avec ces paramètres mais parfois ce n'est pas possible, mais du code qui contient 4 warning avec ces options est sûrement meilleur qu'un qui contient 0 warning avec -Wall tout seul. > Il est vrait que depuis 15 ans, tous mes developpements avaient d'abord > passer > au travers du compilateur C de HP-UX (dont le mode par defaut est ANSI depuis > ~10 ans). Je ne me susi donc jamais pose la question lorsque j'ai passe > certains codes sous Linux... Tout au plus, note des differences concernant le > traitement des pointeurs et de NULL (avec des pointeurs). > > > Il y a tout de même pas mal de choses qui sont explicitement « indéfinies » > > (undefined result) dans ANSI C. > > Oui, mais une lecture du standard permet de savoir ce que l'on fait et de ne > pas se trouver dans la situation d'utilisation d'une variable dont la valeur > est indefinie suite a une opertaion. > > > On ne peut plus, mais est-ce que les anciens compilateurs K&R C > > l'interdisaient ? > > Pour autant que je sache, oui ! > > > Il me semblent qu'ils ne testaient pas la compatibilité > > des pointeurs et convertissaient même automatiquement entre > > pointeurs et entier (bon, avec les flottants peut-être tout de même pas). > > C'est vrai pour les pointeurs <-> int/long, mais ca n'a jamais fonctionne > avec > des float. > > > C++ pousse même encore plus loin dans ce sens, Stroustrup étant > > un ardent défenseur de la vérification des types à la compilation. > > Toutes les verifications de compilation obligatoires en C++ peuvent etre > effectuees en C. Je n'ai pas encore lu les definitions de C99, mais je > suppose que c'est encore mieux defini; permettant une meilleure verification > a la compilation. > > > Je crois que c'est devenu nécessaire en C99 (à vérifier tout de même). > > En tout cas c'est nécessaire en C++. > > Perso, je pense que ca devrait etre obligatoire. Mais je suis aussi persuade > que certain programmeurs biaiseront cette necessite en repmplissant des > declarations juste pour faire plaisir au compilateur. Si elles sont bien définies ce n'est pas une mauvaise chose ça a au moins le privilège de réduire les bêtises. > > Il me semble que C++ est devenu moins souple avec les pointeurs de > > type void*. > > Disons qu'il oblige a ecrire excatement ce que l'on peut faire ! > > > Je ne me rappelle plus des détails (faut le vouloir pour > > utiliser des void* en C++). > > Il y a des cas qui se justifient, mais ca ne doit pas etre une necessite, > simplement pour bomber le torse. La manipulation d'objects crees > dynamiquement est un bon candidat pour ce genre de pratique, mais c'est un > debat delicat qui sort du cadre de cette liste. > > dc ciao, Leo
signature.asc
Description: This is a digitally signed message part
_______________________________________________ gull mailing list [email protected] http://lists.alphanet.ch/mailman/listinfo/gull
