Rückgabe eines vectors sinnvoll?

LordJaxom

...hat gegenüber der potentiellen Returnwertoptimierung bei zahlreichen Aufrufen aber den Nachteil der potentiellen Heap-Fragmentierung...

Will sagen: Es hängt wie immer stark vom Anwendungsfall ab.

hustbaer

gibt es eine besser Möglichkeit, von einer Funktion mehrere Werte zurückgeben zu lassen?

template <class OutIt> void Foo(OutIt oi)
{
    (*oi) = 1234;
    ++oi;
    (*oi) = 42;
    ++oi;
    // ...
}

CStoll

basti33 schrieb:

Ist dieser Lösungsweg sinnvoll oder gibt es eine besser Möglichkeit, von einer Funktion mehrere Werte zurückgeben zu lassen?

Wenn du eine jedes Mal die selbe Anzahl zurückgeben willst, ist der vector auf jeden Fall zu groß für die Aufgabe. Da ist std::pair (bzw. das erwähnt boost::tupel) wohl geeigneter - oder du verwendest Referenzparameter für die Rückgaben.

basti33

Artchi schrieb:

Entweder jemand gibt dir nen vector, den du nur noch füllst:
void foo(vector<string> &vec)
{
vec.push_back("Hallo");
vec.push_back("Welt!");
}

Die Lösung gefällt mir! Danke.

Edit: Von Smartpointern versteh ich leider zu wenig und kann daher nicht beurteilen, wie brauchbar sie sind.

Konrad Rudolph

Artchi schrieb:

jemand gibt dir nen vector, den du nur noch füllst:
void foo(vector<string> &vec)
{
vec.push_back("Hallo");
vec.push_back("Welt!");
}

Wo ist der Vorteil? Solchen Code generiert jeder halbwegs moderne Compiler doch sowieso über RVO.

CStoll

Gibst du eigentlich bei jedem Aufruf gleich viele Objekte zurück? Oder kann die Anzahl sich auch ändern? (wenn ersteres, ist der vector unnötig)

void foo(string& ret1,string& ret2)
{
  ret1 = "Hallo";
  ret2 = "Welt!"
}

thordk

wenns variabel viele sind, wozu gibs schliesslich die container klassen. allerdings sollte man anfangen mit referenzen zu arbeiten, wenns sehr viele elemente werden. man könnte allerdings auch auf OO umsteigen, dann braucht man keine methoden, die in einem rutsch zig elemente zurückgeben, mehr

hustbaer

man könnte allerdings auch auf OO umsteigen, dann braucht man keine methoden, die in einem rutsch zig elemente zurückgeben, mehr

??????????

asc

hustbaer schrieb:

man könnte allerdings auch auf OO umsteigen, dann braucht man keine methoden, die in einem rutsch zig elemente zurückgeben, mehr

??????????

Er meint wohl das er die Rückgabewerte in ein Objekt verpacken würde und als ein Objekt zurückliefert.

cu André

Krux

hustbaer schrieb:

man könnte allerdings auch auf OO umsteigen, dann braucht man keine methoden, die in einem rutsch zig elemente zurückgeben, mehr

??????????

das stimmt schon, wenn alle daten in klassen gekapselt sind, muss man sie nicht in der main hin und herschieben, allerdings weiß ich hier ja nicht den genauen Verwendungszweck.

Edit: ich glaube nicht dass er alles als objekt verpackt zurückgeben will, sondern, dass er die funktion als methode schreibt, die das objekt direkt manipuliert, und somit kein returntyp braucht.

hustbaer

Ich kann mir halt einfach keine Möglichkeit vorstellen wie man es umgehen soll Funktionen zu haben die z.B. Listen von irgendwas zurückliefern.
Macht für mich dabei keinen Unterschied ob die "Listen von irgendwas" dabei in ein "Objekt" verpackt ist oder als std::vector/std::list zurückkommt.

