On Friday 24 February 2006 11:47, Marc Mongenet wrote: > Que veux-tu dire par "operateurs de classes" ?
CAD qu'un test d'egalite ou d'equivalence n'existe pas forc3ment pour une classe. Dans le cas ou la calsse cree n'herite pas de ces operateurs, il faut les creer. C'est tout, je ne cache aucune theorie quelconque la derriere. Je dis cela car j'ai souvent vu des gens s'empecher d'utiliser certains operateurs de base car ils n'avaient pas penser a les redefinir pour cette classe. A la place de cela, on voit parfois des methodes usine-a-gaze... :-) > Il me semble que ces macros restent utilisables partout à la place de ==, > il faut juste penser à insérer des espaces si on fait un > chercher/remplacer. x=a==b; > x=a EQUAL b; // et pas x=aEQUALb; Exact ! De plus, je deteste les codes sans espace, je les trouve illisibles. > Oour des macros d'intérêt universel comme ça, les macros peuvent > être sympa. Mais ça détruit vraiment toute la sémantique du langage > dans la plupart des autres cas, c'est pour ça que les concepteurs de > C++ les rejettent avec force. Franchement, les macros méritent la > plus grande méfiance, non ? Bonne remarque et heureusement que tu abordes le sujet ! Oui, les macros peuvent etre sympas et meme plus, mais il faut garder a l'esprit que l'on doit imperativement conserver les sens et la semantique sous-jacente du langage dans leur utilisation. Les macros permettent de faire autant de choses extremenet utiles que d'horreurs. > Que des problèmes : > i1) L'encapsulation n'est pas respectée. > i2) MAX1(i1++,2) peut incrémenter plusieurs fois i1. > i3) L'encapsulation n'est pas respectable. > i4) On ne peut pas manipuler MAX1 comme une fonction (prendre l'adresse). > malloc) Ça compile, sans commentaire. Tout a fait. Personnellemnt, je suis contre l'utilisation de ce genre de classe. Les aspects de l'encapsulation sont essentiels et cette base doit etre respectee sans exeptions possibles. Ce probleme se retouve dans tous les langages objets et, malheureusement, beaucoup de gens on tendance a continuer les bricolages et les reflexes des langages proceduraux. Estc-e un manque d'education ou simplement de la paresse ? Je ne sais pas... Pendant qu'on y-est... abordons justement le probleme de malloc() et de C++. Il est fort regrettable que C++ n'ait pas une gestion "propre" de la memoire dynamique. C++ fait massivement appel a malloc() et il suffit qu'un utilisateur commette une erreur dans sa propre utilisation de malloc pour que le debugging devienne un enfer... (j'ai encore en memoire mon premier 'bus error' pointant sur une ligne ne contenant qu'une parenthese). Idealement, C++ aurait du offrir une gestion "separee" de la memoire dymanique, afin aussi de garantir la "destruction" d'objet alloues dynamiquement lors de l'instantiation d'un objet... ou de son extension dans le courant de sa vie. Au lieu de cela, C++ s'en lave les mains et laisse l'utilisateur utiliser ce qu'il veut... CAD malloc(). Ceci mene systematiquement a des "memory leaks" et les exemples sur le net sont plus que nombreux. Il etait pourtant facile de n'offrir ne fut-ce qu'une librairie/class offrant ce genre de service... Tout les autres langages OO offrent ce genre d'outils au travers de "ramasse-miette", plus ou moins bien faits, mais quand meme existants; C++ etant le seul a regarder les mouches au plafond... Bien sur, on retroquera que C++ est un langage et pas une collection de librairies/classes, mais que serait le C sans printf() et malloc() ? Pour moi, cela faisait partie du minimum a assurer. dc _______________________________________________ gull mailing list [email protected] http://lists.alphanet.ch/mailman/listinfo/gull
