-1
votes

Pourquoi Microsoft utilise-t-il la structure plutôt que la classe dans le nouveau code?

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 à l'aide de code> plutôt que Typedef code>. p>

extrait de ' https://github.com/microsoft/vcpkg/blob/master/toolsrc/ Inclure / vcpkg / parse.h '' p> xxx pré>

je n'ai pas personnellement utilisé 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>

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> xxx pré>

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>

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;
    };
}


7 commentaires

En quoi est-ce important? Un struct est un class et a class est un struct .


Si je devais deviner, il enregistre des lignes en évitant de devoir écrire public , puis privé 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 est souvent ce que vous voulez. Cela n'inclut pas seulement les membres du code vs des membres privés , mais plus important encore public ( struct par défaut) vs privé ( classe par défaut) héritage. À mon avis, vous aurez beaucoup plus souvent besoin de héritage 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 et aucun auge class . Pourquoi ne devraient-ils pas utiliser struct ?


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 vs en utilisant ; en utilisant est tout que typedef fait / a fait + plus et est beaucoup plus lisible dans de nombreuses situations, alors évitant ainsi TypeFeF et en utilisant Seul en utilisant 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 pour des raisons de clarté de penser que struct est la voie à suivre.


Est-ce que cela répond à votre question? Quand devriez-vous utiliser une classe vs une structure dans C ++?


3 Réponses :


1
votes
  1. être (plus) compatible avec c
  2. Pour éviter tout faire tout public en utilisant le mot clé , puisque que tous les objets COM, par exemple, n'ont que des fonctions membres publiques.

5 commentaires

La disposition de la mémoire d'un struct est la même que pour une classe . Alors, comment utiliser struct améliorer la compatibilité / l'interopérabilité avec c?


Classe Le mot-clé n'existe pas dans c


Ni les fonctions des membres, Public / PRIVATE Mots-clés, etc., SO Swapping Classe pour struct 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.



4
votes

Les les différences entre struct et classe sont:

  1. L'accès membre par défaut ( public vs privé ) et

  2. L'héritage par défaut si vous héritez du type (héritage public vs héritage privé).

    Le résultat final de 1 sera identique une fois que l'auteur a fini d'ajouter public: / privé: 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.

    sur pourquoi Microsoft utilise struct plutôt que class dans leur code , vous devrez demander à certains Microsoft People.


0 commentaires

1
votes

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.

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.

Ceci est particulièrement pertinent si cela est utilisé un peu mal. Imaginez que quelqu'un instance une classe A a avec fonction de membre statique f pour appeler a.f () . 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 () . Mais pour le lecteur, il semble qu'il y ait une sorte d'État impliqué et qui vient de déranger.

Concernant les deux autres: en utilisant est juste supérieur à TypeDEF à travers la mesure d'utiliser des modèles et est (IMO) mieux lisible. Le problème struct la classe 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 .


3 commentaires

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.