Oder ob ich jetzt einen "Proxy" zurückgebe der die "Listen von irgendwas" halt "lazy" erstellt, also immer nur das "berechnet" was angefordert wird. Oder ob ich einen Callback-Mechanismus verwende wie meine "output iterator" Version.

Letztendlich alles "a Nudl a Tag".

Badestrand

hustbaer schrieb:

man könnte allerdings auch auf OO umsteigen, dann braucht man keine methoden, die in einem rutsch zig elemente zurückgeben, mehr

??????????

Vielleicht meint er auch, dass man die Daten in einer Klasse kapselt damit sie so von keiner Funktion mehr zurückgegeben werden müssen.
Z.B. so (Pseudocode):

class Data
{
    void ComputeSomeData( input );
    vector<string> values;
};

Data mydata;
mydata.ComputeSomeData( input );

statt so:

vector<string> mydata = ComputeSomeData( input );

?

Krux

&Vector<Irgendwas> funktion(Vector<Irgendwas> v){
    //mache irgendwas mit dem Vektor v
    //...
    //...
    return v;
}

so würd ich das machen, denn ich denke es ist am sinnvollsten, wenn man ein Objekt immer im selben Block zerstört, wo es auch erstellt wurde (Konstruktor Destruktor sind die einzige ausnahme). Ist aber ungetestet.

Konrad Rudolph

Krux schrieb:

so würd ich das machen, denn ich denke es ist am sinnvollsten, wenn man ein Objekt immer im selben Block zerstört, wo es auch erstellt wurde

Nein. Das gilt nur für Zeiger auf Objekte.

hustbaer

Badestrand schrieb:

hustbaer schrieb:

man könnte allerdings auch auf OO umsteigen, dann braucht man keine methoden, die in einem rutsch zig elemente zurückgeben, mehr

??????????

Vielleicht meint er auch, dass man die Daten in einer Klasse kapselt damit sie so von keiner Funktion mehr zurückgegeben werden müssen.
Z.B. so (Pseudocode):
class Data
{
    void ComputeSomeData( input );
    vector<string> values;
};

Data mydata;
mydata.ComputeSomeData( input );
statt so:
vector<string> mydata = ComputeSomeData( input );
?

Igitt
Dann noch lieber per "non-const-ref Parameter"...

otze

Krux schrieb:

&Vector<Irgendwas> funktion(Vector<Irgendwas> v){
    //mache irgendwas mit dem Vektor v
    //...
    //...
    return v;
}

hmm du weist, dass die funktion ne referenz auf ein totes objekt zurückgibt?

//edit ausser natürlich das & ist überhaupt nicht beabsichtigt, da es ja auch an der falschen stelle ist...hmm

thordk

sieht vom konzept her nach ner reflexiven funktion aus.

vector<int> v;

funktion(v).push_back(12); // o.ä.

asc

thordk schrieb:

sieht vom konzept her nach ner reflexiven funktion aus.

Was aber nichts daran ändert das es falsch konzipiert ist (Referenzrückgabe, eines kopierten Objektes; Wenn schon in beiden Fällen eine Referenz oder eine Kopie). Wie otze auch schon angedeutet hat.

cu André

CStoll

Ich will euch in eurem Tatendrang ja nicht bremsen, aber vielleicht solltet ihr dem OP mal die Chance geben, das ganze zu verarbeiten (und eventuell genauer zu erklären, worum es ihm überhaupt mit der Frage ging).

thordk

CStoll schrieb:

Ich will euch in eurem Tatendrang ja nicht bremsen, aber vielleicht solltet ihr dem OP mal die Chance geben, das ganze zu verarbeiten (und eventuell genauer zu erklären, worum es ihm überhaupt mit der Frage ging).

ist doch immer so, dass simple fragen nach 10 seiten so sehr von der original frage abschweifen, dass sich der OP gar nicht mehr traut, reinzugucken

erstaunlicherweise passiert das bei komplexen fragen fast nie :p