Qui en-tête dois-je inclure pour " size_t`?

Selon cppreference.com size_t est définie de plusieurs en-têtes, à savoir

<cstddef>
<cstdio>
<cstring>
<ctime>

Et, depuis C++11, également dans

<cstdlib>
<cwchar>

Tout d'abord je me demande pourquoi c'est le cas. N'est-ce pas en contradiction avec la SEC principe? Cependant, ma question est:

Dont l'un des au-dessus des en-têtes dois-je inclure pour utiliser size_t? Importe-t-il à tous?

  • Ouvert correspondant fichiers d'en-tête et de trouver la définition.
  • C'est une excellente façon d'écrire fragile du code non portable!
  • Ne pas vraiment comprendre, j'ai tout à fait confiance qu'elle est définie dans les en-têtes
  • Tous ces en-têtes sont C-têtes. Ils sont nécessaires si vous appelez les fonctions C au lieu de leur C++ équivalents. Vous ne devriez probablement pas l'utiliser et trouver le C++ équivalents de
  • C-têtes qui font partie de la norme C++ de la bibliothèque et ne sont probablement pas dupliquer dans l'un de vos allégations de "vrai C++" en-têtes. Quel a été votre point de vue, exactement?
  • J'ai toujours utilisé <cstddef> pour std::size_t
  • Ouais, je suis (de manière informelle) assez sûr que ce soit le lieu pour cela, même si elle finit par être inclus dans les autres.
  • de ne pas mentionner aucun "vrai" en-têtes, mais à l'aide de fonctions C quand il y a des C++ équivalents de ne causer de problème. Par exemple, le mélange de la chaîne d'en-têtes
  • Demander, dans la pour tout ce qui n'est pas de meilleure façon d'écrire du code portable.
  • Je sais, j'étais sarcastique!
  • Bien sûr, en général c'est un bon conseil, mais dans ce cas, il ne semble pas pertinent - comme il n'y a pas de C++ de remplacement pour std::size_t, et l'OP n'était pas plaider en utilisant l'héritage de fonctions C, en observant la citation sur eux le partage de la définition de type. Je doute que quiconque la lecture de ce thread serait induit en erreur en utilisant les anciens types de fonctions à cause de cela, mais si vous voulez être sûr qu'ils ne le font pas, juste assez!
  • Double Possible de What est la différence entre un size_t et int en C++?
  • pas vraiment clair à mes pourquoi vous pensez que c'est un dupe. Je sais quelle est la diff entre int et size_t (et je le savais déjà quand vous posez la question). Les réponses acceptées il y a aussi mentionne seulement deux en-têtes de le définir, mais il ne dit pas lequel de ceux à qui l'on doit utiliser
  • en fait la accepté de répondre à cette question, ne mentionne que le c-têtes, mais bien sûr, je préfère le c++ en-têtes
  • excellente question. J'ai également été intrigué par ce peu de temps en arrière. +1 pour cette

