Est-il un standard C++ équivalent de IEnumerable<T> en C#?

Ou est-il sécuritaire d'utiliser le vecteur si l'agent Recenseur de T est juste de lister tous les éléments?

  • Il y a un Équivalent vous pourriez utiliser en C++ pourriez-vous voir un exemple de code
  • Merci! J'essaie juste de voir si il y a des approches plus appropriées autres que l'aide de vecteur, qui pourrait permettre à nos propres implémentations de GetEnumerator() en C++.
InformationsquelleAutor derekhh | 2012-01-06
  1. 48

    Il n'est pas nécessaire en C++, et voici pourquoi:

    C# ne supporte dynamique polymorphisme. Afin de créer une réutilisables algorithme, vous avez besoin d'une interface qui tous les itérateurs allons mettre en œuvre. C'est IEnumerator<T>, et IEnumerable<T> est une usine pour le retour d'un itérateur.

    Modèles C++, d'autre part, le soutien duck-typing. Cela signifie que vous n'avez pas besoin de contraindre un paramètre de type générique par une interface afin d'accéder aux membres -- le compilateur va rechercher des membres par nom pour chaque instanciation du modèle.

    C++ conteneurs et les itérateurs ont implicite des interfaces, qui est l'équivalent .NET IEnumerable<T>, IEnumerator<T>, ICollection<T>, IList<T>, à savoir:

    Pour les conteneurs:

    • iterator et const_iterator typedefs
    • begin() fonction membre -- remplit le besoin pour IEnumerable<T>::GetEnumerator()
    • end() fonction membre -- au lieu de IEnumerator<T>::MoveNext() valeur de retour

    Pour les itérateurs:

    • value_type typedef
    • operator++ -- au lieu de IEnumerator<T>::MoveNext()
    • operator* et operator-> -- au lieu de IEnumerator<T>::Current
    • de référence de type de retour de operator* -- au lieu de IList<T> indexeur setter
    • operator== et operator!= -- pas de véritable équivalent dans .NET, mais avec du conteneur end() correspond IEnumerator<T>::MoveNext() valeur de retour

    Pour un accès aléatoire itérateurs:

    • operator+, operator-, operator[] -- au lieu de IList<T>

    Si vous définissez ces, puis des algorithmes standard fonctionnera avec votre conteneur et de l'itérateur. Pas d'interface, pas de fonctions virtuelles sont nécessaires. Pas à l'aide de fonctions virtuelles fait C++ générique code plus vite que son équivalent .NET code, parfois beaucoup plus rapide.

    Remarque: lors de l'écriture des algorithmes génériques, il est préférable d'utiliser std::begin(container) et std::end(container) plutôt que sur le contenant des fonctions membres. Qui permet à votre algorithme pour être utilisé avec des tableaux (qui n'ont pas de fonctions membres) outre les conteneurs STL. Raw tableaux et de matières pointeurs de satisfaire à toutes les autres exigences de conteneurs et d'itérateurs, avec cette seule exception à la règle.

    • C'est une bonne explication pour la consommation de IEnumerable équivalents mais qu'à les produire? Que faire si je veux définir une interface qui expose un membre que je peux faire begin() et end() dessus, mais sans se soucier du type qui implémente que membre?
    • Andrei Alexandrescu n'est pas d'accord avec vous. Voir "les Itérateurs doit aller": zao.se/~zao/boostcon/09/2009_presentations/mercredi/... C++/D Plages sont de la a suggéré de remplacer, et vous vous en doutez, les fourchettes correspondent presque exactement .NET interface IEnumerator.
    • Je ne sais pas comment cela constitue un "désaccord". Maintenant, nous avons deux façons d'effectuer une itération plages sans pratiquement distribué de l'interface. Votre réclamation que les plages sont IEnumerator montre l'ignorance de ce qui IEnumerator est en réalité. Les plages sont de canard-types .NET IEnumerable est distribué de façon dynamique. Et s'il vous plaît noter que les plages, pour tous leurs avantages, ne sont pas encore canonique façon de faire les choses dans la Norme C++.
    • Duck-typing et répartition dynamique ne sont pas mutuellement exclusives. C# 4.0 effectue duck-typing via la distribution dynamique par l'intermédiaire d'un polymorphe inline cache. Que le C++ plages ne sont pas dynamiquement distribué n'est pas pertinent. La correspondance sémantique entre IEnumerator et des plages est de 1:1, modulo le pointeur de la sémantique de C++.
    • C# IEnumerator n'est pas canard tapé. C++ les itérateurs et les plages ont pas de fonctions virtuelles. Duck-typing est 100% pertinent, parce que c'est la raison pour laquelle C++ les itérateurs et les plages n'ont pas besoin d'hériter d'une classe de base commune. Oh, le C# dynamic mot clé n'est pas la même que la distribution dynamique, comme votre commentaire suggère. C'est de liaison dynamique. Qui est, d'ailleurs, encore plus lente que la distribution dynamique, même avec le DLR cache.
    • L'héritage est sans importance, seule la sémantique de la matière. Le domaine et la portée de IEnumerator et C++ plages de match 1:1. C'est un solide isomorphisme. Le dynamisme est un leurre. Aussi, la terminologie n'est pas standard. L'expédition de liaison dynamique de méthodes au moment de l'exécution par l'intermédiaire d'une vtable. Enfin, le duck-typing est également réalisable via la liaison dynamique, afin de vous contredire vous-même en disant que C++ itérateurs ne sont pas les mêmes que IEnumerator en raison de l'expédition. Ce que vous appelez "duck typing" est spécifiquement syntaxique de l'abstraction, qui n'est pas pertinent à la sémantique. Duck-typing est une propriété sémantique, et non pas syntaxique.
    • Vous montrer votre C++ analphabétisme, quand vous dites que le dynamisme est un leurre. Le dynamisme a un temps d'exécution coût modéré pour virtuel d'expédition (comme IEnumerable) et très élevés pour la dynamique de liaison (qui est la seule forme de "duck typing" que le C# a). Le langage de conception de C++ a un fort accent sur la prévention de l'exécution des coûts. Dynamisme est de la sémantique. S'il vous plaît arrêter d'abuser le terme de dynamic dispatch - il est synonyme de virtual expédition, pas de liaison dynamique. Duck-typing en C# besoins de liaison dynamique. Et enfin, la question est à propos IEnumerable, ce qui n'est pas canard tapé.
    • C'est un bon début, mais pouvez-vous donner un exemple simple de la façon de construire un itérateur en C++? -- En C# c'est vraiment simple à utiliser juste yield return (vous n'avez jamais réellement besoin de mettre en œuvre IEnumerable manuellement, sauf si vous êtes en train de faire quelque chose de vilain). Comment voulez-vous faire l'équivalent en C++?
    • Il y a beaucoup d'exemples de code C++ itérateurs autour. Le plus simple est un pointeur. Il n'y a pas d'équivalent à yield return... mais c'est vraiment une coroutine la mise en œuvre et n'a rien à voir avec accès au conteneur. Les normes C++ comité est à la recherche à différents coroutine implémentations; certains ont même expérimentales mises en œuvre dans les différents compilateurs. Mais il n'y a rien de normalisé le long de ces lignes.
    • Aussi, vous pouvez construire des générateurs arbitraires et de leur donner la même interface que les itérateurs. Jetez un oeil à cet exemple: stackoverflow.com/a/1388949/103167
    • Je pense que certaines personnes ici confondu IEnumerable/IEnumerator avec foreach. IEnumerable n'est pas canard-typé. foreach est. Pour avoir eu les deux (basé sur un modèle itérateurs et de l'exécution des itérateurs) est mieux que ce soit l'un ou l'autre. C++ STL est tout simplement terrible dans cette affaire. Essayez de faire d'un modèle virtuel de la fonction de mise en œuvre et vous verrez la question.
    • Encore foreach est extrêmement restreint forme de duck-typing, insuffisant pour un grand nombre d'intéressant algorithmes. Par exemple, vous ne pouvez pas construire de canard tapé une recherche binaire en C#, comme cela nécessite d'accès aléatoire itérateurs, et foreach seulement une seule passe vers l'avant de l'itération. Juste parce que vous ne pouvez pas pratiquement envoi à un modèle ne signifie pas que les modèles ne sont pas utiles... Quand vous vous souciez de la performance, virtuel expédition qui doit être évité, de toute façon, et quand vous avez besoin de polymorphisme, pratiquement distribué des itérateurs sont faciles à faire en C++.
    • Mais puisque vous m'a mis au défi, ici, c'est le "modèle dans une fonction virtuelle mise en œuvre", à savoir un itérateur qui déréférence un pointeur intelligent. Vous pouvez avoir whatever_container<unique_ptr<Base>> et efficacement à pied du conteneur, alors que pratiquement expédition sur ses éléments de trop.

    InformationsquelleAutor Ben Voigt
  2. 8

    La norme C++ façon est de passer deux itérateurs:

    template<typename ForwardIterator>
void some_function(ForwardIterator begin, ForwardIterator end)
{
    for (; begin != end; ++begin)
    {
        do_something_with(*begin);
    }
}

    Exemple de code client:

    std::vector<int> vec = {2, 3, 5, 7, 11, 13, 17, 19};
some_function(vec.begin(), vec.end());

std::list<int> lst = {2, 3, 5, 7, 11, 13, 17, 19};
some_function(lst.begin(), lst.end());

int arr[] = {2, 3, 5, 7, 11, 13, 17, 19};
some_function(arr + 0, arr + 8);

    Yay programmation générique!

    • plus générique façon est d'utiliser des fonctions libres std::begin et std::end
    • Le code du client est d'exploitation sur la non-types de charge qui manifestement ont .begin et .end donc il ne fait pas la cote ici. Dans tous les cas, la genericity de some_function est ce qui est important et ce choix dans le code du client n'a pas d'incidence sur sa mise en œuvre.
    • Générique code client? 🙂
    • oui, générique code client.
    • C'est le contraire de ce qui est demandé pour, à mon humble avis. Cela montre comment consommer un itérateur de façon générique. -- Comment voulez-vous mettre en œuvre la réelle itérateur? (À l'aide de IEnumerable en C#, c'est très facile, il vous suffit d'utiliser yield return -- mais comment faire l'équivalent en C++?)
    InformationsquelleAutor fredoverflow
  3. 4

    IEnumerable<T> est conceptuellement très différent de vector.

    La IEnumerable fournit avant uniquement, en lecture seule accès à une séquence d'objets, indépendamment de ce que le conteneur (le cas échéant) détient les objets. Un vector est en fait un conteneur lui-même.

    En C++, si vous souhaitez donner l'accès à un conteneur sans donner les détails de ce conteneur, la convention est de passer en deux itérateurs représentant le début et la fin du conteneur.

    Un bon exemple est le C++ STL définition de accumuler, qui peut être comparé avec le IEnumerable<T>.Agrégation

    En C++

       int GetProduct(const vector<int>& v)
   {
         //We don't provide the container, but two iterators
         return std::accumulate(v.begin(), v.end(), 1, multiplies<int>());
   }

    En C#

      int GetProduct(IEnumerable<int> v)
  {
        v.Aggregate(1, (l, r) => l*r);
  }
    • Cette réponse ne montre que la consommation de côté, et n'est pas très utile.
    • Vos commentaires et downvotes ne sont pas très utiles. Rien dans la question demande sucre syntaxique pour l'itérateur de la mise en œuvre à l'aide de coroutines, ce qui est exactement ce que le C# yield return est. Cette question n'a pas d'accent sur le côté de mise en œuvre ou la consommation de côté, il pose des questions sur l'interface iterator lui-même, et pas des emballages pratiques. Vous êtes d'imposer votre curiosité au sujet de la mise en œuvre, ce qui est naturel, mais pas utile. Si vous voulez connaître les détails de mise en œuvre, demandez à votre propre question, ne pas détourner celui-ci.
    InformationsquelleAutor Andrew Shepherd
  4. 2

    Si nous nous en tenons à la question strictement la réponse est non, autant que je sache. Les gens ont répétait qu'est-ce que le substitut disponible en C++, qui peut être de bonnes infos, mais pas de réponses, et que les OP plus en savait probablement déjà.

    Je suis complètement en désaccord que "il n'est pas nécessaire," il est juste que les dessins de le C++ et .NET bibliothèques standards sont différents. La principale caractéristique de IEnumerable<>, c'est que c'est polymorphe, et il permet à l'appelant de faire usage de quelque classe qu'il veut (tableau, Liste, Ensemble, etc.), tout en continuant à fournir au moment de la compilation taper fort, fail-safe, même dans la bibliothèque d'Api.

    La seule alternative en C++ est des modèles. Mais les modèles C++ ne sont pas en sécurité tapé au moment de l'exécution des génériques, ils sont en gros les macros. Alors tout d'abord avec les templates en C++, vous êtes obligé de fournir l'ensemble du modèle de code source pour celui qui a besoin d'utiliser votre modèle. D'ailleurs si vous faites votre bibliothèque API basées sur des modèles de vous perdre la capacité de garantir qu'un appel à compiler, et le code n'est pas automatiquement l'auto-documentation.

    Je compatis pleinement avec toute autre programmeur qui utilise à la fois le C# et C++ et est frustré à ce point.

    Cependant, C++2X est prévu d'ajouter des fonctionnalités, y compris les plages (qui peuvent satisfaire aux exigences de l'OP?); ainsi que les concepts (qui adresse les faibles et mauvaise vérification de type de modèles -- faille admis par Bjarne Stroustrup lui-même), et les modules (qui peut ou ne peut pas aider à réduire la douleur de l'en-tête uniquement les modèles).

    • "Les modèles C++ ne sont pas en sécurité tapé au moment de l'exécution génériques" est incroyablement trompeur. Ils sont en toute sécurité tapé (beaucoup moins de danger .NET polymorphisme) au moment de la compilation (ce qui permet une optimisation) génériques.
    • Permettez-moi de reformuler: C++ sont des modèles mais des macros. C++ est bien sûr fortement de type sécurisé -- comme C#.
    • Les modèles C++ sont sensiblement différentes dans le comportement des macros, la fois le faible C variété de macros et également n'importe quel super-puissant, indépendant du langage de macro processeur de soins à adopter. Les modèles et le type de système sont profondément liés.
    • La lecture Alexandrescu de La D Langage de Programmation je vois c'est un vieux débat... je comprends pourquoi un langage comme C# opté pour homogène/polymorphes générique mais le C++ est heureux à une hétérogénéité des modèles et permettre spécialisé instanciation (même si il ne joue pas avec la séparation de l'en-tête et les fichiers de mise en œuvre qui est une autre histoire...) "Homogène traduction favorise l'uniformité, la simplicité et la compacité du code généré. [...] En revanche, hétérogène traduction favorise la spécialisation, de la puissance expressive et la vitesse du code généré."
    • Complètement d'accord avec ceci: "en Outre, si vous faites votre bibliothèque api basées sur des modèles de vous perdre la capacité de garantir qu'un appel à compiler".
    InformationsquelleAutor J.P.