2010-07-02 4 views
2

En C++, quel est le meilleur moyen de renvoyer une collection au code client sans utiliser d'itérateurs.Méthode générique pour renvoyer une collection entière

Supposons que les itérateurs soient exclus car, par exemple, la collection est distante. Je voudrais une signature pour une fonction qui renvoie la collection sous la forme la plus utile possible.

Par «meilleur», j'entends le meilleur compromis entre la clarté et la généricité.

Mon instinct était (où result.push_back (obj) est valide C++):

template <typename T> 
void getCollection(T& result); 

Je me demande si quelqu'un a de meilleures idées, par exemple qui soutiendrait également des insertions dans des conteneurs qui ne supportent pas push_back, ou qui nécessitent une transformation des objets dans la collection.

Ce qui suit, peut-être?

template <typename Func> 
void getCollection(Func f); // applies f to all the objects 
+4

Peut-être que c'est juste moi, mais je ne vois vraiment, vraiment, vraiment pas quel problème vous essayez de résoudre. Qu'est-ce que push_back a à faire avec votre première option?Pourquoi ne pouvez-vous pas utiliser les itérateurs pour une collection à distance? L'interface de l'itérateur semble correspondre parfaitement à cela. Votre question est si vague que je me demande pourquoi vous ne pouvez pas faire 'template CollectionType & GetCollection()'. De quoi avez-vous besoin? – jalf

+2

Il y a deux choses que je ne comprends pas à la question: que voulez-vous accomplir? Pourquoi les itérateurs ne sont-ils pas la solution? Pouvez-vous clarifier - je crois que les itérateurs * sont * la solution même si je n'ai pas bien saisi la question ... –

+1

Pourriez-vous clarifier la partie "à distance"? Je ne vois aucune connexion. – pmr

Répondre

-1

Mon friedns de façon préférée de retourner un tas de données à partir d'une fonction est en utilisant des pointeurs partagés:

boost::shared_ptr<vector<string>> f() { 
    boost::shared_ptr<vector<string>> vec(new vector<string>()); 
    vec->push_back(....); 
    return vec; 
} 
+6

Inutile, inefficace et mauvais pointeur intelligent. Si vous l'avez, vous devriez utiliser std :: unique_ptr, sinon vous devriez utiliser std :: auto_ptr. Une fois dans un shared_ptr vous ne pouvez jamais le sortir et l'utiliser dans un pointeur intelligent plus approprié. Vous devriez au moins donner le choix au client. –

+0

Je ne peux pas être d'accord. Un pointeur intelligent est suffisant pour tous vos programmes. 0,00001% des cas sont nécessaires à cet égard, et tous seront traités différemment. –

+2

Cela n'a rien à voir avec l'efficacité. Si un pointeur intelligent suffit, pourquoi pensez-vous que la norme en ajoute 2? La sémantique partagée n'est souvent pas ce qui est désiré. –

0

Je pense que vous devez mieux décrire votre problème. Simplement, pour retourner une collection, je dirais, utilisez un template qui retourne un itérateur. Mais si vous parlez de code client, c'est-à-dire que l'application sera séparée en quelques parties et qu'elles pourraient être compilées séparément, je dirais que la seule façon portable est d'utiliser un pointeur vers un tableau. Mais, que voulez-vous dire par télécommande? Si cela signifie une machine séparée, alors vous avez besoin d'une forme de sérialisation comme Boost::Serialization ou Protobuf.

4

Le mode itérateur est ce que vous voulez vraiment. Pourquoi? Parce que cela permet au client de coller ces données dans tout ce dont il a besoin. Comme vous le savez, vous avez déjà du mal à décider comment coller les données sur la fin du conteneur parce qu'il y a différentes façons. Avec un OutputIterator, vous n'avez pas à vous en soucier. Attribuez et avancez.

Ennemi, l'utilisateur de votre fonction pourrait vouloir coller les données dans une chaîne et si vous utilisez la méthode d'itérateur, c'est trivial.

0

Je pense que je l'ai enfin compris votre problème, je vais reformuler ma question:

  • Vous avez une collection d'objets
  • Vous souhaitez que votre client d'avoir accès aux objets, sans connaître les détails de la mise en œuvre
  • la collecte et le client peut-être sur des machines différentes (vous avez donc un moyen de le mettre dans un message)

Je voudrais simplement renvoyer une copie de la collecti sur, convenablement emballé pour abstraire l'implémentation réelle.

Par exemple, une classe Collection, avec des membres begin et end pour accéder à des itérateurs personnalisés. La classe est instanciée avec la forme sérialisée de la collection et la désérialise (paresseusement ou non). C'est à votre client d'utiliser les itérateurs pour stocker les données dans la collection qu'il souhaite.

Questions connexes