Discussion :

[germinolegrand]

Ah, je vois qu'il y a eu quiproquo, que j'avais déjà expliqué plus haut (je ne sait plus où), on ne parle pas de la différence entre class et struct, mais bien (à ne pas confondre) des classes (de services) et des structures (de données = POD), donc grossièrement si je devait résumer le titre du débat, les class/struct à sémantique de valeur doivent-elle être des classes de services ou des structures de données (POD) ?

[Kaamui]

Presque, mais pas tout à fait

Le débat est en fait celui-ci: est-ce que toutes les entités (class ou struct) d'un programme (ou librairie) doivent être présentés sous la forme d'objets encapsulés (qui, donc, fournissent une interfaces proposant des services) ou peut-on intégrer dans un programme (ou une librairie) des entités qui ne sont pas encapsulées (et donc, ne fournissent pas de services) ? Si tel est le cas, quelles sont les conditions que doit remplir selon vous une telle entité ?

D'accord, mais j'ai l'impression que tout le monde a associé les structures comme des entités qu'on utilise quand on penses "données" et les classes comme des entités qui sont utilisées quand on souhaite encapsuler. Alors que d'après ce que vous me dites le mot struct (ou class) ne sert plus à rien.

Oui. Même l'héritage privé. Si tu tiens à en avoir le coeur net, essaie (tu dois bien avoir un compilateur à portée de clavier).

Non non si vous le dites je vous crois. Et puis rien ne me dit que mon compilateur respecte le standard à ce niveau là, si je voulais en avoir le cœur net, il faudrait surtout que je lise ça dans la norme.

non non mais moi aussi j'ai cette impression. Un attribut privé avec un getter dessus n'est pas forcément un service on est d'accord.

[germinolegrand]

g++ -pedantic et tu seras tranquille ^^

