Normalement, je ne poserais donc pas une question comme celle-ci car elle semble être une opinion basée ou commencer une sorte de guerre verbale sur des pratiques de codage, mais je pense qu'il pourrait y avoir une raison technique ici que je ne comprends pas .
Je cherchais par-dessus le code dans les fichiers d'en-tête de VCPKG (un gestionnaire d'emballage de bibliothèque que Microsoft crée et est "Nouveau" code) car le code de lecture est généralement un bon moyen d'apprendre des choses que vous ne saviez pas.
La première chose que j'ai remarquée a été l'utilisation de extrait de ' https://github.com/microsoft/vcpkg/blob/master/toolsrc/ Inclure / vcpkg / parse.h '' p> je n'ai pas personnellement utilisé regarder ' https://github.com/microsoft/vcpkg/blob/master/toolsrc/include/vcpkg/commands.h 'J'ai remarqué qu'ils n'utilisaient aucune classe. Au lieu de cela, ce n'étaient que des espaces de noms avec une fonction ou donc dans eux. c.-à-don: p> Je suppose que cette partie de ceci est que la syntaxe appelante semble essentiellement comme une fonction de membre statique dans une classe, de sorte que le code effectue donc la même chose mais peut-être Enregistre des frais généraux en étant un espace de noms au lieu d'une classe. (Si quelqu'un a des idées sur cela aussi, ce serait génial.) P> maintenant le point principal de tout cela. Pourquoi Microsoft utilise-t-il des structures au lieu de classes dans leurs espaces de noms? strong> p> extrait de ' https://github.com/microsoft/vcpkg/blob/master/toolsrc/include/vcpkg/pars.h ': P> à l'aide de code> plutôt que
Typedef code>. p>
en utilisant code> de cette façon avant et une réponse de: Quelle est la différence entre "Typedef" et "en utilisant" en C ++ 11? . Essentiellement,
en utilisant code> est la nouvelle façon de le faire, et la prestation est qu'elle peut utiliser des modèles. Donc, Microsoft avait une bonne raison d'utiliser
à l'aide de code> au lieu de
Typedef code>. P>
namespace vcpkg::Parse
{
/* ... Code I'm excluding for brevity ... */
struct ParagraphParser
{
ParagraphParser(RawParagraph&& fields) : fields(std::move(fields)) {}
void required_field(const std::string& fieldname, std::string& out);
std::string optional_field(const std::string& fieldname) const;
std::unique_ptr<ParseControlErrorInfo> error_info(const std::string& name) const;
private:
RawParagraph&& fields;
std::vector<std::string> missing_fields;
};
}
3 Réponses :
La disposition de la mémoire d'un struct code> est la même que pour une classe
code>. Alors, comment utiliser
struct code> améliorer la compatibilité / l'interopérabilité avec c?
Classe Code> Le mot-clé n'existe pas dans c
Ni les fonctions des membres, Public CODE> /
PRIVATE CODE> Mots-clés, etc., SO Swapping code> Classe code> pour
struct code> ne vous aide pas Compiler le code en C.
@Kevin quand il y a des fonctions membres, oui, mais quand il n'y a qu'un pod, cela fonctionnera dans C.
Mais ce n'est pas le cas ici, alors votre premier point ne s'applique pas.
Les em> les différences em> entre L'accès membre par défaut ( L'héritage par défaut si em> vous héritez du type (héritage public vs héritage privé). p> li>
ol>
Le résultat final de 1 sera identique une fois que l'auteur a fini d'ajouter sur pourquoi em> Microsoft utilise struct code> et
classe code> sont: p>
public code> vs
privé code>) et p> li>
public: code> /
privé: code> au type. 2 Vous pouvez facilement vous contrôler en étant explicite lorsque vous hériter, plutôt que de compter sur la valeur par défaut. C'est à peine une grosse affaire et n'aimable pas vraiment. P>
struct code> plutôt que
class code> dans leur code em>, vous devrez demander à certains Microsoft People. P>
En ce qui concerne les fonctions libres et les fonctions statiques, je ne pense pas qu'il y ait des frais généraux dans les cours (je ne les ai pas mesurés du tout, je penserais que la plupart des compilateurs reconnaîtraient que la classe est fondamentalement juste une Espace de noms pour la fonction). La chose est juste: vous n'avez pas besoin d'une classe. p>
L'utilisation d'une classe avec seulement des fonctions statiques abuse essentiellement de la classe comme espace de noms. Donc, si vous ne faites que cela, alors soyez explicite à ce sujet et utilisez simplement un espace de noms. Avoir une classe, il ne serait que déroutant depuis que vous penseriez que peut-être qu'il pourrait y avoir un État ici et il suffit de voir qu'il n'y a pas de non quand vous voyez que la fonction de la classe est statique. p>
Ceci est particulièrement pertinent si cela est utilisé un peu mal. Imaginez que quelqu'un instance une classe Concernant les deux autres: A a code> avec fonction de membre statique
f code> pour appeler
a.f () code>. Ce n'est pas un problème concernant la performance, car la construction est un non-op et il sera à peu près équivalent à
A :: F () code>. Mais pour le lecteur, il semble qu'il y ait une sorte d'État impliqué et qui vient de déranger. P>
en utilisant code> est juste supérieur à
TypeDEF code> à travers la mesure d'utiliser des modèles et est (IMO) mieux lisible. Le problème
struct code> la classe code> est juste quelque chose sur ce qui a les meilleures par défaut, ce n'est pas une grande différence, mais le plus souvent, ce que vous voulez, c'est ce qu'est un
struct < / code> fait, donc il n'y a aucune raison d'utiliser une classe
code>. p>
Ah cela a du sens. Ayant travaillé dans C (pas d'espaces de noms) et C # (tout doit être dans une classe). L'idée de montrer aucun État n'avait pas traversé mon esprit, mais j'aime ça. En outre, l'héritage public par défaut est sympa! Je peux voir les avantages à cette utilisation de la structure.
Que tout doit être une classe est quelque chose que je suis venu à haïr en Java, je n'ai pas vraiment travaillé avec C # Sofar.
C # Bascialement est juste la version de Java de Microsoft. Je suppose qu'un avantage de choses comme celle-ci est-ce qu'ils créent une norme claire à travers le tableau pour que chacun a suivi.
En quoi est-ce important? Un
struct code> est un
class code> et a
class code> est un
struct code>.
Si je devais deviner, il enregistre des lignes en évitant de devoir écrire
public code>, puis
privé code> plus loin dans la définition de la classe. Enregistrer 1 ligne de code est la seule différence mesurable.
Le comportement par défaut de
struct code> est souvent ce que vous voulez. Cela n'inclut pas seulement les membres du code code> vs
des membres privés code>, mais plus important encore
public code> (
struct code> par défaut) vs
privé code> (
classe code> par défaut) héritage. À mon avis, vous aurez beaucoup plus souvent besoin de
héritage code> et cela n'est pas aussi clair qu'avec les membres, où l'on a principalement des deux types et peut différencier entre eux. Donc, vous avez un petit avantage à travers
struct code> et aucun auge
class code>. Pourquoi ne devraient-ils pas utiliser
struct code>?
IMHO, vous devriez vous concentrer sur vos directives et styles de codage et utiliser uniquement d'autres directives de codage en tant que recommandations ou influences. Jusqu'à présent, il n'y a pas une ligne directrice codante qui convient à tous. Voici quelques: Misra, Microsoft, Google et Amazon. Il existe des outils d'analyse statiques qui reconnaissent beaucoup plus.
Parler de
Typedef code> vs
en utilisant code>;
en utilisant code> est tout i> que
typedef code> fait / a fait + plus i> et est beaucoup plus lisible dans de nombreuses situations, alors évitant ainsi
TypeFeF code> et en utilisant Seul i>
en utilisant code> fait beaucoup de sens pour moi.
@ N314159 Eh bien, je suis passé de penser que ce n'était pas une bonne idée d'utiliser
struct code> pour des raisons de clarté de penser que
struct code> est la voie à suivre.
Est-ce que cela répond à votre question? Quand devriez-vous utiliser une classe vs une structure dans C ++?