Comme tout le monde le fait remarquer, il n'y a que deux différences linguistiques réelles :
-
struct
par défaut, l'accès public et class
Par défaut, l'accès est privé.
- Lors d'un héritage,
struct
La valeur par défaut est public
l'héritage et class
La valeur par défaut est private
l'héritage. (Ironiquement, comme pour beaucoup de choses en C++, le défaut est à l'envers : public
l'héritage est de loin le choix le plus courant, mais les gens déclarent rarement struct
juste pour éviter de devoir taper le " public
mot-clé ".
Mais la véritable différence dans la pratique se situe entre un class
/ struct
qui déclare un constructeur/destructeur et un autre qui ne le fait pas. Il existe certaines garanties pour un type POD "plain-old-data", qui ne s'appliquent plus lorsque vous prenez en charge la construction de la classe. Pour que cette distinction reste claire, de nombreuses personnes utilisent délibérément uniquement les types struct
pour les types POD, et, s'ils doivent ajouter des méthodes, utiliser class
es. La différence entre les deux fragments ci-dessous est par ailleurs sans signification :
class X
{
public:
// ...
};
struct X
{
// ...
};
(Soit dit en passant, voici un fil de discussion contenant de bonnes explications sur la signification de "type POD" : Que sont les types POD en C++ ? )
65 votes
Ceci n'est pas seulement applicable au C++, mais à tout langage qui fournit à la fois des structs et des classes.
4 votes
Je ne suis toujours pas d'accord - j'aborde cette question de manière sémantique. Il y a peut-être quelques différences techniques, mais sémantiquement, elles ne le sont pas. Les structures sont vraiment utiles pour créer des types de valeurs, les classes ne le sont pas.
1 votes
Je trouve que j'utilise rarement struct en C++, sauf quand j'ai besoin d'une initialisation auto-agrégée de Plain Old Data, je ne pense pas que cela puisse être fait avec des structures de données définies avec une instance d'une classe.
9 votes
Je pense qu'il n'y a aucune raison sérieuse d'utiliser les structs en C++. Pour moi, les structs sont une autre "fonctionnalité" redondante du C++ qui n'existe que pour la compatibilité avec le C, comme les typedefs. Ces derniers n'existeraient pas si le C++ n'était pas initialement traité comme une extension du C, et était conçu à partir de zéro, comme Java. En général, je trouve que beaucoup des choses les plus bizarres à propos du C++ ont à voir avec la compatibilité avec le C.
4 votes
En pratique, la plupart des gens semblent utiliser class s'ils prévoient d'avoir des fonctions membres, et struct dans le cas contraire. Il ne s'agit cependant que d'une convention. struct et class sont en fait pratiquement identiques, à l'exception de l'accès privé par défaut pour class et de l'accès public par défaut pour struct.
7 votes
Struct - Pour POD (plain old data) et l'accessibilité de tous les membres est publique. Class - Lorsque vous avez besoin d'une meilleure encapsulation et que les fonctions membres doivent travailler avec l'état de la classe.
6 votes
Ce n'est vrai que par convention. Il n'y a aucune différence, hormis l'encapsulation par défaut.
1 votes
@Dave - cette convention est la raison la plus importante de faire cela. Si elle est suivie de manière cohérente, cette seule différence fournit immédiatement beaucoup d'informations aux lecteurs.
0 votes
Les conventions sont incroyablement importantes (considérez l'impact des catégories d'itérateurs, ou des gardes d'en-tête, ou des paires de fichiers .cxx/.h). Cette réponse minimise cette importance, et est donc moins utile que la plupart des autres.
0 votes
Vous avez raison. Je pense personnellement que les concepteurs des autres langages ont emprunté cet idiome aux développeurs de C++.
1 votes
Je ne dirais pas que mon commentaire "minimise" l'importance des conventions. Je pense qu'il est important de savoir ce qui est conventionnel et ce qui fait vraiment partie du langage si vous voulez être plus qu'un simple programmeur de cargo-cult.
0 votes
Memset un struct, vs memset une classe.
2 votes
@EvilTeach :
memset a struct, vs memset a class.
il n'y a pas de différence en C++. Cela dépend si ce que vousmemset
est un type POD ou non.0 votes
Que se passe-t-il s'il ne s'agit pas d'un POD ?
4 votes
@JasonBunting notez que pour C# c'est plus qu'une différence "sémantique". Les structures sont traitées comme des valeurs et transmises par valeur, contrairement aux classes.
1 votes
@Matthias - Cela va bientôt faire 9 ans que j'ai écrit cela, et il semble que certains commentaires intermédiaires aient été supprimés. Cela dit, j'ai bien dit "Les structures sont vraiment utiles pour créer des types de valeur, les classes ne le sont pas", et c'est précisément pour la raison que vous mentionnez.
0 votes
Este pregunta est quelque peu pertinent, que faire si nous voulons ajouter uniquement des constructeurs aux structs pour initialiser les données.
0 votes
@Kostas écrit "[les structs] n'existeraient pas si le C++ n'était pas initialement traité comme une extension du C, et était conçu à partir de zéro, comme Java." Peut-être, peut-être pas. J'ai conçu un système de POO (dans un dialecte Lisp), non compatible avec tout système de POO existant, dans lequel les classes sont appelées "structs". Elles présentent l'héritage, le polymorphisme et tout le reste. J'aurais pu facilement choisir d'utiliser la terminologie "classe". Il n'est donc pas acquis qu'une conception de zéro, à partir de zéro, utilisera "class" au lieu de "struct".
0 votes
C'est l'un des (nombreux) domaines de dysfonctionnement du "C avec classes" au C++. Les classes avec une répartition statique pure et les classes avec une répartition virtuelle pure sont des bêtes très différentes. Avec le C++, nous avons obtenu un mélange in-évident qui a fait trébucher de nombreux programmeurs au fil des ans. Pas brillant.