Lese-/Schreib-Unterschiedung beim []-Operator, die 2.

Nathan

Spaghettimann schrieb:

Nathan schrieb:

Wenn du COW willst: COW macht keinen Sinn bei Multithreading, a.k.a. lass es.

Och aber damit umgehe ich doch das lästige kopieren. Ich habe mir den alten Artikel nicht wirklich durchgelesen, schon alleine, weil sich hier nicht alle einig waren, aber wenn ich jetzt nicht 'multithreadde' ist das doch schon ein Vorteil oder?

Spontan fällt mir z.B. dies ein:
array<int> ai;
ai.InitAlleInts();

array<array<int> > aai;
aai.SetzeAnIdx0(ai);
Wen ich das jetzt ohne COW mache, habe ich nachher 2 ais. 1 (im Array-Array) wäre mir aber genug. Aber fürs Init muss ich ja i.A. immer erst ein "echtes" Objekt erstellen..

Wie viele Stunden hängst du da jetzt schon dran?
Und die Optimierung wirst du im seltensten Fall merken.
Lass es einfach, wenn du wirklich Performanceprobleme hast, die an zu vielen Kopien liegen, komm nochmal.

Wie viele Stunden hängst du da jetzt schon dran?

Jaaa - zu viele, besonders an der Proxy(-Proxy)-Geschichte. Vor allem, wenn man mal davon ausgeht, dass ich es jetzt wohl doch 'billig' machen werde, oder doch gleich nen vector nehme (...leider...;) )..

Und die Optimierung wirst du im seltensten Fall merken.

Das war mir schon bewusst. Mir ging es eher ums Prinzip. Zur Übung sozusagen.. Viel mehr werde ich leider aus der Geschichte auch nicht mitnehmen können, wies aussieht.

hustbaer

Nathan schrieb:

Wenn du COW willst: COW macht keinen Sinn bei Multithreading, a.k.a. lass es.

Wieso denn das?
Klar macht COW auch Sinn bei MT. Über shared_ptr geht das sogar recht schön.

void write()
{
   if (!m_guts.unique())
      m_guts.reset(new Guts(*m_guts));

   m_guts->write();
}

Ist einzig doof wenn die write Operationen ziemlich billig und ziemlich häufig sind. Dann könnte der Overhead des threadsicheren shared_ptr bemerkbar werden.