[gull] cours C++

[Daniel Cordey]

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