Pourquoi je ne peux pas hériter de int en C++?

J'aimerais être capable de faire cela:

class myInt : public int
{

};

Pourquoi ne puis-je pas?

Pourquoi voudrais-je? Plus de la frappe. Par exemple, j'ai pu définir deux classes intA et intB, qui m'a laissé faire intA + intA ou intB + intB, mais pas intA + intB.

"Ints ne sont pas des classes." Et alors?

"Ints n'ont pas de données sur les membres." Oui, ils le font, ils ont 32 bits, ou quoi que ce soit.

"Ints n'ont pas de fonctions membres." Eh bien, ils ont tout un tas d'opérateurs comme + et -.

  • Parce que la langue n'a pas été conçu de cette façon.
  • Les langages tels que C# vous permettent d'ajouter des "méthodes d'extension" pour les classes (et à peu près tout, y compris ints, sont des classes), généralement utilisé pour le format en chaînes ou ce que vous avez. Bien sûr, ce n'est pas jive avec la presque-nu-métal C++ modèle.
  • Je pense que Neil commentaire cloué vers le bas. C'était une décision de conception pour ne pas faire de types primitifs classes. Il y a de bonnes raisons de le faire et de bonnes raisons contre. Comme tout dans le C++, cela, aussi, est justifiée par l'objectif de quasi-optimale de la performance.
  • Bien que j'ai apprécié de Neil réponse, il n'a probablement pas faire beaucoup pour éduquer OP. Rappelle moi (n'en déplaise) de l'ingénierie de manuels scolaires: si vous ne l'avez pas déjà comprendre le sujet, l'explication est inutile. Puis de nouveau, j'ai eu un bon rire...
  • "Ints ne sont pas des classes" alors? l'Héritage, le polymorphisme et l'encapsulation sont les clés de voûte de la conception orientée objet. Aucune de ces choses s'appliquent à ordinale types. Vous ne pouvez pas hériter d'un int, parce que c'est juste un tas d'octets et n'a pas de code. Il n'a pas une méthode de la table, donc il n'y a aucun moyen d'ajouter des méthodes ou de les remplacer.
  • Comme pour les "Pourquoi voudrais-je? Plus de la frappe. Par exemple, j'ai pu définir deux classes de l'intA et intB, qui permettez-moi de faire l'intA+intA ou intB+intB, mais pas l'intA+intB", c'est absurde. Vous pouvez mettre en œuvre ces types sans hériter de int. Il suffit de définir un nouveau type à partir de zéro, et de définir ses operator+. Je ne vois pas le problème
  • Si votre syntaxe est légal, alors intA+intB serait de compiler, ce qui était ce que l'on voulait éviter.
  • Downvoted parce que l'OP est belligérants. La question a été répondu de manière adéquate. @Neil réponse est le meilleur: la langue n'a tout simplement pas travailler de cette façon. L'OP doit le laisser aller.
  • Que faire si vous voulez toutes les opérations entiers de soutien? Assurément, il n'est pas beaucoup de joie à les mettre en œuvre pour l'intA, puis la même chose pour intB, etc. etc.
  • Mais UncleBens, il y a la faille. Si vous voulez de type sécurisé opérateurs qui ne fonctionnent pas sur tous les types int, mais seulement à certains, vous allez avoir à re-mettre en œuvre tous les opérateurs de toute façon. Vous n'avez pas sauver quoi que ce soit en descendant à partir de quelque chose qui a déjà les opérateurs. Et si vous ne voulez que les opérateurs de travailler sur tous les types int, alors vous devriez utiliser int.
  • Il peut ne pas être beaucoup de joie, mais il est nécessaire, parce que l'ensemble de la prémisse de la question est de je ne veux pas de ce type de travail dans un contexte où int est prévu. Il ne peut pas réutiliser tout int opérateurs, car cela permettrait à la chose exacte que l'OP voulait éviter.
  • Cela ne signifie pas encore que l'on doit l'accepter, et ne pas se demander s'il pourrait y avoir différents, mais générique et réutilisable solutions.
  • Ne pas hériter de int pour but de faire dégénérer les classes qui violent LSP? Quel est le problème avec la création d'une nouvelle classe avec ints et les opérateurs de membres?
  • Accepter quoi? L'OP propose une fonctionnalité qui, même si elle était possible, ne permettrait pas de réaliser ce qu'il a réellement envie de faire. Avant que vous pouvez blâmer la langue pour ne pas l'appui de sa fonction, il est utile de considérer que le dispositif serait effectivement de résoudre son problème. Dans ce cas, il ne serait pas.
  • Non, @David, il n'en a pas. Il lui a fallu un certain temps pour enfin comprendre à quelle question il vraiment envie de demander, mais dans son deuxième commentaire à votre réponse, enfin, il a précisé qu'il. (Je vois que beaucoup de choses en question "pourquoi", où une personne a de la difficulté à exprimer ce qu'il veut savoir la justification d'une décision de conception plutôt que le chapitre et le verset qui dit que quelque chose est ou n'est pas autorisée.) Je ne vois aucune preuve qu'il rejetait les réponses à ses qui n'est pas encore finalisé question juste pour embêter les gens.
  • bon point bon point de vue.
  • Vous devriez changer le titre de votre question ce que vous cherchez n'est pas hériter de type int, mais avoir un autre type.
  • Je suis content que cette question a obtenu les gens à parler et beaucoup de réflexion à ce sujet. Je pense que c'est une de ces questions que beaucoup de gens pensent qu'ils connaissent la réponse, mais quand il s'agit de formuler cette réponse, le mieux qu'ils viennent avec est: "Juste parce que". I. E. "je ne sais pas".
  • Pourquoi aurait-on à faire un tel héritage? typedef int CostumerId; typedef int ProductId; Costumer getCostumer(CostumerId cid); ProductId pid = 10; Costumer c = getCostumer(pid); // mistake allowed!! si c'était class CostumerId: int {}; and class ProductId: int {}; il ne serait pas autorisé. Si je viens de composer CostumerId { int id; } je vais avoir de la surcharge de tous les opérateurs pour obtenir la pleine fonctionnalité, comme (pid++ == ++pid || pid != pid--).
  • nope, class ProductId { ... int i; public: operator int() {return i;} ...}; va créer un nouveau, de différent objet temporaire. Vous ne pouvez toujours pas faire ProductId pid; .... pid++; -- vous avez encore besoin de surcharger l'opérateur++ pour compiler. S'il était possible d'hériter de int, tous ceux de l'opérateur primordial serait donnée pour gratuit.
  • oups, vous avez raison, la suppression de mon commentaire précédent

InformationsquelleAutor Rocketmagnet | 2010-01-26
  1. 82

    Neil commentaire est très précis. Bjarne mentionné en considérant et en rejetant cette possibilité1:

    L'initialiseur de syntaxe utilisée pour être
    illégal pour les types intégrés. Pour permettre
    c', j'ai introduit la notion que
    construit-dans les types de constructeurs et
    les destructeurs. Par exemple:

    int a(1);    //pre-2.1 error, now initializes a to 1

    J'ai envisagé d'étendre cette notion à
    permettre la dérivation de classes intégrées
    et une déclaration explicite de
    les opérateurs de type intégré. Cependant,
    Je me suis retenu.

    Permettant
    la dérivation à partir d'un int n'est pas
    effectivement donner un programmeur C++
    rien de manière significative de nouveau par rapport à
    avoir un int membre. C'est
    principalement parce que int n'a pas
    toutes les fonctions virtuelles pour les dérivés
    classe remplacer. Plus sérieusement
    cependant, le C des règles de conversion sont donc
    chaotique que de prétendre que int,
    short, etc., sont bien comportés
    les classes ordinaires est pas d'aller travailler.
    Ils sont soit C compatible, ou qu'ils
    obéir à la relativement bien comportés C++
    règles pour les classes, mais pas les deux.

    Autant que le commentaire de la performance justifie pas faire int une classe, c'est (au moins pour la plupart) faux. En Smalltalk, tous les types sont les classes-mais près de toutes les implémentations du langage Smalltalk ont optimisations de sorte que la mise en œuvre peut être essentiellement identique à la façon dont vous ferais un non-class type de travail. Par exemple, le smallInteger classe représente 15 bits entier, et le '+' message est codé en dur dans la machine virtuelle, de sorte que même si vous pouvez tirer de smallInteger, il donne toujours des performances similaires à un type (bien que Smalltalk est assez différent de C++ qui dirigez l'exécution des comparaisons sont difficiles et il est peu probable beaucoup de sens).

    Le bit qui est "perdu" dans le langage Smalltalk mise en œuvre de smallInteger (la raison pour laquelle il ne représente que 15 bits au lieu de 16) ne serait probablement pas nécessaire en C ou C++. Smalltalk est un peu comme Java -- lorsque vous "définir un objet" vous êtes vraiment seulement la définition d'un pointeur vers un objet, et vous devez allouer dynamiquement un objet pour qu'il point. Ce que vous manipuler, transmettre à une fonction comme paramètre, etc., c'est toujours juste le pointeur, pas de l'objet lui-même.

    C'est pas comment smallInteger est mis en œuvre -- il y a dans son cas, ils ont mis la valeur de l'entier directement dans ce qui serait normalement le pointeur. Pour faire la distinction entre un smallInteger et un pointeur, ils ont la force de tous les objets alloués à même les limites d'octets, de sorte que le LSB est toujours clair. Un smallInteger a toujours le LSB ensemble.

    La plupart de ce qui est nécessaire, cependant, parce que Smalltalk est dynamiquement typé, il doit être en mesure de déduire le type en regardant la valeur elle-même, et smallInteger est essentiellement l'aide que LSB type de balise. Étant donné que C++ est statiquement typé, il n'y a pas besoin d'en déduire le type de la valeur, de sorte que vous ne serait probablement pas besoin de "déchets" qui bits sur un type de balise.

    1. Dans La Conception et l'Évolution de C++, §15.11.3.

    • Je ne sais pas la représentation interne des nombres entiers en Smalltalk, mais à 15 bits de l'entier n'est pas utile dans une langue en essayant de travailler avec ou étendre C. Il est trop petit pour être un short, et je doute qu'il peut être utilisé pour faire compact bitfields. Si le coût pour être en mesure de tirer à partir des matières premières les types d'entiers est un peu de surcharge par entier, il est beaucoup trop élevé pour un langage comme C++. C'est une approche valable dans la conception de langage en général, mais une langue qui ne qui ont des problèmes de compatibilité avec C.
    • Thornley:alors c'est vrai que 15 bits est sur le petit côté, gardez à l'esprit que smallInteger a été défini à un moment donné avant 1980. Si j'étais la mise en œuvre de Smalltalk aujourd'hui, je serais probablement faire 63 bits, adéquat pour tous les types integer, sauf long long.
    • Savez-vous si Smalltalk faut vraiment les bit supplémentaire? 63-bit integer est techniquement légal pour int, mais il va toujours avoir des problèmes de compatibilité avec C.
    InformationsquelleAutor Jerry Coffin
  2. 53

    Int est un type ordinal, pas une classe. Pourquoi voudriez-vous?

    Si vous avez besoin d'ajouter des fonctionnalités à "int", envisager la construction d'un agrégat de classe qui a un champ de type entier, et les méthodes qu'exposer ce que des fonctionnalités supplémentaires que vous avez besoin.

    Mise à jour

    @OP "Ints ne sont pas des classes" alors?

    Héritage, le polymorphisme et l'encapsulation sont les clés de voûte de la conception orientée objet. Aucune de ces choses s'appliquent à ordinale types. Vous ne pouvez pas hériter d'un int, parce que c'est juste un tas d'octets et n'a pas de code.

    Entiers, caractères, et d'autres ordinale types n'ont pas méthode des tables de, donc il n'y a aucun moyen d'ajouter des méthodes ou de les remplacer, ce qui est vraiment le cœur de l'héritage.

    • Si je veux tous les méthodes, il devient massive et sujettes à erreur de classe.
    • Je ne pense pas que quiconque faisant valoir le bien-fondé d'une langue, vous permettant d'étendre les types primitifs (plusieurs langues). Cependant, il n'est pas possible en C++. La meilleure solution pour vous, en C++, est de construire un agrégat de classe qui a un nombre entier de membre comme suggéré par cette réponse.
    • Tous les ce méthodes? Int n'en ont pas.
    • Tout ce que je voudrais savoir, c'est pourquoi. Est-il une raison fondamentale pour laquelle cela n'aurait pas été fait à l'intérieur de la conception les contraintes de C++, ou ont-ils oublier?
    • Désolé, je voulais dire les opérateurs.
    • Pourquoi quelqu'un de la conception la Honda Aztek à l'air si stupide? C'était une décision de conception. C'est la seule raison.
    • Il s'agit de la C du patrimoine et ce qui, exactement, primitives représentent. Une primitive de c++ n'est qu'une collection d'octets qui ont peu de sens, sauf pour le compilateur. Une classe, d'autre part, a une table de fonction, et une fois que vous commencez à aller en bas de la succession et de l'héritage virtuel chemin, alors vous avez une vtable. Aucune de ce qui est présent dans un primitif, et en le faisant vous présenter: a) pause beaucoup de code c qui suppose un int est de 8 octets et b) de rendre les programmes prennent beaucoup plus de mémoire.
    • Maçon, de le rendre légal de déclarer des sous-types d'int ne nécessite pas l'ajout d'espace de stockage int. Il est particulièrement ne nécessite pas l'ajout de fonctions virtuelles de type int. Si j'ai un int sous-classe ajouté fonctions virtuelles, et je l'affecter à une variable de type int, alors j'ai un problème de découpage, mais ce n'est pas unique à cette situation.
    • Si j'hérite de l'int il vaut mieux avoir un destructeur virtuel.
    • pour fonctionner correctement avec des fonctions virtuelles int aurait du avoir une vtable. si l'int n'ont pas de fonctions virtuelles, alors il n'y aurait aucun avantage d'hériter d'elle.
    • c'est tout à fait OT, mais l'Aztec est par Pontiac, pas Honda.
    • OK, @Soapbox, je vais poser la même question, à vous comme je l'ai fait à Neil dans les commentaires à Mason de réponse. Si il n'y a aucun avantage à hériter de quelque chose sans fonctions virtuelles, alors pourquoi a C++ conçu pour permettre à tous? C++ permet de permet décroissant à partir de la classe de types qui n'ont pas de fonctions virtuelles, de sorte que l'int est le manque de fonctions virtuelles ne peuvent pas être la raison pour laquelle C++ interdit décroissant d'elle.
    • L'Aztek est un Pontiac. Si c'était une Honda, il aurait été très ennuyeux et vendu un LOT, l'ensemble de ce qui serait encore sur la route de la grande consommation d'essence, mais le coût un peu plus que vous attendez. Et qu'ils ne serait pas presque aussi laid.
    • Sur la Honda, c'est une mauvaise analogie. Q: Pourquoi la Honda Aztek ont 4 roues? mauvais: Car les voitures ont 4 roues. bon: Trois roues ont été essayé, et il est instable.
    • D'autres classes ont des méthodes (même si elles ne sont pas virtuelle) dont vous pourriez bénéficier, y compris dans une classe dérivée, dont certains peut-être protégé ceux qui, ensuite, bien sûr, on ne pouvait obtenir par hériter d'elle. Il y a aussi un avantage évident pour la passer autour de pointeurs vers des classes de base ainsi que d'autres bibliothèques peuvent utiliser l'original de la base de méthodes (virtuel ou pas). Depuis int n'a pas du tout les méthodes, ces arguments ne s'appliquent pas. Vous pouvez obtenir toutes les fonctionnalités que vous souhaitez avec l'opérateur int().
    • "ordinal" types? Peut-être vous dire "fondamentaux" types. Ou peut-être les deux ne sont que des synonymes. Je ne le signale parce qu'il est le type de trait std::is_fundamental, et je soupçonne que renvoie la valeur true pour tous les types de référence.
    • Il serait très utile de dire que "la classe Foo est un flotteur avec des méthodes"; l'Aller langage de programmation fournit une existence qui est la preuve. L'exemple canonique est Fahrenheit et Celsius classes, dont chacune simplement est flotteurs, mais qui ne peut pas être ajouté à ou multipliés l'un par l'autre. Cependant, vous pourriez mettre en œuvre le "AsCelsius" fonction sur un Fahrenheit, et vice versa.
    • La "méthode" est pas un mot en C++. Différentes personnes ont différents notion de "méthode".
    • rien ne peut être ajouté ou multipliés l'un par l'autre", afin que les deux ne peuvent pas être "float avec les méthodes"!

    InformationsquelleAutor 3Dave
  3. 25

    Pourquoi voudrais-je? Plus de la frappe. Par exemple, j'ai pu définir deux classes de l'intA et intB, qui permettez-moi de faire l'intA+intA ou intB+intB, mais pas l'intA+intB.

    Qui n'a pas de sens. Vous pouvez faire tout cela sans hériter de quoi que ce soit. (Et, d'autre part, je ne vois pas comment vous pourriez peut-être obtenir l'aide de la succession.) Par exemple,

    class SpecialInt {
 ...
};
SpecialInt operator+ (const SpecialInt& lhs, const SpecialInt& rhs) {
  ...
}

    De remplir les blancs, et vous avez un type qui permet de résoudre votre problème. Vous pouvez faire SpecialInt + SpecialInt ou int + int, mais SpecialInt + int ne compile pas, exactement comme vous le vouliez.

    D'autre part, si l'on prétendait que l'héritage de int était légal, et notre SpecialInt dérivé de int, puis SpecialInt + int serait de la compilation. Héritant serait la cause du problème exact que vous voulez éviter. Pas hériter évite le problème facilement.

    "Ints n'ont pas de fonctions membres." Eh bien, ils ont tout un tas d'opérateurs comme les + et les -.

    Ceux qui ne sont pas des fonctions de membre du bien.

    • +1 pour régler le véritable problème (surcharge d'opérateur)
    • "Hériter serait la cause du problème exact que vous voulez éviter." Seulement si vous avez été publiquement hériter (que, certes, la question initiale implicite dans la section de code). Privé de l'héritage ne serait pas l'origine de ce problème.
    • Oui, et privé de l'héritage est utile idiome quand vous en avez besoin pour remplacer la classe de base des fonctions de membre sans s'exposer à la classe de base de la fonctionnalité. Ce qui serait privé de l'héritage d'un type de béton sans fonctions virtuelles atteindre?
    • +1 pour le fait que + et - et ce ne sont pas des fonctions membres. Il pourrait être utile de mentionner que, même pour complet soufflé de nombreuses classes surchargées opérateurs n'ont pas besoin d'être membre de fonctions.
    InformationsquelleAutor jalf
  4. 14

    Si l'OP veut vraiment comprendre POURQUOI C++ est la façon dont il est, alors il devrait vous en procurer une copie de Stroustup du livre "La Conception et l'Évolution de C++". Il explique la raison pour cela et beaucoup d'autres décisions de conception dans les premiers jours de C++.

    • Je vais le faire. J'ai Le Langage de Programmation C++, mais pas D&E.
    • C'est un commentaire, pas une réponse. Il serait améliorée si l'information pertinente a été cité ici, au lieu de simplement se référant à une source externe.
    InformationsquelleAutor Stephen C. Steel
  5. 10

    Parce que l'int est un type natif, et non pas une classe

    Edit: déplacement de mes commentaires dans ma réponse.

    Il vient de la C du patrimoine et ce qui, exactement, primitives représentent. Une primitive de c++ n'est qu'une collection d'octets qui ont peu de sens, sauf pour le compilateur. Une classe, d'autre part, a une table de fonction, et une fois que vous commencez à aller en bas de la succession et de l'héritage virtuel chemin, alors vous avez une vtable. Aucune de ce qui est présent dans un primitif, et en le faisant vous présenter: a) pause beaucoup de code c qui suppose un int est de 8 octets seulement, et b) de rendre les programmes prennent beaucoup plus de mémoire.

    Penser d'une autre manière. int/float/char n'ont pas de membres de données ou de méthodes. Pensez à les primitives comme les quarks - ils sont les blocs de construction que vous ne pouvez pas subdiviser, vous les utiliser pour faire des choses plus importantes (toutes mes excuses si mon analogie est un peu hors, je ne connais pas assez la physique des particules)

    • Ce n'est pas une réponse, juste un rappel des faits.
    • qui ne l'empêche pas d'être une réponse. Votre question initiale a demandé pourquoi il ne pouvait pas être fait. Vous ne pouvez pas avoir de savoir que c'était parce que int n'est pas une classe; dans certaines langues int est une classe.
    • OK, pourquoi est de type int pas une classe ? Pour moi, il est logique d'hériter d'un int. Il serait un objet qui se comporte comme un int.
    • Si celui-ci se comporte comme un int, pourquoi voudriez-vous ré-inventer int? :]
    • C'était une décision de conception, quand le C++ a été créé que le groupe builtin types ne seraient pas les classes. Penser d'une autre manière. int/float/char n'ont pas de membres de données ou de méthodes. Pensez à les primitives comme les quarks - ils sont les blocs de construction que vous ne pouvez pas subdiviser, vous les utiliser pour faire des choses plus importantes (toutes mes excuses si mon analogie est un peu hors, je ne connais pas assez la physique des particules)
    • la plupart d'entre nous ne le saurons jamais pourquoi notre 'animal de compagnie' pour n'importe quelle langue sont pas mises en œuvre ou pas mis en œuvre la façon dont nous pensons qu'ils doit être. C++ a été conçu par le comité et c'est ce qu'ils ont décidé sur.
    • Je pense que tu voulais dire "Pourquoi vous ré-inventer int?"
    • Fix avais.
    • Donc punny. L'éloge de La Dood pour le commentaire capacités d'édition. Aussi +1 pour cette réponse parce que c'est la bonne.
    • Comme aussi une décision de conception lors de Java a été créé, et le Java concepteurs allaient massivement dans l'orientation de l'objet. Ils ne fournissent classes wrapper, mais quelqu'un pourrait-il écrire un wrapper template en C++.
    • Je ne vois rien à propos de la fonction de "tables" faire partie d'une classe dans la norme, Mason. Les Classes ont des fonctions membres, mais ils ne contribuent pas quelque chose de la taille d'un objet.
    • Le noyau de C++, encore bien visibles aujourd'hui, n'a pas été conçu par un comité - il a été conçu et mis en œuvre principalement par un seul homme. Presque toutes les fonctions dans le courant de la norme C++ étaient présents dans Cfront 3.0, qui est bien antérieur.
    • Fonctions virtuelles doivent être mis en œuvre en quelque sorte, et que la mise en œuvre doit ajouter à la taille de l'instance. Et si vous n'avez pas de fonctions virtuelles, pourquoi avez succession?
    • si l'héritage est inutile sans fonctions virtuelles, alors pourquoi serait-C++ est conçu pour permettre d'héritage sans fonctions virtuelles?
    • Parce qu'il a été conçu de cette façon. Pas chaque décision de conception est bonne, mais je ne peux pas imaginer l'utilisation de l'héritage sans fonctions virtuelles - certainement, je ne l'ai jamais fait.
    • Donc, nous savons que vous n'êtes pas un théoricien des cordes, puis. 🙂
    • bon point sur Bjarne n'étant pas un comité - je suppose que nous savons exactement qui est à blâmer alors.
    • C'est une pétition de principe, @Neil. Chaque décision a une raison. Je peux penser à un peu pourquoi ce une à ont été faites. 1. Stroustrup ou le comité savait que l'héritage sans virtuals était inutile, mais n'a pas pris la peine d'officialiser une restriction dans le standard, les utilisateurs devraient comprendre pour eux-mêmes, éventuellement, de toute façon. 2. Il y a est raisons pour vouloir héritage sans virtuals, il a été décidé de l'autoriser. 3. Ce n'était pas une décision à tous; la question tout simplement jamais pensé n'importe qui à la fois. 4. Quelqu'un tirèrent.
    • J'irais pour le #2.
    • Si vous avez lu de la Conception et de l'Évolution, vous trouverez que Stroustrup fait, les décisions de conception qui avait l'air bien au moment où il a regretté plus tard (je pense que les protégés de l'héritage est le meilleur exemple). Cependant, Stroustrup voulais laisser les options ouvertes pour le programmeur, et a été peu disposés à interdire quoi que ce soit sans une bonne raison.
    • C'est intéressant @David. (Je ne peux pas vraiment trouver protégées héritage mentionné dans D&E, je vous crois si tu dis que c'est là.) Je ne suis pas sûr de comprendre votre point à l'égard de ce que j'ai déjà écrit, si.
    • Je suis en commentant vos raisons: vous semblez avoir laissé de côté ", Elle ressemblait à une bonne idée de Stroustrup en ce moment", ainsi que des commentaires sur #1: Stroustrup n'aime pas faire des choses illégales, simplement parce qu'il ne voit pas d'un bon usage. La "protégés héritage" chose peut être un défaut dans ma mémoire, mais la section 13.9 est sur les données protégées par les membres, et c'est peut-être ce que j'étais en souvenir de mal.
    • Une classe en C++ ne dispose pas d'une table de fonction, ou de toute autre source de surcharge. Je m'attends à des opérations sur class Int { public: int x; }; pour compiler vers le bas pour le même code que int.

    InformationsquelleAutor Mason
  6. 9

    typage fort d'entiers (et les flotteurs, etc) en c++

    Scott Meyer (Effective c++ a une très efficace et puissant solution à votre problème de faire le typage fort de types de base en c++, et il fonctionne comme ceci:

    Typage fort est un problème qui peut être traitée et évaluée au moment de la compilation, ce qui signifie que vous pouvez utiliser les ordinaux (typage faible) pour de multiples types au moment de l'exécution en déploiement d'applications, et de l'utilisation d'une compilation spéciale de la phase de fer inapproprié combinaisons de types au moment de la compilation.

    #ifdef STRONG_TYPE_COMPILE
typedef time Time
typedef distance Distance
typedef velocity Velocity
#else
typedef time float
typedef distance float
typedef velocity float
#endif

    Vous définissez ensuite votre Time, Mass, Distance être des classes à tous (et seulement) les opérateurs appropriés à surcharger les opérations appropriées. En pseudo-code:

    class Time {
  public: 
  float value;
  Time operator +(Time b) {self.value + b.value;}
  Time operator -(Time b) {self.value - b.value;}
  //don't define Time*Time, Time/Time etc.
  Time operator *(float b) {self.value * b;}
  Time operator /(float b) {self.value / b;}
}

class Distance {
  public:
  float value;
  Distance operator +(Distance b) {self.value + b.value;}
  //also -, but not * or /
  Velocity operator /(Time b) {Velocity( self.value / b.value )}
}

class Velocity {
  public:
  float value;
  //appropriate operators
  Velocity(float a) : value(a) {}
}

    Une fois cela fait, votre compilateur va vous dire toutes les endroits que vous avez violé les règles codées dans les classes ci-dessus.

    Je vous laisse trouver le reste des détails vous-même, ou d'acheter le livre.

    • Merci Alex. C'est à peu près ce que je suis après. Je me demandais si il serait possible de le faire sans avoir à re-préciser à tous les opérateurs de tous les temps.
    • Vous référence Effective C++. Quel rôle voulez-vous dire? "Article 18: Faire des interfaces faciles à utiliser correctement et difficile à utiliser de manière incorrecte", avec ses Date exemple?
    • Une fois que vous avez mis en œuvre le type fort de la compilation, pourquoi même de quitter la faiblesse de frappe comme une option de compilation?
    • La Performance, la densité de code, icache d'utilisation, debuggability, la manipulation des plates-formes incomplètes, incompatible modèle de mise en œuvre.
    • "La Performance, la densité de code" n'est-il pas un compilateur moderne complètement inline ces classes à haut niveau d'optimisation ? J'ai essayé sur gcc.godbolt.org et au -O3 il compile à la même ASM instructions: pastebin.com/sbqvXxP7
    • Pas si les types sont définis dans une bibliothèque, ils ne sont pas

    InformationsquelleAutor Alex Brown
  7. 5

    Ce que les autres ont dit, c'est vrai... int est une primitive en C++ (un peu comme en C#). Cependant, vous pouvez obtenir ce que tu voulais dire par la simple construction d'une classe autour de int:

    class MyInt
{
private:
   int mInt;

public:
   explicit MyInt(int in) { mInt = in; }
   //Getters/setters etc
};

    Vous pouvez alors hériter de tout ce que vous jolly souhaitez.

    • Ok, mais vous aurez envie de marquer le constructeur comme explicit pour empêcher la conversion automatique.
    • Mais cette classe se comporte rien de tel que int.
    • C'est un exemple, pour illustrer un point.
    • Vous devez aller à la peine de l'ajout de tous les états opérateurs abd typecasting des fonctions pour obtenir pour agir comme une étendue int type. Mais une fois que vous faites, vous pouvez alors faire un type de modèle qui prend min et max valeurs admissibles, et toutes les fonctions de membre peut faire le contrôle de la portée.
    • Désolé Fusée, vous voulez "hériter" de l'int tu dois faire le travail 🙂
    • Ne pas se comporter comme un int est votre point de vue, n'oubliez pas: vous voulez plus de vérification de type. Permettant toutes les opérations tels que les entiers n'est le contraire.
    • Quelle est la méthode préférée de test pour cela? is_arithmetic, is_scalar, is_fundamental, etc.

    InformationsquelleAutor Polaris878
  8. 4

    Personne n'a mentionné que le C++ a été conçu pour avoir (surtout) la rétro-compatibilité avec le C, afin de faciliter le chemin de mise à niveau pour les codeurs C donc struct défaut à tous les membres du public etc.

    Avoir int comme une classe de base que vous pourriez remplacer serait fondamentalement compliquer la règle pas de fin et de faire le compilateur de la mise en œuvre infernale qui, si vous souhaitez existant des codeurs et des éditeurs de compilateurs à l'appui de votre naissante de la langue n'était probablement pas la valeur de l'effort.

    • Je ne vois pas cela comme valide. L'original de type int ne se comportent pas du tout différent de l'int forme dont vous pourriez hériter. Et c'est pas comme si C avait une méthode pour vérifier si un type est censé être une classe.
    • BS. Si vous êtes en utilisant l'arithmétique des pointeurs pour itérer sur un malloc avais bloc de mémoire, d'incrément par sizeof(int) doit être de 2 ou 4 octets ( selon la bande passante de votre système tel que défini dans les limites.h) et non par exemple la taille d'un Int, qui sera certainement différent. Aller écrire un compilateur et laissez-nous savoir comment il va.
    • Pourquoi la taille de l'instance qui sera différent? Il ne donne pas toute l'information en dehors de la valeur d'un int? Je n'ai pas besoin de mon propre compilateur pour prouver que.
    • Du point de vue de la langue de conception, un Int classe qui n'a pas la capacité d'avoir des fonctions virtuelles est très limité comme une classe de base, et donc sans doute pas la peine d'avoir. Du point de vue de la mise en œuvre, une classe de fonctions virtuelles besoin d'une vtable pointeur par exemple.
    • Il n'y aurait pas vtable, car il n'y a pas de fonctions virtuelles. La dérivée de la classe int serait de la même taille que l'original int.
    InformationsquelleAutor zebrabox
  9. 3

    En C++ les types intégrés ne sont pas des classes.

    InformationsquelleAutor Trent
  10. 3

    Comme les autres, je dis, ne peut pas être fait depuis int est un type primitif.

    Je comprends la motivation, si, si c'est pour taper plus fort. Il a même été proposé pour C++0x qu'un type spécial de typedef devrait être suffisant pour que (mais cela a été rejeté?).

    Peut-être quelque chose qui pourrait être atteint, si vous avez fourni la base wrapper vous-même. E. g quelque chose comme ce qui suit, qui nous l'espérons utilise curieusement récurrents des modèles d'une manière légale, et ne nécessite que la dérivation d'une classe et de fournir un constructeur approprié:

    template <class Child, class T>
class Wrapper
{
T n;
public:
Wrapper(T n = T()): n(n) {}
T& value() { return n; }
T value() const { return n; }
Child operator+= (Wrapper other) { return Child(n += other.n); }
//... many other operators
};
template <class Child, class T>
Child operator+(Wrapper<Child, T> lhv, Wrapper<Child, T> rhv)
{
return Wrapper<Child, T>(lhv) += rhv;
}
//Make two different kinds of "int"'s
struct IntA : public Wrapper<IntA, int>
{
IntA(int n = 0): Wrapper<IntA, int>(n) {}
};
struct IntB : public Wrapper<IntB, int>
{
IntB(int n = 0): Wrapper<IntB, int>(n) {}
};
#include <iostream>
int main()
{
IntA a1 = 1, a2 = 2, a3;
IntB b1 = 1, b2 = 2, b3;
a3 = a1 + a2;
b3 = b1 + b2;
//a1 + b1;  //bingo
//a1 = b1; //bingo
a1 += a2;
std::cout << a1.value() << ' ' << b3.value() << '\n';
}

    Mais si vous suivez les conseils que vous devriez juste de définir un nouveau type et de la surcharge des opérateurs, vous pouvez prendre un coup d'oeil à Coup de pouce.Les opérateurs

    • Grâce UncleBens. C'est une réponse utile. Je pense qu'une combinaison de Alex Brown réponse avec Boost::Opérateurs serait bon.
    InformationsquelleAutor UncleBens
  11. 2

    Bien, vous n'avez pas vraiment besoin d'hériter de quelque chose qui n'a pas obtenu un membre virtuel fonctions. Donc, même si int ont été une classe, il n'y aurait pas un plus sur la composition.

    Pour ainsi dire, l'héritage virtuel est la seule vraie raison pour laquelle vous pourriez avoir besoin de l'héritage de toute façon; tout le reste est juste vous sauver des masses de taper du temps. Et je ne pense pas qu'un int classe/type avec des membres virtuels serait la meilleure chose à imaginer dans le C++ monde. Au moins pas pour vous, tous les jours int.

    InformationsquelleAutor Debilski
  12. 1

    Que signifie le fait d'hériter d'un int?

    "int" n'a pas de fonctions de membre; il n'a pas de données sur les membres, c'est une 32 (ou 64 bits de la représentation en mémoire. Il n'est pas vtable. Tout ce qu'il "a" (il n'a pas vraiment le même propre) sont certains opérateurs comme +-/* qui sont vraiment global de plus de fonctions que les fonctions de membre.

    • int a un tas d'opérateurs. int a des données sur les membres, composé de 32 ou 64 bits.
    • Non, int est membre des données.
    • Les bits d'un int ne sont pas membres d'un int. Tordre les mots ne modifie pas la réalité.
    • Quelle différence cela fait, @Chuck? Un int contient des données. Un descendant d'un int pouvait contenir que des données aussi facilement, non? Pourquoi a-t-il besoin d'être appelé membre données?
    • Kennedy: Quelle différence cela fait-il? Ça fait toute la différence. Bien sûr, un "descendant" d'un int peut être représenté par le même modèle binaire — en fait, c'est tout ce qu'il pouvait faire, car un int n'a pas de membres. Un descendant qui ne peuvent pas être d'une autre de ses parents n'est pas différent d'un typedef.
    • Tout simplement parce que le type de base n'a pas de "membres" ne signifie pas un descendant ne pouvais pas add membres.
    • Oh, et l'Int de ne pas "avoir" des opérateurs. Les fondamentaux des opérateurs qui font partie de la grammaticales de la langue de support de type int et char, et d'autres ordinale types, mais ils font partie de la langue, pas les méthodes d'une classe. À un certain point, les opérateurs doivent être résolus à des opérations atomiques. Sinon, l'ensemble de la langue mange sa propre queue et le monde allait imploser dans un drôle de paradoxe.
    • Chuck, David: C'est tout à fait vrai et juste, mais il ne répond pas à la question "pourquoi est-il de cette façon". Ceux qui étaient volontaires, les décisions de conception. Indiquant le résultat de ces décisions n'explique pas pourquoi elles ont été faites.
    • De mon point de vue, il y a beaucoup trop de questions sur "pourquoi est-il de cette façon", qui semble supposer qu'un langage de conception émerge de plein fouet et d'une cohérence logique, de quelque part, ou alternativement supposer que le langage a été conçu pour les embêter en laissant certaines fonctionnalités préférées. Il y a tout simplement pas de bonnes réponses à plusieurs de ces questions, en dehors de "Il ressemblait à une bonne idée de Ritchie/Stroustrup/Gosling/celui qui à le temps" ou "Nous avons besoin de maintenir une certaine compatibilité avec X".
    • Je ne vois pas Rocketmagnet rejet de réponses, car ils ne sont pas logiques. Ce que je vois surtout c'est les gens en retraitant les faits ("parce qu'ils sont encastrés!") comme une tentative de réponse pourquoi les faits sont la façon dont ils sont. Si vous pensez que ints ne sont pas héritables parce que Stroustrup pensais que personne ne voulait la fonction, ou parce qu'il considère qu'il est manifestement stupide de penser ça ou tout - aller et de répondre à la question de cette façon. Mais il est parfaitement légal de question que devrait obtenir de meilleures réponses que les "parce que!" il a surtout obtenu dans ce fil.
    • Et de mon point est que ces questions n'ont pas souvent la bonne réponse. Beaucoup de langue de conception de décisions sont prises sans raison particulière, et qui n'ont pas changé plus tard en raison de la compatibilité. Il arrive que Jerry Cercueil déterré de Stroustrup raisonnement sur ce cas, qui est bonne. Parfois, "parce que" est la meilleure réponse, et ça m'énerve quand les gens refusent de l'accepter.
    • Non, ce "parce que" n'est jamais une bonne réponse. C'est juste une tentative pour éviter de dire "je ne sais pas" ou tout simplement fermer. Que faire si tout le monde qui ne sait pas le Pourquoi abstenu de répondre "parce que"? Nous aurions une question tout à fait pertinente avec l'habitude, trois ou quatre réponses, au moins l'un des qui a frappé le droit clou sur la tête. Au lieu de cela, nous avons tout ce bruit, où tout le monde a essayé de cacher le fait qu'ils ne connaissent pas et gagnent en réputation, tout de même.
    • Parfois, "parce que" est la seule réponse. Pourquoi est la constante de Planck ont de la valeur qu'il n'? Parfois, la seule réponse est que cela semblait être une bonne idée à l'époque. Si personne n'a fourni une réponse qui n'était certainement pas la bonne, quelques questions sur les fonctionnalités de la langue irait sans réponse. Ce qui, je dois l'admettre, peut-être une amélioration.
    • Il y a une sacrée différence: est la constante de Planck a été découverte, tandis que le C++' mécanisme d'héritage a été délibérément conçu.
    • comme ça"/"juste parce que"/"c'est la Loi" est une réponse valable lorsque vous savez qu'il n'y a pas une meilleure réponse, mais SI les modérateurs n'aiment pas cette réponse et l'enlever sans rationnelle (et non, "pas de réponse" n'est pas un rationnel)
    • l'ensemble de la langue mange sa propre queue et le monde allait imploser dans un drôle de paradoxe" Non, il ne le serait pas. malloc n'est pas définie en terme de mmap. Vous ne pouvez pas écrire mutex en terme de std C++. Entiers pourrait faire partie de la std lib.
    • Cependant, il y a est une meilleure réponse.

    InformationsquelleAutor anon
  13. 1

    Vous pouvez obtenir ce que vous voulez avec une forte typedefs. Voir BOOST_STRONG_TYPEDEF

    • C'est parfait si, comme moi, on veut le type de tout vérifier et puis est OK avec un lâche typedef. Ce n'est pas aussi élégant que @Alex réponse (à partir de Scott Meyers), mais m'a coûté une seule ligne de code par rapport à la lâche typedef!
    InformationsquelleAutor Vicente Botet Escriba
  14. 0

    Plus général que le fait que "int est primitif" est-ce: int est un scalaire type, tandis que les classes sont globale types. Un scalaire est une valeur atomique, tandis qu'un agrégat est quelque chose avec les membres. L'héritage (au moins tel qu'il existe en C++) n'a de sens que pour un type de regroupement, parce que vous ne pouvez pas ajouter des membres ou des méthodes pour les scalaires, par définition, ils n'ont pas membres.

    • pour certains, class est la syntaxe pour exprimer un type et sous-classement moyen de restreindre le domaine. comme naturals sont un sous-type des entiers, qui sont un sous-type de reals, etc.
    • Devinez quoi? Ces "certains" vivent dans la la terre. Vous parlez de la façon dont vous le souhaitez étaient pas comment il est. Je traite dans le monde réel. la classe n'est pas une syntaxe générique pour exprimer le concept mathématique de type en C++.
    • Ce que vous dites est bien beau, sauf que la question n'était pas "comment est-il?" mais "pourquoi est-il de cette façon?" Ni vos ni vos (un peu désagréable) commentaire réponses à la bonne question.
    • La question était: "Pourquoi ne puis-je faire cela?" La réponse est "Parce que int est un scalaire, et le C++ notion de sous-typage n'est pas significatif pour les scalaires." Les entiers n'étaient pas arbitrairement exclus — il n'est pas possible d'appliquer le concept tel qu'il existe pour eux. C'est pourquoi.
    • Non, ce n'est pas pourquoi. C'est tout en indiquant les faits sans les expliquer pourquoi ils sont comme ils sont. Il y a une très bonne réponse à ces questions et, sans surprise, c'est aussi la accepté de répondre.
    InformationsquelleAutor Chuck
  15. 0

    Cette réponse est une implémentation de UncleBens réponse

    mis en Primitives.php

    #pragma once
template<typename T, typename Child>
class Primitive {
protected:
T value;
public:
//we must type cast to child to so
//a += 3 += 5 ... and etc.. work the same way
//as on primitives
Child &childRef(){
return *((Child*)this);
}
//you can overload to give a default value if you want
Primitive(){}
explicit Primitive(T v):value(v){}
T get(){
return value;
}
#define OP(op) Child &operator op(Child const &v){\
value op v.value; \
return childRef(); \
}
//all with equals
OP(+=)
OP(-=)
OP(*=)
OP(/=)
OP(<<=)
OP(>>=)
OP(|=)
OP(^=)
OP(&=)
OP(%=)
#undef OP
#define OP(p) Child operator p(Child const &v){\
Child other = childRef();\
other p ## = v;\
return other;\
}
OP(+)
OP(-)
OP(*)
OP(/)
OP(<<)
OP(>>)
OP(|)
OP(^)
OP(&)
OP(%)
#undef OP
#define OP(p) bool operator p(Child const &v){\
return value p v.value;\
}
OP(&&)
OP(||)
OP(<)
OP(<=)
OP(>)
OP(>=)
OP(==)
OP(!=)
#undef OP
Child operator +(){return Child(value);}
Child operator -(){return Child(-value);}
Child &operator ++(){++value; return childRef();}
Child operator ++(int){
Child ret(value);
++value;
return childRef();
}
Child operator --(int){
Child ret(value);
--value;
return childRef();
}
bool operator!(){return !value;}
Child operator~(){return Child(~value);}
};

    Exemple:

    #include "Primitive.hpp"
#include <iostream>
using namespace std;
class Integer : public Primitive<int, Integer> {
public:
Integer(){}
Integer(int a):Primitive<int, Integer>(a) {}
};
int main(){
Integer a(3);
Integer b(8);
a += b;
cout << a.get() << "\n";
Integer c;
c = a + b;
cout << c.get() << "\n";
cout << (a > b) << "\n";
cout << (!b) << " " << (!!b) << "\n";
}
    • J'ai écrit ma réponse avant que j'ai vu votre (nous avons différence de 1,5 heures entre nos réponses). Mais je ne suis pas sûr que votre code s'annonce compliquée. Pourriez-vous commenter toute question de plus simple code: stackoverflow.com/a/26154803/751932
    • Je ne vois pas votre message le lien que vous avez fourni ne semble pas aller à un poste particulier. J'ai été le codage en c++ tellement ici, tout semble très simple pour moi. Je serai heureux d'expliquer ma réponse plus loin, laissez-moi savoir ce que vous ne comprenez pas.
    • ma réponse a été supprimée: donc, le lien que je veux vous montrer ici: github.com/Speakus/cppFundamentalClass/blob/master/...
    • Dans votre code, vous aussi mettre en œuvre pour le TT (un autre type autre que de T). Cela supprime la forte typeness qui est recherché. Aussi vous retourner un Primitive<T> plutôt que le type dérivé.Donc, de nouveau, de ne pas être utiles à l'objet de fortes typeness. Essayez d'exécuter UncleBens fonction main() à l'aide de votre classe. Que devrait faire la lumière là où vous en avez besoin pour améliorer.
    • je manque vraiment taper fort demande. Maintenant, il est pris en charge dans mon code aussi: github.com/Speakus/cppFundamentalClass/commit/... - testé avec UncleBens fonction main ():)
    • De mieux en mieux :). à l'aide d'un enum (ou le nombre) n'est pas une bonne idée parce que quelqu'un d'autre peut définir un Primitive<T,N> du même numéro, sans le savoir il en existe déjà un. Vous pouvez faire template<class T, class B> class Primitive : public B {... et passe vide nommé structures pour B

    InformationsquelleAutor over_optimistic
  16. 0

    S'il vous plaît, excusez-moi pour mon mauvais anglais.

    Il existe une différence majeure entre le C++ correcte de la construction comme ceci:

    struct Length { double l; operator =!?:%+-*/...(); };
