struct, enum, typedef, , et Programmation objet.

Bonjour à tous !


J'aimerai comprendre la place des struct, typedef, enum, union, ... en C++.

Actuellement j'utilise un ensemble de bibliothèques en C++ où ils sont très utilisés. Mais quand j'utilise ces types, ces instructions, j'ai l'impression de faire du C. On peut facilement les remplacer par une classe, ce qui me fait penser qu'en les utilisant on s'éloigne un peu du concept de programmation objet. A force d'avoir ces fameuses biblio sous les yeux j'ai tendance à reproduire ce style de code.

C'est une mauvaise habitude ? ou ça dépend simplement du contexte d'utilisation ?


Merci developpez ! Encore et toujours :lol:

Concernant struct et class : http://cpp.developpez.com/faq/cpp/?p...lass-et-struct

typedef, enum et union n'ont par contre rien à voir. Comment penses-tu pouvoir les remplacer à chaque fois par une class ?! 8O

D'abord, lit les sections relatives au enum, union et typedef ici. Maintenant, est-ce que tu arriverais à obtenir un même comportement rien qu'avec des classes ? Et si oui, qu'est-ce que ça apporte ?

Reproduire le comportement d'une enum avec une classe est possible, juste extrêmement lourd à taper (beaucoup de code "boilerplate" pour gérer les opérateurs)

J'ai parlé un peut vite en mettant les enum et les union dans l'histoire. Mais pour le reste, notamment les structures, je persiste.

Par exemple si je veux employer des couleurs dans mon code. Il va falloir que je crée une structure RGB, une structure couleur, que je déclare chaque couleur en tant que constante de type couleur... . Le code gagnerait en lisibilité si je remplaçai cette partie avec une classes plutôt que d'implémenter des structures de données qui sont assez loin de la fonction originale de ce code. J'ai l'impression que c'est très souvent le cas avec les structures et les typedef.

Sinon, en effet il n'y aucun intérêt à implémenter un enum et un union...

À part pour la visibilité par défaut, une structure et une classe sont strictement pareil. Après on a donné un sens sémantique, généralement on utilise une structure si on veut tout mettre en public, par exemple une structure RGB est un bon exemple. Et on utilise une classe si on fait de l'orienté-objet. Tu parles aussi des typedefs mais ça n'a pas de rapport, un typedef c'est juste un alias sur un type existant et tu peux l'utiliser sur un type créé via un struct ou une class.

Si tu penses que ton code améliorera sa lisibilité en utilisant le paradigme objet et bien vas-y. Si tu veux notre avis, tu peux nous montrer les deux codes pour qu'on saisisse ce qui te tracasse ;)

Typiquement pour une structure de couleur on utilisera un struct parce qu'on en voudra un POD et la visibilité par défaut en public est un bonus. En programmeur feignant, ça nous évite 1 ligne public:.
Maintenant, as-tu seulement lu le lien que je donne dans le premier post ? Il semblerait que non..

Quant au gain de lisibilité avec class plutôt que struct, ça me parait des plus hors-sujets/faux. Encore une fois, lis le lien du premier post.

Citation:

---

Le code gagnerait en lisibilité si je remplaçai cette partie avec une classes plutôt que d'implémenter des structures de données qui sont assez loin de la fonction originale de ce code.

---

Parce qu'une class n'est pas une structure de données ? :weird:
C'est peut-être pas un POD (encore qu'il me semble qu'on peut faire du POD avec class maintenant), mais tout de même..
La fonctionnalité originelle..? Tu veux dire aggréger une composante R, G et B ? :weird:

En c++, une class a toujours pu être POD (c'est uniquement rapport à l'allocation d'une instance de l'objet). J'ai récemment trouvé un bon texte sur le sujet, ici. A noter que j'avais écrit une entrée sur la faq cpp il y a quelques années, mais qu'il faudrait la mettre à jour (c++11 a changé quelques trucs).

Sinon, concernant une classe couleur, je conseille toujours de prendre exemple sur celle de la SFML de Laurent Gomila: simple, efficace, robuste, propre.

Je sais qu'une structure est une sorte de classe avec quelques spécificités. Et oui Bousk, j'ai lu ton lien.

Pour moi certains code C++ utilisent les typedef et les structures comme s'il s'agissait d'un code C. La POO a permis de structurer les programmes. Et, il me semble, les composantes principales de la POO sont les classes et l'héritage. Après on se retrouve avec des .hpp .cpp qui partent dans tous les sens. Bousk, je veux dire que si l'objectif de cette partie de code est de modéliser un fruit (exemple au pif), je trouve ça judicieux que la modélisation de la couleur du fruit soit implémentée séparément. Dans une autre classe si on suit une démarche objet.

En tout cas vous répondez à ma question qui est de savoir si l'utilisation des typedef et des structures en POO est complètement justifiée. Mais bon, j'ai vraiment l'impression que s'ils sont trop utilisés on s'éloigne de la POO.

Dire que c'est trop utilisé, c'est une question de point de vue, on te donnerait bien notre point de vue si tu nous donnais les liens des bibliothèques utilisées ou des exemples.

Dans tous les cas il ne faut jamais être fermé d'esprit, la programmation comporte beaucoup de paradigmes et certains encore trop peu connu/utilisé (fonctionnelle, par contrainte, réactive, ...), là on parle des deux plus connu qui est la programmation impérative et orienté-objet (qui est héritée de la prog impérative). Il faut utiliser le paradigme qui rend le code plus clair, moins long et si besoin, plus performant. Un programme ne devrait pas avoir d'étiquette "orienté-objet", on peut très bien utiliser plusieurs paradigmes, car il y a plusieurs problèmes différents à résoudre dans un même programme. Le plus dur étant de choisir le paradigme adapté (et c'est seulement sur ça qu'on pourrait débattre).