Frage: Welche Variante ist Laufzeitechnisch und v.a. speichertechnisch unter der Anahme von laaaaangen, speicherintensiven vektoren zu bevorzugen?

Wie oft wird bei A, B und C kopiert ?

Ich gehe derzeit von folgenden worst case Szenarien aus (also ohne compiler-optimierungen):
A 1 Kopie bei return tmp
B 1 Kopie bei return tmp, 1 Kopie durch aufruf des copy-konstruktos von vector
C 1 Kopie bei return tmp, 1 Kopie durch aufruf des zuweisungs-operator von vector

Liege ich da falsch?

Wird bei return tmp immer eine Kopieraktion durchgeführt oder verhindern das gute compiler, wenn man den return Wert anschließend zuweist und dieser auf eine lokale Variable verwies?

int mina(){
    X a;
    vector<XYZ> v;
    a.fill(&v); //Oder als referenz
}

Version A ist nicht gültig. Du gibst von der Methode die temporäre(!) Kopie eines lokalen Objekts zurück und willst nur eine Referenz darauf weiternehmen. Wenn das der Compiler zuläßt kommt es zu undefiniertem Verhalten.
Version B ist potentiell das beste, weil dort das Rückgabeergebnis gleich zum Initialisieren des vectors verwendet wird.
Bei Version C muß erstens das alte in vec2 gelöscht, dann alles kopiert werden.

bis bakd
akari

Da bei deiner getVector Funktion der Vector gefüllt wird, würde ich sowas vorschlagen.

int mina(){
    X a;
    vector<XYZ> v;
    a.fill(&v); //Oder als referenz
}

so, mache ich das i.d.R. auch. Aber hin und wieder ist diese Funktionaliät nicht gegeben. Mich interesiiert grad das allgmeine Verhalten. Zumal ich auch gelesenhabe, dass manche Compiler automatisch das von dir gewünschte zur Compilezeit umsetzen.

@akari:
version a verwende ich wenn dann auschließlich temporär in einem scope. niemals länger.
z.B.

void writeGeoFiles(X a)
{
   vector<XYZ>& v = a.getVector();   
   ...
   for_each(...) file.write(...);
   ...
}

bisher verwende ich ausschließlich Version A für solche fälle und hatte damit noch keine probleme (weder mit cl, gcc3.x, 4.x oder intel compiler).
ist es bei dem genannten bsp auch undefiniert?

gekärt werden müsste jetzt die frage mit ob A auch in dem von mir genannten weiten Bsp undefniert ist und vor allem würden mich die kopieroperationen interessieren (siehe topic)

Also mein GCC meckert zu Recht wie ich erwartet habe

std::vector<int> Test()
{
  return std::vector<int>();
}
...
std::vector<int>& test = Test();
test.push_back(10);

invalid initialization of non-const reference of type ... from a temporary of a type ...

Interessant ist das mit einer const Referenz kompiliert wird. Meines Erachtens sollte aber dann bei jedem Lesen von test auf ungültiger Speicher zugriffen werden.

bis bald
akari

gekärt werden müsste jetzt die frage mit ob A auch in dem von mir genannten weiten Bsp undefniert ist...

Grundsätzlich sehe ich keinen Grund warum dein Fall A jemals definiert sein sollte. Temporäre Ergebnise sind nach dem zuweisen undefiniert. Vermeide Kopien wo es möglich ist, aber unterbinde sie niemals wo es nötig ist.

cu André

- Du definierst in getvector() einen vector tmp, der eigentlich nur genau innerhalb dieser Methode existiert.
- durch das return statement existiert tmp noch einen kleinen Tick laenger, naemlich um den Ergebniswert ggf einer anderen Variablen zuweisen zu koennen, wird danach aber doch zerstoert. (im Grunde wird eine temporaere Variable ohne Namen angelegt, die den inhalt von tmp kopiert. das wird aber meist wegoptimiert)
- durch die Zuweisung an eine Referenz (v) verweist diese Referenz auf tmp bzw. auf die temporaere Variable, die sofort nach der Zuweisung zerstoert wird. v ist also von Anfang an eine Referenz auf ein nichtmehr existierendes Objekt -> undefiniert.