En fait on utilise struct quand on fait quelque chose de purement public et qu'on ne veut pas s'embêter à mettre un public: (donc de la pure flemme comme les dev l'aiment tant).
Là encore ce ne sont que les goûts et les couleurs, personnellement j'utilise struct/class à des fins sémantiques, pour donner une indication à la lecture du code (tiens ça c'est un type de données, ça c'est une classe de service...).

[r0d]

Là encore ce ne sont que les goûts et les couleurs, personnellement j'utilise struct/class à des fins sémantiques, pour donner une indication à la lecture du code (tiens ça c'est un type de données, ça c'est une classe de service...).

Pareil. J'utilise aussi struct pour les foncteurs. Je pense que c'est une pratique assez répandue.

[PilloBuenaGente]

Je me permet de remonter ce post, il est écrit ici, je cite :

En informatique beaucoup d'ingénieurs, ayant l'habitude de travailler avec des structures, ont tendance à les utiliser en lieu et place de classes. Il y a pourtant une différence de taille entre la classe et la structure :

La structure est un "#define" (soit une macro traité par le pré-processeur).
La classe est un "typedef" (soit un type au même titre qu'un int ou un char).

Cela signifie que la structure est une macro (son code est expansé avant compilation par le préprocesseur à chaque appel) alors que le code de la classe n'est compilé qu'une seule fois.

J'ai pourtant lu partout, et on m'a dit, que les classes et structures n'avait pas de différence au niveau du code généré ?

Intox, non ?

[germinolegrand]

http://cpp.developpez.com/faq/cpp/?p...e_class_struct

Donc oui, intox. (et c'est tout bonnement sale de faire une macro pour ça)

[koala01]

Je me permet de remonter ce post, il est écrit ici, je cite :J'ai pourtant lu partout, et on m'a dit, que les classes et structures n'avait pas de différence au niveau du code généré ?

Intox, non ?

Non, je persiste et signe : il n'y a aucune différence entre une structure et une classe en C++, en dehors de la visibilité par défaut.

Il n'est pas impossible que ce que dit ce wiki ait été vrai à un moment donné (aux tout débuts de C++), parce que C ne connaissait que les structures et qu'il fallait (il le faut d'ailleurs à ma connaissance toujours ) rajouter le mot clé struct à chaque utilisation d'une structure ou passer par un typedef pour qu'elle soit connue comme un type.

Mais cette distinction ne s'applique pas en C++, vu que les structures C++ définissent automatiquement le type en question

[Emmanuel Deloget]

Je me permet de remonter ce post, il est écrit ici, je cite :J'ai pourtant lu partout, et on m'a dit, que les classes et structures n'avait pas de différence au niveau du code généré ?

En informatique beaucoup d'ingénieurs, ayant l'habitude de travailler avec des structures, ont tendance à les utiliser en lieu et place de classes. Il y a pourtant une différence de taille entre la classe et la structure :
* La structure est un "#define" (soit une macro traité par le pré-processeur).
* La classe est un "typedef" (soit un type au même titre qu'un int ou un char).
Cela signifie que la structure est une macro (son code est expansé avant compilation par le préprocesseur à chaque appel) alors que le code de la classe n'est compilé qu'une seule fois.

Intox, non ?

Ils ont fumé ces braves gens. Même en C, les structures n'ont strictement rien à voir avec les macros. Une structure a toujours été un type en C. Il n'y a aucune raison pour que ça ne soit pas le cas en C++.

En C++, et ce depuis aussi loin que je m'en souvienne (j'ai commencé le C++ en 1994), les structures ont toujours été des classes avec un accès public par défaut. Je parierais ma chemise qu'elles sont décrites ainsi dans la première version du C++ Programming Language de Stroustrup, et que c'est comme ça qu'il les a imaginé (pour la simple et bonne raison que le premier compilateur C++ générait du code C ; donc le mot-clef struct et le mot-clef class étaient tous les deux mappés au mot-clef struct du C).

Un brin supplémentaire de logique aurait pu servir aux auteurs : un compilateur C++ peut compiler du code C, et le programme résultant est censé se comporter de la même manière (modulo certains cas très, très particuliers).

[PilloBuenaGente]

C'est modifié ! :p

(Je m'en doutais bien, pour en avoir entendu parlé , mais ils m'ont quand même mis un léger doute)

Merci pour les infos.

#Edit C'est re-modifié, merci !

[Emmanuel Deloget]

C'est modifié ! :p

(Je m'en doutais bien, pour en avoir entendu parlé , mais ils m'ont quand même mis un léger doute)

Merci pour les infos.

Il existe une autre différence : par défaut, quand on hérite d'une classe, on en hérite de manière privée. Quand on hérite d'une structure, on en hérite publiquement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
struct A { int a;  }; 
struct A_child : A { }; // A_child::a est public
 
class B { public: int a;  }; 
struct B_child : B { }; // B_child::a est privé

C'est une différence importante (qui est, encore une fois, liée au contrôle d'accès).

[Médinoc]

Il existe une autre différence : par défaut, quand on hérite d'une classe, on en hérite de manière privée. Quand on hérite d'une structure, on en hérite publiquement.

Je crois que tu as légèrement mal formulé: Il me semble que c'est "quand une classe hérite d'une classe ou structure, elle hérite en privé" et "quand une structure hérite d'une classe ou structure, elle hérite publiquement".
En gros, c'est le type du légataire qui compte, pas celui du défunt.

[PilloBuenaGente]

B hérite de A, B à accès aux membres de A ?!

[Matthieu Brucher]

Oui !

[Bousk]

B hérite de A, B à accès aux membres de A ?!

Si les membres sont public ou protégé et l'héritage public ou protégé.
C'est le principe-même de l'héritage..

[Médinoc]

Si les membres sont public ou protégé et l'héritage public ou protégé.

B hérite de des membres publics/protégés de A même en héritage privé. C'est juste qu'ils ne seront pas visibles de l'extérieur, et que de l'extérieur on ne pourra pas convertir implicitement un B* en A*.

[koala01]

En fait, ce qu'il faut comprendre, c'est que private:, protected: et public: ne sont que des "contrôle d'accès".

Un objet, quel qu'il soit, se doit d'être complet et de disposer, quelle que soit la situation, de l'ensemble de ses membres.

Lorsque l'un moteur de voiture est entièrement monté, par exemple, tu n'a pas accès aux cylindres ou aux pistons, parce qu'ils sont "cachés" par la carcasse même du moteur, mais cela n'empêche absolument pas que le moteur (en état de fonctionnement) dispose bel et bien des cylindres et des pistons, car il ne serait pas en mesure de rendre les services que l'on en attend s'il ne les avait pas.

Les contrôleurs d'accès ne font que donner une précision sur "qui peut accéder à telle ou telle chose", et "cacher" certains éléments à certaines catégories d'objets.

Ainsi, lorsque tu déclares un membre dans le contrôle d'accès public, tu dis "tout le monde sans exception peut y accéder", alors que lorsque tu en déclare un autre dans l'accessibilité privée tu dis "seules les fonctions membres de l'objet peuvent y accéder".

L'accessibilité protégée quant à elle indique que seules les fonctions membres de l'objet et les fonctions membres des types qui dérivent de l'objet peuvent accéder au membre en question

Tout comme le cylindre de mon exemple, ce n'est pas parce qu'un membre n'est "pas accessible" depuis l'extérieur qu'il n'existe pas, bien sur

Mais intéressons nous à l'héritage, maintenant.

L'héritage est un processeur qui permet au type dérivé de récupérer "l'ensemble des élément" du type de base.

Il est simplement possible de définir le "niveau maximal" d'accès aux différentes composantes du type de base.

Ainsi, lorsqu'un héritage est défini comme publique, les éléments publiques de la classe de base sont publiques dans la classe dérivée, les éléments protégés de la classe de base sont également protégés dans la classe dérivée et les éléments privés de la classe de base sont... inaccessibles à la classe dérivée, à moins de passer par une fonction membre de la classe de base.

Dans le même ordre d'idées, lorsque l'on déclare un héritage comme étant privé, on indique que seules les fonctions membres de la classe dérivée sont susceptibles d'accéder aux éléments de la classe de base auxquels la classe dérivée peut accéder (donc, aux membres protégés et publiques de la classe de base).

De même, si l'on déclarait un héritage comme étant protégé, nous indiquerions que seules la classe dérivée et ses éventuelles classes dérivées auraient accès aux éléments de la classe de base auxquels la classe dérivée a légalement accès (encore une fois, les membres protégés et publiques de la classe de base).