InformationsquelleAutor formerlyknownas_463035818 | 2016-04-13
  1. 79

    En supposant que je voulais minimiser les fonctions et les types I importait, j'irais avec cstddef comme il ne veut pas déclarer toutes les fonctions et ne déclare qu'6 types. Les autres se concentrent sur des domaines particuliers (chaînes de caractères, le temps, IO) qui ne peut pas d'importance pour vous.

    Noter que cstddef seulement des garanties à définir std::size_t, c'est la définition de size_t dans l'espace de noms std, bien qu'il peut fournir ce nom dans l'espace de noms global (en fait, plaine size_t).

    En revanche, stddef.h (qui est également un en-tête disponible en C) des garanties pour définir size_t dans l'espace de noms global, et peut également fournir std::size_t.

    • Est-il garantir que size_t de cstddef est la même et sera toujours le même que les autres? Semble comme il devrait être un bon fichier d'en-tête avec des définitions communes comme size_t...
    • et comme par magie, une autre réponse ici a déjà observé exactement ce qui se passe, par le biais d'un "intérieur" de l'en-tête.
    • Oui, et cet en-tête est cstddef.
    • la question est alors pourquoi d'autres fichiers d'en-tête de définir leur propre...?
    • qui dit qu'ils définissent leur propre? Tous les que dit la norme est-elle sera défini après, y compris ceux en-têtes, cela ne veut pas dire qu'ils ont tous à redéfinir. Il se peut que tous comprennent <cstddef>, ou ils peuvent inclure tous les internes en tête, qui ne définit size_t.
    • et bien sûr, il ya une garantie que size_t dans <cstddef> est la même que dans les autres en-têtes, ce genre d'idiots ne vous prenez la bibliothèque des graphistes? Il est défini dans <cstddef>, mais peuvent également être disponibles (directement ou indirectement) en incluant d'autres en-têtes.
    • L'OP a déclaré Selon cppreference.com size_t est définie de plusieurs en-têtes... et franchement, étant une bibliothèque créatrice n'implique pas d'être un idiot. Et aucun moyen que vous pouvez réclamer, "bien sûr" ici, depuis plusieurs définitions peuvent très bien avoir des fins légitimes et/ou être complètement intentionnel (de minimiser les dépendances d'un fichier d'en-tête). Donc, à moins que vous pouvez pointer vers quelque chose qui interdit explicitement de multiples définitions incompatibles, alors vous consolidés sont un peu trop libéral.
    • le standard C++ dire que vous ne pouvez pas inclure tous ces en-têtes à la fois? Pas de. Il doit donc être possible, et, par conséquent, les définitions doivent être compatibles. Toute autre conclusion est incompatible. Aussi, ", plusieurs définitions peuvent très bien avoir des fins légitimes et/ou être complètement intentionnel (de minimiser les dépendances d'un fichier d'en-tête)" Pourquoi faire qui impliquent incompatible définitions? Donc, je le répète, bien sûr, les définitions sont les mêmes (ce qui n'implique pas il y a une seule définition, c'est juste que toutes les définitions sont équivalentes).
    • Si vous êtes à l'aide du "même" pour dire "venez à partir du même fichier", alors que c'est sans importance, et vous n'avez pas besoin de savoir ou de soins. Peut-être qu'ils le font, peut-être qu'ils n'en ont pas. Tout ce qui importe, c'est que les définitions sont équivalentes (c'est à dire les mêmes types), et cela est évidemment vrai, parce que toute autre conclusion serait de dire que vous ne pouvez pas inclure différents en-têtes standard sans se faire d'erreurs du compilateur.
    • Le but de cette question était l'ambiguïté autour de ce sujet. Vous êtes de faire une supposition que les choses seront toujours les mêmes, mais il y a plusieurs implémentations du standard et il n'est littéralement rien l'application de ces définitions à la même, de sorte que vous ne pouvez pas utiliser "bien sûr" ici. Votre agressivité est ici ridicule plaine. Allez jeter un mauvais jour, quelque part d'autre s'il vous plaît.
    • vous n'obtenez pas différents en-têtes de des implémentations distinctes, de sorte que vos préoccupations ne sont pas fondées. Il n'y a aucun moyen que vous pouvez obtenir incompatible définitions de size_t de différents en-têtes, sauf si vous avez délibérément ou par négligence cassé de votre compilateur. Choses sera toujours le même pour une application donnée. Le type d'un sizeof expression n'est pas juste varient en fonction du jour de la semaine. Si vous doutez encore que les, prendre de quelqu'un qui en fait met en œuvre la bibliothèque standard pour une vie que c'est vrai, et vous pouvez compter sur elle être la même dans chacun de ces en-têtes.
    • J'ai posé une simple question, et n'ai aucune idée de pourquoi vous êtes si hellbent sur hostile. Vous n'êtes pas à l'abri d'être un idiot tout simplement parce que vous hack sur une bibliothèque pour de l'argent. Vous travaillez sur une mise en œuvre spécifique d'une norme, qui n'a pas de mécanisme pour faire appliquer la conception vous en parler. La norme peut modifier, et/ou dans d'autres implémentations peuvent choisir de différer. C'est débile que l'on peut importer tout type à partir de plusieurs fichiers d'en-tête - il devrait y avoir un seul canonique à l'importation pour obtenir un type spécifique. c'est à dire. c'est mauvais pour permettre l'en-tête des importations à la chaîne des autres importations dans votre programme.
    • C'est le noyau essentiel de ma question initiale. Et oui, je comprends que c'est juste la façon dont C et al œuvres, mais elle est bête et provoque exactement cette confusion de l'OP est venu demandant au sujet.
    • Ainsi, bien que <ctime> définit des fonctions comme strftime qui utilisent size_t dans leur interface, et <cstring> définit des fonctions comme memcpy qui utilisent size_t dans leur interface, c'est débile pour size_t être définies à la suite notamment de ceux en-têtes? Je ne pense pas que vous avez pensé à ce travers.
    • Est le csttddef dans la réponse à une faute de frappe? Peut-être cstddef est destinée?

    InformationsquelleAutor Sean
  2. 42

    En fait le synopsis (inclus dans la norme C++) de plusieurs en-têtes specifially inclure size_t ainsi que d'autres en-têtes de définir le type size_t (basé sur la norme C comme le <cX> les en-têtes sont juste ISO C <X.h> les en-têtes de avec a noté des changements où la suppression de size_t n'est pas indiqué).

    La norme C++ cependant, se réfère à <cstddef> pour la définition de std::size_t

    • dans 18.2 Types,
    • dans 5.3.3 Sizeof,
    • dans 3.7.4.2 de Libération de la mémoire de fonctions (qui se réfère à 18,2) et
    • dans 3.7.4.1 des fonctions d'Allocation de (se réfère également à 18,2).

    Par conséquent, et en raison du fait que <cstddef> seulement introduit les types et les fonctions, je collerais à cet en-tête pour faire std::size_t disponibles.

    De noter quelques petites choses :

    1. Le type de std::size_t est obtenu à l'aide de decltype sans y inclure un en-tête

      Si vous avez l'intention d'introduire une définition de type dans votre code, de toute façon (c'est à dire parce que vous écrivez un récipient et souhaitez proposer un size_type typedef), vous pouvez utiliser le mondial sizeof, sizeof... ou alignof opérateurs pour définir votre type sans y inclure les en-têtes à tous, depuis ces opérateurs retour std::size_t par définition standard et vous pouvez utiliser decltype sur eux:

      using size_type = decltype(alignof(char));

    2. std::size_t est pas en soi le monde visible, bien que les fonctions avec std::size_t arguments.

      La déclarées implicitement mondial de l'allocation et la libération des fonctions 

      void* operator new(std::size_t);
void* operator new[](std::size_t);
void operator delete(void*);
void operator delete[](void*);

      ne PAS introduire de size_t, std ou std::size_t et

      se référant à std ou std::size_t est mal formé, à moins que le nom a été déclarée en incluant l'en-tête approprié.

    3. L'utilisateur ne peut pas redéfinir std::size_t bien qu'il est possible d'avoir plusieurs typedefs référence au même type dans le même espace de noms.

      Bien que, la survenue de multiples définitions de size_t dans std est parfaitement valide que par 7.1.3 /3, il n'est pas autorisé à ajouter des déclarations de namespace std comme par 17.6.4.2.1 /1:

      Le comportement d'un programme C++ n'est pas définie si on ajoute les déclarations ou les définitions de l'espace de noms std ou à un espace de noms à l'intérieur de l'espace de noms std, sauf indication contraire.

      L'ajout d'une bonne définition de type de size_t à l'espace de noms ne viole pas 7.1.3 mais il ne viole 17.6.4.2.1 et conduit à un comportement indéterminé.

      Précisions: Essayez de ne pas mal interpréter 7.1.3 et n'ajoutez pas de déclarations ou de définitions de std (à l'exception de quelques le modèle de la spécialisation des cas où un typedef n'est pas un modèle de spécialisation). L'extension de la namespace std

    • Vous oubliez le fait qu'un double de la définition de type pour ne pas introduire un nouveau type. Il ajoute tout simplement un double de la définition de type, ce qui est parfaitement valide.
    • Je ne prétends pas que l'ajout d'une redéfinition de typedef pour std est pas valide car en double typedefs sont illégales. Je déclare que c'est illégal parce que vous simplement ne pouvez pas ajouter des définitions de namespace std - peu importe si ils sont légaux.
    • Ce qui pourrait briser, compte tenu de tout ce que nous savons de toutes ces citations?
    • Quoi que ce soit. C'est ce comportement indéfini est à propos, n'est-ce pas? Au point qu'il peut ou encore, au point qu'il t sur n'importe quel compilateur ne fait pas le comportement du programme défini selon la norme. Ou comme "fredoverflow' mis bien here: "La norme C++ est le seul vote, période."
    • J'aimerais que vous utilisez votre pensée critique. Ce qui pourrait briser?
    • Le plus simple rupture serait une erreur de compilation de l'application de l'interdiction. Mais compte tenu de l'habitude de compilateur auteurs d'abus des comportements indéfinis je voudrais éviter d'encourir le risque, dans la mesure du possible.
    • Votre code pourrait être l'aide d'un subtil définition est différente de celle d'une autre bibliothèque (par exemple, le C++ standard library), mais en raison de l'alignement, semblent continuer à travailler pendant 18 ans, jusqu'à ce qu'un très valeur spécifique est passé dans lequel cas, il déclenche une branche, elle exécute un code aléatoire, et supprime tous les fichiers dans le répertoire documents de l'utilisateur. oups.
    • si le standard dit que std::size_t est du même type que ::size_t qui est du même type que le résultat de sizeof(1) alors comment pourrait-il en être légèrement différente de la définition? Si c'est le cas, la mise en œuvre est non conforme.
    • J'ai négligé le contexte de la question, vous avez raison.

    InformationsquelleAutor Pixelchemist
  3. 9

    Tous les standard de la bibliothèque de fichiers d'en-tête ont la même définition; il n'est pas question que l'un de vous inclure dans votre propre code. Sur mon ordinateur, j'ai la déclaration suivante dans _stddef.h. Ce fichier est inclus par tous les fichiers que vous avez énumérés.

    /*
   Define the size_t type in the std namespace if in C++ or globally if in C.
   If we're in C++, make the _SIZE_T macro expand to std::size_t
*/

#if !defined(_SIZE_T) && !defined(_SIZE_T_DEFINED)
#  define _SIZE_T_DEFINED
#if defined(_WIN64)
   typedef unsigned __int64 size_t;
#else
   typedef unsigned int size_t;
#endif
#  if defined(__cplusplus)
#    define _SIZE_T std::size_t
#  else
#    define _SIZE_T size_t
#  endif
#endif
    • pas sûr, mais je pense qu'il n'est question pour le moment de la compilation, non?
    • pas pour cette question en particulier. Oui, vous pouvez ajouter un en-tête de plus que nécessaire, mais vous déjà addedd un en-tête C dans un projet C++. Pourquoi avez-vous besoin size_t en premier lieu?
    • Ce n'est pas une bonne idée d'utiliser OS macro reniflant à définir size_t. Vous pouvez définir plus portably comme using size_t = decltype( sizeof( 42 ) ). Mais il n'est pas nécessaire, puisque <stddef.h> a presque zéro coût.
    InformationsquelleAutor vll
  4. 4

    Vous pourriez le faire sans en-tête:

    using size_t = decltype(sizeof(int));
using size_t = decltype(sizeof 1); // The shortest is my favourite.
using size_t = decltype(sizeof "anything");

    C'est parce que la norme C++ nécessite:

    Le résultat de sizeof et sizeof... est une constante de type std::size_t. [ Note: std::size_t est défini dans la norme en-tête <cstddef> (18.2). — fin de la remarque ]

    En d'autres termes, la norme exige:

    static_assert(std::is_same<decltype(sizeof(int)), std::size_t>::value,
              "This never fails.");

    Également noter qu'il est parfaitement bien de faire ce typedef déclaration dans le mondial et dans std espace de noms, tant qu'il correspond à tous les autres typedef déclarations de la même typedef-nom (une erreur du compilateur est délivrée sur la non-correspondance des déclarations).

    C'est parce que:

    • §7.1.3.1 Un typedef-nom ne pas introduire un nouveau type de la façon dont une déclaration de classe (9.1) ou déclaration d'enum n'.

    • §7.1.3.3 Dans un non-étendue de classe, un typedef spécificateur peut être utilisé pour redéfinir le nom de n'importe quel type déclaré dans le champ d'application pour désigner le type à qui il fait déjà référence.

    Pour les sceptiques disent que cela constitue un ajout d'un nouveau type dans l'espace de noms std, et un tel acte est explicitement interdite par la norme, et c'est UB et c'est tous là pour ça; je dois dire que cette attitude élève à ignorer et nier meilleure compréhension des enjeux sous-jacents.

    La norme des interdictions de l'ajout de nouvelles déclarations et les définitions dans l'espace de noms std car, ce faisant, l'utilisateur peut faire un désordre de la bibliothèque standard et tirer sur sa jambe large. Pour les rédacteurs de normes, il était plus facile pour permettre à l'utilisateur de se spécialiser un peu de choses et l'interdiction de faire quoi que ce soit, pour faire bonne mesure, plutôt que d'interdire tous les seule chose que l'utilisateur ne doit pas faire au risque de manquer quelque chose d'important (et que la jambe). Ils l'ont fait dans le passé, lorsque exigeant qu'aucun conteneur standard doit être instancié avec un type incomplète, alors qu'en fait, certains conteneurs pourraient bien faire (voir La Norme Bibliothécaire: les Conteneurs sont Incomplètes Types de Matthew H. Austern):

    ... En fin de compte, tout cela semblait trop sombres et trop mal compris; le comité de normalisation ne pense pas qu'il y avait un quelconque choix, sauf pour dire que les conteneurs STL ne sont pas censés travailler avec incomplètes types. Pour faire bonne mesure, nous avons appliqué cette interdiction pour le reste de la bibliothèque standard de trop.

    ... Rétrospectivement, maintenant que la technologie est mieux comprise, cette décision semble encore raison sur le fond. Oui, dans certains cas, il est possible de mettre en œuvre certaines des conteneurs standard afin qu'ils puissent être instancié avec incomplètes types — mais il est également clair que, dans d'autres cas, il serait difficile ou impossible. C'était surtout la chance que le premier test, nous avons essayé, à l'aide de std::vector, qui est arrivé à être l'un des cas faciles.

    Étant donné que la langue règles exigent std::size_t être exactement decltype(sizeof(int)), faire namespace std { using size_t = decltype(sizeof(int)); } est une de ces choses qui ne cassent pas quoi que ce soit.

    Avant C++11 il n'y a pas de decltype et donc aucun moyen de déclarer le type de sizeof suite à une simple déclaration, sans faire une bonne affaire de modèles impliqués. size_t alias de types différents sur différentes architectures cibles, cependant, il ne serait pas une solution élégante pour ajouter un nouveau type juste pour le résultat de sizeof, et il n'existe pas de standard intégré dans les typedefs. Par conséquent, la solution la plus compacte à l'époque était de mettre size_t type alias dans un en-tête spécifique et document.

    En C++11, il est maintenant une façon d'écrire que l'exigence exacte de la norme comme un simple déclaration.

    • que juste introduit une définition de size_t que je voudrais éviter
    • Peu importe, cette définition va être aussi bon que les autres à venir à partir de la norme en-têtes.
    • pas de son pas, parce que sa ma propre définition de la place de la série
    • Ce n'est même pas droit. size_t est défini n'est pas signé, et pourtant, vous avez défini est comme signed. La montre le problème avec le fait d'essayer de couper et de coller votre chemin autour de l'utilisation de la norme en-têtes de!
    • Ce que vous avez écrit n'a aucun sens.
    • Cette définition de type est exactement le même que le mondial ::size_t typedef. Vous pouvez typedef le même type de nombreuses fois, aussi longtemps qu'il est mappé sur le même type.
    • et conseillé sont des choses différentes.
    • exactement. En manquant la différence entre signés et non signés, cette définition a ajouté un incompatiblity. Encore pire - size_t est définie par le système. Pourquoi devrait-il être int ?
    • Quels sont vos propos? Cette size_t est pas signé.
    • La moitié d'entre eux n'ont pas compris le présent code, il fonctionne parfaitement. Cependant, je n'aime pas cette façon : c'est mieux, de l'omi, à inclure un en-tête et de laisser le standard de la définir.
    • Eh bien, peut-être (je n'ai pas testé ce ou par rapport à tous les autres bits de la Norme) en plus de la vie réelle des implémentations vous n'avez pas besoin physique d'inclure la définition de type, mais c'est probablement mieux pour ce faire, au moins pour éviter toute ésotérique des problèmes plus tard.
    • Ouais, le nombre de downvotes indiquer combien de personnes ne sont pas undertstand C++.
    • Vous avez raison, mon erreur! Cependant, votre réponse se sent vraiment comme un maladroit (et hacky) de façon à éviter d'inclure un en-tête de!
    • Les gars, d'apprendre au moins les effing langue avant d'aller downvoting parfaitement les réponses correctes.
    • Peut-être pas gênant, mais intelligent. Astucieux, le code doit quelques commentaires autour d'elle.
    • Tom a dit, "Il y a 6 bibliothèque standard les en-têtes de définir la même chose! C'est de la folie! Nous avons besoin d'une et une seule définition de size_t!" Une minute plus tard, Marie dit, "OMG! Il y a 7 définitions de size_t à travers la bibliothèque standard les en-têtes et un projet d'en-tête de Tom est de l'édition! Il y a probablement plus dans la 3e partie des bibliothèques!" xkcd.com/927
    • Explication: le type de Retour de sizeof est size_t. Ce code introduit un type, qui est égal au type de retour de sizeof, et les noms qui size_t.
    • Non, vous ne pouvez pas ajouter un std::size_t définition de toute façon depuis l'ajout de std n'est pas autorisée. Mais en fonction de ce que vous faites (c'est à dire la mise en œuvre de certains type de Conteneur de la définition d'un size_type), vous pouvez introduire une nouvelle définition de type et puis, cette réponse est valable pour le faire.
    • Si j'ai voulu faire le malin, je le ferais using size_t = decltype(sizeof(1));, lol.
    • Ce serait une déclaration en double, ne pas casser l'ODR.
    • Wow, comment fait-il pour le côté positif si rapidement? 😉
    • Notez que dans mon commentaire, il n'y a pas de std::. Il est parfaitement acceptable de présenter les choses comme mylib::binary_tree::size_type. Je me sens douteux de définir le 7e mondial size_t quand il y a 6 std::size_t disponibles.
    • La norme ne permet pas (à quelques exceptions près) à l'ajout de définitions de l'espace de noms std et je pense que les typedefs ne sont pas autorisés. Ce n'est pas à propos de l'ODR.
    • Où il est probablement sous-optimale à instaurer des typedefs de toute façon. 😉
    • Cela ne veut pas ajouter un nouveau type dans std, ni redéfinit tout type, simplement une déclaration en double. Cela ne veut pas casser l'ODR. Totalement inoffensif.
    • le comportement d'un programme C++ n'est pas définie si on ajoute les déclarations ou les définitions de l'espace de noms std. Cela inclut les déclarations en double.
    • où avez-vous vu l'espace de noms std ?
    • comprend double déclarations. - quelle phrase de la norme est-ce en venir?
    • J'ai grandi, que vous ne pouvez pas déclarer std::size_t de toute façon et comme vous n'ajoutez pas "un autre" std::size_t comme @NickyC donne à penser, mais plutôt un size_t (espérons-le) dans votre environnement local.
    • Il dit que vous êtes dans UB terre si vous ajoutez des déclarations de std. Il n'y a pas d'exception pour la copie des déclarations et, par conséquent, ils sont formellement interdits dans les régimes, en respectant le code C++.
    • n'est pas une exception pour la déclaration en double - cette affirmation est inexacte. Voir 7.1.3: Une définition de type nom-ne pas introduire un nouveau type de la façon dont une déclaration de classe (9.1) ou déclaration d'enum ne... Dans un non-étendue de classe, un typedef spécificateur peut être utilisé pour redéfinir le nom de n'importe quel type déclaré dans le champ d'application pour désigner le type à qui il fait déjà référence.
    • Mon affirmation est correcte. Votre citation dit tout simplement que vous pouvez redeclare/redéfinir identiques types de non-portée de classe. Il ne lève PAS la règle que vous êtes ne sont pas autorisés pour ajouter les déclarations de namespace std.
    • Laissez-nous continuer cette discussion dans le chat.
    • Je ne vois pas de rien ajouter à l'espace de noms std ici.
    • Alors que c'est une définition possible de la size_t, cela ne veut pas répondre à l'OP de la vraie question: c'est comme si je l'avais demandé pour l'en-tête où FILE est déclarée et que vous souhaitez suggérer d'écrire la mienne.
    • La plupart des généralisations sont incorrectes. Le vôtre ne fait pas exception. stackoverflow.com/a/36504750/412080
    • Je ne vois pas comment il ne pourrait pas s'appliquer à ce cas. Si l'on demande où acheter un marteau, ce qui suggère comment fabriquer un vous-même est au-delà du point de la question, les avis, je n'ai pas dit que c'est incorrect, c'est tout simplement en dehors de la portée.
    • Downvoting, tandis que le poste n'est pas explicitement mis size_t dans namespace std, l'OP question était à propos de l'obtention de l'accès à std::size_t. De sorte qu'il ne soit pas répondre à l'OP de la question, ou conseille UB pour le faire. (Injection d'une telle définition de type dans namespace std est une déclaration, et vous ne pouvez pas ajouter une déclaration d'espace de noms std.) Votre insistance sur le fait que ce qui est légal n'est pas pertinente: même si vous correcte, la norme devrait être au moins ambigu de l'AC, et l'ajout d'une manière ambiguë, UB du code est presque aussi mauvais que sans ambiguïté UB, sauf grande récompense.
    • Il y a de nombreux exemples dans le passé, lorsque la norme a été underspecified. E. g. les personnes traitées std::string::data() comme contiguë, lorsque la norme n'exige pas ou de la garantie de cette qualité. Basé sur les précédents historiques, et les exigences de la norme layed dehors dans ce post, la probabilité de cet être UB est de 0.
    • Vous utilisez UB dans un chemin qui semble se mettre en ligne avec "crash" ou "erreur de segmentation", pas "résultant dans un programme dont le comportement n'est pas spécifiée par la norme". C'est but que l'ajout de symboles pour std autres que dans quelques cas précis ne doit pas être fait par l'utilisateur code côté. Ce n'est pas une underspecification. Vous semblez faire valoir "bien sûr, la norme dit de ne pas le faire, mais le faire de toute façon, qu'est-ce que le mal". C'est fondamentalement différente de celle de "le standard a une erreur". Enfin, en supposant que std::string::data() était contiguë a une grande récompense, votre suggestion aucun.
    • Nous sommes d'accord pas d'accord a l'amiable.
    • Euh, ce n'est pas "tout à fait correct." Il (a) ne répond pas à la question (qui était: "qui d'en-tête?") et (b) les défenseurs de l'AC.
    • bon, peut-être que correct, puis. Au moment où j'ai atterri ici, cette réponse était debout à -7 (sans doute) parce que les gens ne comprennent pas que decltype(sizeof(int)) était fondamentalement size_t, pas int. D'autres coupant les cheveux en quatre questions n'étaient pas dans mon périmètre.
    • Je n'ai pas d'objection à l'utilisation du mot parfaitement, j'ai été en s'opposant à l'utilisation du mot correct.
    • Il n'est pas établi que cela est incorrect. Malgré l'opposition des opinions.
    • Il n'y a pas valable des avis opposés. Il y a le @Yakk (et al) a soutenu l'argument que l'ajout de cette déclaration à std UB. Et il n'y a que vous venez de désaccord avec cela. Tous plaident pour une réponse au meilleur résout pas de problème de toute façon et il est juste d'essayer d'être intelligent. Dans le meilleur des cas, vous avez raison (et vous n'êtes pas), et c'est une mauvaise réponse. Le pire des cas, c'est tout simplement faux.
    • "Le standard des interdictions de l'ajout de nouvelles déclarations et les définitions dans l'espace de noms std" ... Vous êtes encore confus, j'ai peur. La norme n' pas dire que "[t]il, le comportement d'un programme C++ n'est pas définie si on ajoute [nouveau] les déclarations ou les définitions de [ ... ]", mais il est dit que "[t]il, le comportement d'un programme C++ est undefined si on ajoute les déclarations ou les définitions [...]". Il y a une différence entre ces deux états. La première serait de permettre l'ajout d'un autre std::size_t définition, ce dernier ne fonctionne pas.
    • Bien que cela semble être un énorme gaspillage de temps et d'énergie, j'ai été invité à présenter ses observations. Techniquement, l'ajout de toute déclaration d'espace de noms std UB, à moins d'indication contraire. Il n'y a aucune autre indication" qui permet de (re)déclarations de std::size_t. Mais dans ce cas, il ne sera jamais rien de mal, parce que decltype(sizeof 1) est std::size_t. Mais je ne vois aucun avantage à le faire plutôt que de #include <cstddef> (qui est un tout petit en-tête).

    InformationsquelleAutor Maxim Egorushkin