struct X1{
vector<XYZ>& getVector() { return m_a; } 
vector<XYZ> m_a;
};

int main() { X1 a; vector<XYZ>& vec = a.getVector(); }

Du kannst deinen vector in getVector mit new erstellen und dann den Pointer zurück geben und wieder löschen, wenn du ihn nicht mehr brauchst. es gibt auch noch diese auto_ptr, oder wie die heißen, die das wohl automatisch machen.

stimmt... die auto_ptr idee ist gut. andernfalls generiert man sich leicht nen speicherloch.

Warum dir die Option nicht zur Verfuegung stehen sollte sei mal dahingestellt (ich kann mir kein Szenario vorstellen das sowas verbietet).
Warum version A undefiniert ist, nehme ich mal kurz auseinander:

- Du definierst in getvector() einen vector tmp, der eigentlich nur genau innerhalb dieser Methode existiert.
- durch das return statement existiert tmp noch einen kleinen Tick laenger, naemlich um den Ergebniswert ggf einer anderen Variablen zuweisen zu koennen, wird danach aber doch zerstoert. (im Grunde wird eine temporaere Variable ohne Namen angelegt, die den inhalt von tmp kopiert. das wird aber meist wegoptimiert)
- durch die Zuweisung an eine Referenz (v) verweist diese Referenz auf tmp bzw. auf die temporaere Variable, die sofort nach der Zuweisung zerstoert wird. v ist also von Anfang an eine Referenz auf ein nichtmehr existierendes Objekt -> undefiniert.

danke für die erklärung

muffmolch schrieb:

okay. das hilt mir schon mal enorm weiter... dann werde ich hier version B verwenden.
nur zur sicherheit. A ist aber erlaubt bzw. sogar pflicht (wenn nachhaltig memberdaten auf dieseunschöne weise ändern möchte) bei:

struct X1{
vector<XYZ>& getVector() { return m_a; } 
vector<XYZ> m_a;
};

int main() { X1 a; vector<XYZ>& vec = a.getVector(); }

Ja das ist in Ordnung und sinnvoll. Aber eben auch ein großer Unterschied, da hier eine Referenz auf eine Membervariable zurückgegeben wird und nicht eine temporäre Kopie einer lokalen Variable.

bis bald
akari

vector< vector<int> > vec;
...
vector<int>& internal_vec = vec[2];
internal_vec[3] = 4;  //1
vec[2][4] =5;         //2

1 und 2 führen beide eine zuweisung durch. ist 1 auch durch den direkten zugriff schneller als 2, denn dort muss er zuerst ja wieder vec[2] aufrufen.

Naja bei einem einzigen Effektiven Zugriff hast du natürlich keinen Vorteil davon.
Wenn du aber mehrmals hintereinander auf den gleichen internal_vec zugreifen willst dann ist das sehr wohl effizienter.

bis bald
akari

Hallo
Naja bei einem einzigen Effektiven Zugriff hast du natürlich keinen Vorteil davon.
Wenn du aber mehrmals hintereinander auf den gleichen internal_vec zugreifen willst dann ist das sehr wohl effizienter.
bis bald
akari

selbstredend. sondern eben bei schleifen wie:

vector< vector<int> > vec;
...
for(int i=(int)vec.size()-1; i>=0; ++i){
   vector<int>& internal_vec[i];  
   for(int j=(int)vec[i].size()-1; i>=0; ++j) internal_vec[j] = i*j;
}

Frage: Welche Variante ist Laufzeitechnisch und v.a. speichertechnisch unter der Anahme von laaaaangen, speicherintensiven vektoren zu bevorzugen?

Variante

vector<XYZ>  vec;
X a;
a.getVector().swap(vec);

Dass das meist nicht gemacht wird, bedarf keiner Erklärung. In gewisser Weise ist das eine Art manuelles move - mit C++0x wird das unnötig werden.