From: <nik...@wa...> - 2000-11-29 11:01:46
|
tout ce que tu dis est plus que vrai, et la plus part date de l'epoque pre-historique ou je debutais sur orion ... ceci dit, VC++ ne renvois pas tous les warnings que tu detailles. si ça peux te rassurer, je pense ne plus faire ce genre d'erreurs ----- Original Message ----- From: Rakan El-Khalil <rf...@co...> To: Gabriel Peyre <nik...@wa...> Sent: Wednesday, November 29, 2000 11:07 AM Subject: Remarques pour C > oyez oyez! > > j'ai commence a bidouiller up peu avec le code d'o3d, et j'ai remarque qques > petits pbs: > > 1 - ne jamais declarer les variables autre-part que le haut de la fonction: > raison: 1 - c pas ANSI C > 2 - les diff compilateurs n'interpretent pas les regles de > "scoping" associes a c variables de la meme maniere. > hum, t'es sur que les compilos qu'on va utiliser ne le gere pas [gcc le gere tres bien]. parceque là, ça va etre chiant a corriger, et moi, je trouve que c plus clair comme ça. c peut etre une manie, mais je prefere. Et je pense qu'en + ça fait parfaitement partie des specifs du c++ > 2 - tjrs mettre un "default" case dans les switch > oui, ça ok > 3 - faire gaffe a '=' vs. '=='!!!! idem > 4 - faire gaffe aux conversions entre les nombres (int,unsigned int, long, > float, etc..). souvent j'ai trouve des trucs du genre: mon_int = mon_float. > ouaip, j'ai du en faire pas mal des conversion barbare, mais en general, c voulu [mais ok, c mieux de faire un cast] > 5 - faire gaffe aux types de variables passes aux fonctions. ex, ne pas > passer (int, unsigned int *) a une fonction qui demande (long, unsigned long > *) > idem, mais j'ai l'impression que des fois la doc vc++ se plante sur les fonctions opengl > 6 - ne pas creer des variables qui ne sont jamais utilises > oui, c sur ceci dit, vc++ sort des warning, donc ça m'etonne que j'en ai laissé ... > 7 - essayer de n'inclure que le fichier .h correspondant dans le .cpp. > genre, dans classe.cpp, inclure seulement classe.h. classe.h se chargera > ensuite d'inclure ce qu'il fo. also, essayer d'avoir le max de fichiers > inclus dans OR_Config. comme ca si on change qqch (un define, ou le nom > d'un fichier), c tres facil de tout changer puisque tout est dans un seul et > meme fichier. > pour OR_Config et OR_Annexes, vu que ce sont deux fichiers "externe" au dll [l'utilisateur doit les inclure], non, il ne faut pas les surcharger de fichiers specifiques. Par contre, oui, il faudrait jarter les include execifs Par contre, pas d'include dans Orion.h !!!!!!!!!! [a part config.h ], parceque c un fichier externe au dll. > Toutes ces erreurs peuvent etres evitees si tu dis au compilateur de > t'avertir a la moindre alerte (sur gcc/g++ c le flag -Wall -- je suis sur > qu'il ya un equivalent "show warnings" sur VC++) > > question, pkoi t'utilises des fonctions virtuelles? mon compilateur se > plaint que t'as des fonctions virtuelles dans une classe dont le destructeur > n'est pas virtuel (moa pas comprendre) > hum, la les fonctions virtuelles, c toue la base d'Orion, donc va faloir qu'elle compile. Grosso modo, c ce qui donne le polymorphisme de l'arbre, donc c vital. Par contre, VC++ les gere de façon chelou, c.a.d. que si je ne spécifie pas au moins { } pour toutes les fonctions [meme celles virtuelles], il merde, ce qui est a l'oppose de la philosophie de l'heritage [sur ce point, java est excellent], puisque une fonction virtuelle n'a pas a etre definit en gros, en c++, virtuelle=typage dynamique [!= java ... en java, il utilise le typage dynamique partout]. par contre, pour ce qui est de tes erreurs, t'as qu'a ajouter virtual devant le constructeur, mais c chelou par contre, j'ai remarqué un truc : pour que ça compile, je suis obligé d'inclure une fois [et une seule par fichier .o] le fichier OR_Std_Template.cpp, ce qui est zarbe. Rakan, tu m'avais dit qu'avec gcc tu avais la meme couille, mais de toute façon, il est bien connu que le c++ gere tres mal les template [un prof m'a dit que c'etait super façil de le faire boucler] > R. > > ps. j'ai update les sources si t'as envie de voir les pbs que j'ai a > compiler sur uniz > ok, c cool si y'a des bugs de bases, meme sous win32, n'hesite pas a les corriger ! |