struct Mass { double l; operator =!?:%+-*/...(); };

    et le projet d'extension 

    struct Length : public double ;
struct Mass   : public double ;

    Et cette différence se trouve sur le mot-clé this comportement. this est un pointeur et à l'aide d'un pointeur de laisser peu de chances pour utiliser les registres pour les calculs, parce que dans conventuelles processeurs registres n'ont pas d'adresse. Pire, à l'aide du pointeur de faire le compilateur suspectes sur le fait que les deux pointeurs peuvent désigner la même mémoire.

    Cela va mettre une charge extraordinaire pour le compilateur d'optimiser triviales de la fpo.

    Un autre problème est le nombre de bugs: reproduire exactement tous les comportements des opérateurs est absolument enclins à faire des erreurs (par ex faire de constructeur explicite n'interdit pas toutes les implicites des cas). La probabilité d'une erreur lors de la construction d'un tel objet est assez élevé. Il n'est pas équivalente à la possibilité de faire quelque chose thru dur travail ou de l'avoir déjà fait.

    Compilateur réalisateurs permettrait d'introduire le type de code de vérification (avec peut-être quelques erreurs, mais le compilateur précision est beaucoup mieux que le code du client, en raison d'un bogue dans le compilateur de générer d'innombrables erreurs des cas), mais l'essentiel du comportement de l'opération restera exactement le même, avec le moins d'erreurs que d'habitude.

    La proposition de solution de rechange (à l'aide de structures pendant la phase de débogage et de vrais chars optimisé lorsque ceux) est intéressante, mais présente des inconvénients: c'est augmenter la probabilité d'avoir des bugs uniquement en version optimisée. Et le débogage d'applications optimales est beaucoup plus coûteux.

    On peut mettre en place une bonne proposition pour @Rocketmagnet initiale de la demande pour les entiers les types d'aide :

    enum class MyIntA : long {}; 
auto operator=!?:%+-*/...(MyIntA);
MyIntA operator "" _A(long);

    Le bug niveau sera très élevé, comme en utilisant un seul membre de truc, mais le compilateur va traiter ces types exactement comme intégré dans les entiers (y compris le registre de la capacité & optimisation), merci pour inline.

    Mais ce truc ne peut pas être utilisé (malheureusement) pour les nombres flottants, et les plus beaux besoin est évidemment réel évalué les dimensions de la vérification. On ne peut pas mélanger les pommes et les poires: ajouter de la longueur et de la région est une erreur commune.

    Stroustrup' invocation par @Jerry n'est pas pertinent. La virtualité est utile principalement pour le patrimoine public, et la nécessité est ici vers le privé de l'héritage. Compte autour de "chaotiques" C des règles de conversion (C++14 d'entre eux, ce qui n'est pas chaotique?) de type de base ne sont pas également utiles : l'objectif est de n'avoir aucun défaut, des règles de conversion, de ne pas suivre les standards.

    InformationsquelleAutor alta
  17. -1

    Si je me souviens, c'était le principal ou l'un des principaux motifs de C++ n'a pas été considéré comme un véritable langage orienté objet. Java les gens disaient: "En Java, TOUT est un objet" 😉

    • Sauf que Java a aussi un int qui ne peut pas être sous-classé, de sorte que ces personnes seraient mal 🙂
    • Merci, quelqu'un qui comprend la question.
    • Remarque que les gens ont différentes définitions de l'orientation de l'objet, de sorte qu'il serait plus exact de dire que "certaines personnes considérées comme C++ pas un vrai O-O de la langue" ou indiquer qui.
    • En C++ un int est un objet. Ce n'est pas un class. Et non pas toutes les classes ont des fonctions virtuelles, non pas toutes les classes sont conçus pour servir de classe de base.
    InformationsquelleAutor Joe
  18. -3

    Ceci est lié à la façon dont les articles sont stockés dans la mémoire. Un int en C++ est un type intégral, comme mentionné ailleurs, et est à seulement 32 ou 64 bits (un mot) dans la mémoire. Un objet, cependant, est stockée différemment dans la mémoire. Il est généralement stocké sur le tas, et il dispose de fonctionnalités liées à la polymorphisme.

    Je ne sais pas comment l'expliquer mieux. Comment voulez-vous hériter du numéro de 4?

    • Les objets sont généralement stockés sur le tas en C++? N'est-ce pas un peu une extrapolation abusive?
    • Aussi, le numéro 4 n'est pas un type. C'est une valeur à une variable de type int peut tenir. Aussi les objets ne sont pas nécessairement polymorphe (voir votre STL).
    • Voici deux variables: int x; struct { int i; } y; Erik, veuillez décrire comment x et y sont stockés différemment dans la mémoire.
    • Il y a des langues avec le prototype de base de l'objet, où l'on ne peut hériter que d'une instance. C'est assez standard dans les langues pour la rédaction d'un texte d'aventures/fiction interactive, comme les Informer et les maladies transfrontières des animaux. C'est juste que le C++ ne fonctionne pas de cette façon.
    • Je ne veux pas hériter à partir du numéro 4, je veux hériter de int.
    • Les structures sont aussi partie intégrante du (de base) types. Ils ne peuvent pas être instanciées, et ne sont pas des objets.
    • Où les objets sont stockés, n'était pas le point principal de mon post. Et, vous POUVEZ stocker des objets sur le tas, si je me souviens bien (ça fait très longtemps que j'ai fait de la programmation en C++), Mais, en général, vous avez une référence à l'objet (sur la pile), et l'objet lui-même est stocké sur le tas. Le pointeur est détruit lorsque vous quittez votre portée, cependant, l'objet de la vie si vous ne la supprimez pas. Cela pourrait conduire à des fuites de mémoire.Cependant, mon point est, les types intégraux ne sont pas stockés de la même manière que les objets, et il n'est pas logique d'en hérite. Ils auraient alors à être les types d'objet
    • vous semblez avoir aucune idée de quoi vous parlez. Dans mon commentaire précédent, y est une instance de la anonyme struct définis à droite. Si elle avait un nom (par exemple, Y), vous pouvez également l'instancier comme ceci: Y* z = new Y; Les variables x, y, et maintenant z, sont tous les objets. (Cochez la norme pour la définition de l'objet; si vous pensez que c'est une "instance de la classe", vous avez tort.) Vous peut stocker des objets sur le tas, mais en disant qu'ils sont généralement il y a une exagération. Ils sont souvent sur la pile, trop. Les types intégraux sont stockés de la même façon que les autres types.
    • Je ne rentrerai pas dans une polémique de C++ détails, je ne suis pas suffisamment compétent dans la langue (loin) de le faire. Cependant, je pense que nous sommes un peu hors-piste. La question initiale est de savoir pourquoi l'auteur ne pouvait pas hériter d'un int (qui est un type de base). Je vais arrêtez de vous battre, maintenant, que j'ai l'impression que nous sommes un peu OT 🙂

    InformationsquelleAutor Erik A. Brandstadmoen
  19. -3

    Pourquoi ne pouvez-vous pas hériter de int, même si vous pourriez vouloir?

    Performance

    Il n'y a pas fonctionnelle raison pourquoi vous ne devriez pas être en mesure (en un point arbitraire de la langue) hérite de l'ordinal de types tels que int ou char, ou char* etc. Certains langages comme Java et Objective-C en fait fournir classe/objet (en boîte) versions du type de base, afin de répondre à ce besoin (ainsi que pour faire face à certaines autres conséquences désagréables de ordinale types n'étant pas des objets):

    language     ordinal type boxed type, 
c++          int          ?
java         int          Integer
objective-c  int          NSNumber

    Mais même Java et objective-c préserver leur ordinale types pour l'utilisation... pourquoi?

    La simple raisons sont la performance et la consommation de mémoire. Un ordinal type peut être généralement être construits, exploités, et passé par valeur en seulement une ou deux instructions X86, et ne consomme que quelques octets au pire. Un cours en général, ne peut - il utilise souvent 2x ou plus comme beaucoup de mémoire, et la manipulation de sa valeur peut prendre plusieurs centaines de cycles.

    Cela signifie que les programmeurs qui comprennent ce sera généralement d'utiliser l'ordinal types pour mettre en œuvre la performance ou l'utilisation de la mémoire sensible de code, et d'exiger que la langue les développeurs prennent en charge les types de base.

    Il convient de noter qu'un certain nombre de langues n'ont pas de ordinale types, en particulier les langages dynamiques tels que perl, qui repose presque entièrement sur un variadic type, ce qui est tout autre chose, et partage une partie de la surcharge des classes.

    • Vous pouvez facilement construire des classes wrapper en C++, qui ajoute de la sémantique pour les types primitifs, mais compile vers le bas à la même assemblée que l'utilisation de la primitive directement, (ou d'appeler un non-membre de la fonction qui gère l'primitive). Une langue n'a pas besoin d'aller à la Java chemin et de vous fournir un nombre Entier de classe qui se comporte différemment de la primitive equivialent.
    • oui, vous avez raison, vous le pouvez. Mais ils ne sont pas fournis à l'extérieur de la boîte, d'où l' ? dans la table.
    • aussi, si il y avait fournis à l'extérieur de la boîte, ils ont des fonctions virtuelles et en se fondant sur une classe de base et de l'avoir des membres dans plus de leur valeur principale. vous pouvez compter sur elle. Par exemple, la Java de type Int, équipé d'une serrure en elle, ainsi que l'int (et qui sait quoi d'autre?)
    • Alex, je suis en désaccord. int n'a pas de fonctions virtuelles, donc il n'y aura pas vtable. Si j'ajoute pas d'autres membres, puis MyInt est exactement de la même taille que int, et devrait compiler un code identique. La seule différence sera moment de la compilation, la vérification de mes types.
    InformationsquelleAutor Alex Brown