Es gibt da ein Problem, dass in letzter zeit immer mehr an mir nagt: wie gibt man am geschicktesten in C++ eine Menge von Ausgabewerten zurück?
In meinem konkreten Fall habe ich das Problem, dass ich ein Bild analysiere und das Ergebnis eine ziemlich lange Liste von Vektoren ist. Diese wird dann von späteren Modulen weiterverarbeitet. Zusätzliche Anforderung ist, dass jedes Modul problemlos ausgetauscht werden kann, ohne dass es sich auf andere Module auswirkt.

Konkret sähe das Beispiel und die Lösungen die mir einfallen, so aus:

//Ansatz 1: direkte Rückgabe
//Nachteil: Rückgabe als Wert, Bindung an vector
class Foo
{
    public:
        std::vector<Vector> bar(Image image);
};
//Ansatz 2: Als Parameter
//Nachteil: Bindung an vector
class Foo
{
    public:
        void bar(Image image,std::vector<Vector>& container);
};
//Ansatz3: Als templateparameter
//Nachteil: Ich kann intern nicht die Datenstruktur so wählen, 
//wie ich sie zur Berechnung brauche sondern muss drauf
//Vertrauen, dass der Nutzer des Moduls mir das gibt was ich brauche
class Foo
{
    public:
        template<class T>
        void bar(Image image,Container& container);
};
//Ansatz4: Datenstruktur als Member und anbieten eines Iteratorinterfaces
//Nachteil: unschön. Allerdings die flexibelste Lösung
class Foo
{
    private:
        std::vector<Vector> container;
    public:
        void bar(Image image);

        std::vector<Vector>::const_iterator begin()const;
        std::vector<Vector>::const_iterator end()const;
};

Momentan favorisiere ich Lösung 4, weil ich so intern dem Modul jede Datenstruktur erlauben kann, ohne dass dies nach außen hin zu Änderungen führt. Fällt jemandem noch etwas besseres ein?

Das Problem ist, dass das Ergebnis des Algorithmus fast eine beliebig lange Liste sein kann(zwischen 1000 und ~10000 Vektoren). Es muss also schon ein dynamischer Container sein. Auch ist die Datenmenge groß genug, dass ich es mir mehrmals überlegen würde, sie zu kopieren, also fällt ein Container als Rückgabewert raus. Hinzu kommt, dass wenn ein anderer container eingesetzt wird, auch anderer Code direkt davon betroffen ist. Also nicht wirklich die beste Wahl. Alles andere wirkt auf mich aber auch ziemlich unschön.

Zusätzliche Anforderung ist, dass jedes Modul problemlos ausgetauscht werden kann, ohne dass es sich auf andere Module auswirkt.

D.h., auch ohne daß andere Module neukompiliert werden müßten?

Die Lösung würde ich davon abhängig machen, wie du dir die Besitzverhältnisse vorstellst. Wenn es sinnvoll ist, nur eine Range auf einen intern verwalteten Container beliebigen Typs zurückzugeben, würde ich mir einen Iterator-Wrapper schreiben, der beliebige Iteratortypen durch ein gemeinsames binäres Interface nutzbar macht, z.B. im Enumerator-Stil:

template <typename T>
    class IEnumerator
{
public:
    virtual void reset (void) = 0;
    virtual bool moveNext (void) = 0;
    virtual T& get (void) = 0;
};
typedef std::tr1::scoped_ptr <IEnumerator> IEnumeratorPtr;

template <typename T, typename IterT = T*>
    class IteratorEnumerator : public IEnumerator
{
    ...
public:
    IteratorEnumerator (IterT first, IterT last) { ... }
    ...
};

class Foo
{
public:
    IEnumeratorPtr bar (Image image);
};

Wenn aber das Besitztum des Containers auf den Aufrufer übergehen soll, wäre so etwas vielleicht besser:

template <typename T, typename ContT>
    class ContainerEnumerator : public IEnumerator
{
private:
    std::tr1::scoped_ptr <ContT> cont;
    ...
public:
    IteratorEnumerator (std::tr1::scoped_ptr <ContT> _cont)
     : cont (_cont)
    { ... }
    ...
};

Auch ist die Datenmenge groß genug, dass ich es mir mehrmals überlegen würde, sie zu kopieren, also fällt ein Container als Rückgabewert raus.

Dafür gibt's die "Return Value Optimization". Der MSVC kann's, der g++ laut kurzer Google-Nachfrage seit Version 3.1. Zum Lesen:
http://msdn.microsoft.com/en-us/library/ms364057%28VS.80%29.aspx

@otze: bist du sicher dass das Kopieren der Liste, im Vergleich mit dem Analysieren des Bildes, überhaupt lange dauert? Wenn das bloss ein paar Prozent sind, dann ... -> wurscht

@Badestrand: dein Link beschreibt die NRVO. RVO != NRVO. Und RVO würde in diesem Fall auch vermutlich garnix bringen.

Upsi, da hab ich was durcheinandergeworfen. Aber wie wär's mit 'nem aktuellen Compiler, greift bei Objekt-Rückgabe nicht die Move-Semantik?

Was du wahrscheinlich meinst, ist std::auto_ptr .

@ audacia: scoped_ptr ist nicht kopierbar (und zudem nicht in TR1).

Tatsächlich - das war ein Flüchtigkeitsfehler; ich meinte natürlich shared_ptr<> . Danke für den Hinweis.

hustbaer schrieb:

@Badestrand: dein Link beschreibt die NRVO. RVO != NRVO. Und RVO würde in diesem Fall auch vermutlich garnix bringen.

Upsi, da hab ich was durcheinandergeworfen. Aber wie wär's mit 'nem aktuellen Compiler, greift bei Objekt-Rückgabe nicht die Move-Semantik?

Nur wenn die Klasse die als Return-Typ verwendet wird move-semantics unterstützt. Was die std:: Container tun sollten (und in der STD-Lib vom 2010 Beta auch implementiert ist -- GCC weiss ich nicht, vermutlich auch).

Ich denke das wäre eine gute Möglichkeit: sich drauf verlassen dass es eh egal ist, und sobald man einen Compiler hat der r-value refs kann, fällt der (vermutlich minimale) Overhead dann auch noch weg.

Falls man wirklich draufkommt, dass es nicht egal ist, kann man sich immernoch über diverse Workarounds ein "move-by-swap" für die Standard-Container basteln. Siehe boost::move_t<>.

Wenn der Container nur als Ausgabe verwendet würde, d.h. die Funktion da nur reinschreiben muss, dann wäre die Standard-Lösung natürlich nen Output-Iterator zu verwenden.

Wenn die Funktion wirklich den Container braucht, z.B. um nachsehen zu können ob es schon einen Eintrag gibt, dann würde man mit der Output-Iterator Variante natürlich wieder sinnlos Daten kopieren. Ist aber IMO wirklich die Frage ob das nicht egal ist. Vor allem da es dann eine sehr saubere Trennung gäbe.

----

Oder ... ganz doofer Vorschlag:
Du könntest die Funktion als Input-Iterator implementieren (mit lazy evaluation, oder auch ohne)