ich habe folgenden Codeauschnitt:

typedef std::vector<unsigned char> byte_buffer;

class split {

private:
	util::uid m_fuid;
	byte_buffer m_data;
	byte_buffer m_iv;
	byte_buffer_sec m_pw;

};
//-------------
generator::process() {
//....
	byte_buffer splitData( queue.MaxRetrievable(), 0);
	util::queueSource src( queue, true, new CryptoPP::ArraySink( splitData.data(), splitData.size()) );

	return split( fuid, splitData , m_iv, plainDigest);
}
//-------------

api::split::split split( gen.process() );

Die Frage dazu ist wie ich es jetzt schaffe damit der Vector beim split Ctor nicht kopiert wird.
Und der split selber sollte auch nicht kopiert werden.

Das Problem bei splitDatadas ist, das die groesse zwischen 1 - 50 MB sein kann.

Ich bentutze VS2010 falls das wichtig ist wegen C++11 features.

Gruessle stuxn

Ich meine das wird wegoptimiert, Stickwort Copy-Elision und Return Value Optimization.

Hmm also bei split irgendwie nicht. Wenn ich den Copy-Ctor im private Bereich erstelle kann ichs nicht mehr Kompilieren.

Ja, verbieten darfst du die Kopien auch nicht. Denn dann lässt du eine Kopie ja nicht zu. Aber du willst das kopieren in manchen Fällen ja "nur" verschnellern.

Es ist nur so, dass bei einem temporären Returnwert, das Ergebnis (also das temporäre Objekt) ja nichtmehr gebraucht wird (in der Funktion/Methode), daher kann man dieses auch direkt in das Zielobjekt schieben.

Ich meine das wird wegoptimiert, Stickwort Copy-Elision und Return Value Optimization.

Wie sollte dann der Ctor von split sein damit der vector nicht kopiert wird.

split(const byte_buffer& buf) : m_data(buf) {}

so?
Und dann wuerde unter umstaenden der vector gemoved werden (mit optimierung an usw).

Oder koennte ich den mit:

split(byte_buffer&& buf) : m_data(buf) {};

byte_buffer data(1024,0);
return split( std::move( data) );

dazu zwingen?

Skym0sh0 schrieb:

Regel Nummer 1: Optimierungen anschalten, sonst macht der Compiler je nachdem gar nix.

Ja, verbieten darfst du die Kopien auch nicht. Denn dann lässt du eine Kopie ja nicht zu. Aber du willst das kopieren in manchen Fällen ja "nur" verschnellern.

Es ist nur so, dass bei einem temporären Returnwert, das Ergebnis (also das temporäre Objekt) ja nichtmehr gebraucht wird (in der Funktion/Methode), daher kann man dieses auch direkt in das Zielobjekt schieben.

Ok macht Sinn ja. Haette aber schon gedacht das zumindestens sowas wie Return Value Optimization auch in der Debug Version mit dabei ist.

Und wenn du schonmal mit dem Debugger durch die Release Version eines Programms gegangen bist, dann weiste ja wie das aussieht und was da alles wegfällt...

split(const util::uid& uid,byte_buffer&& data,const byte_buffer& iv,  const byte_buffer_sec& pw) :
	  	m_fuid( uid), m_data( data), m_iv(iv), m_pw(pw)
	{
	}
//---------------
split func() {
	byte_buffer splitData( queue.MaxRetrievable(), 0);
	util::queueSource src( queue, true, new CryptoPP::ArraySink( splitData.data(), splitData.size()) );

	return split( fuid, std::move(splitData) , m_iv, plainDigest);
}

Beim Aufruf der letzten Zeile, wird trotzdem der Copy-Ctor von Vector aufgerufen. Das sollte doch eingentlich nicht sein oder.

Nochmal kurz beschrieben. Ich habe folgenden Code:

class split {

public:

	split(const util::uid& uid,byte_buffer&& data,const byte_buffer& iv,  const byte_buffer_sec& key) :
	  	m_fuid( uid), m_data( data), m_iv(iv), m_key(key)
	{
	}
	split(split&& rhs) :
		m_fuid( rhs.m_fuid), m_data( std::move(rhs.m_data) ), m_iv(rhs.m_iv), m_key(rhs.m_key)
	{
		std::cout << "move copy\n";
	}
	const util::uid& fuid() const { return m_fuid; };
	const byte_buffer& data() const { return m_data; };
	const byte_buffer& iv() const { return m_iv; };
	const byte_buffer_sec& key() const { return m_key; };

	tstring serialize(const byte_buffer ) const;
private:
	split(const split& rhs);
	util::uid m_fuid;
	byte_buffer m_data;
	byte_buffer m_iv;
	byte_buffer_sec m_key;
};

//-----------
split func() {
//.......
	encryptQueue( queue, plainDigest); // hier wird buffer per aes256 verchluesselt
	util::uid fuid = generateUid( queue );

	byte_buffer splitData( queue.MaxRetrievable(), 0);
	util::queueSource src( queue, true, new CryptoPP::ArraySink( splitData.data(), splitData.size()) );

	return split( fuid, std::move(splitData) , m_iv, plainDigest);
	//return split();
}

Nun wird in meinem Test der Buffer( zwischen 1 - 50Mb) mit gzip compressed & mit aes256 encrypted. Danach wir der Split zurueck gegeben und wieder decrypted, decompressed und auf die Platte geschrieben.

Das Problem ist aber das laut dem VS2010 Profiler ca 69% der Zeit dem Aufruf von

return split( fuid, std::move(splitData) , m_iv, plainDigest);

zuzurechnen ist.
Und per Debugging wird ersichtlich das der Vector nicht gemoved sonder per Copy-Ctor erstellt wird im Split-Ctor.

Was mache ich falsch?

Mit freundlichen Gruessen

Aber bei nochmaligen drübergucken ist mir das hier aufgefallen:

stuxn schrieb:

class split {
public:
	split(const util::uid& uid,byte_buffer&& data,const byte_buffer& iv,  const byte_buffer_sec& key) :
	  	m_fuid( uid), m_data( data), m_iv(iv), m_key(key)
	{
	}

das m_data(data) müsste m_data(std::move(data)) heißen; denn data ist eine benannte Rvalue-Referenz und damit ein Lvalue-Ausdruck. Klingt widersprüchlich, ist aber doch logisch, weil Lvalues ja gerade die Dinger sind, die "einen Namen haben". Du kannst dich mit dem Namen "data" mehrfach auf ein und dasselbe Objekt beziehen. Das wär eine schlechte Idee, wenn es jedes Mal als Rvalue behandelt würde, weil der Zustand durch andere Move-Operationen klammheimlich sich verflüchtigen könnte, ohne dass man das will. Deswegen brauchst du hier ein explizites move.

Allerdings würde ich es eher so wie hier machen:

struct foo
{
  vector<int> v;

  explicit foo(vector<int> temp) // pass by value ist absicht. soll sich doch
  : v(move(temp))                // der compiler drum kümmern, wie das ding
  {}                             // zustande kommt. der move nach v ist ja
};                               // quasi kostenlos (gegenüber der kopie).

foo bar()
{
  vector<int> v;
  ...
  return foo(move(v));
}

Der Unterschied ist, dass hier der Konstruktor auch mit einem Lvalue aufrufbar ist, wobei in dem Fall der Vektor kopiert würde. Du hast also mit einem Konstruktor mit pass-by-value Parameter beide Fälle erschlagen.

Laut C++11 Regeln bekommt foo vom Compiler generierte Kopier- und Move-Operationen, die elementweise kopieren und moven. Falls Dein Compiler noch keine Move-Operationen für eine Klasse selbt generieren kann und auch die =default;-Syntax noch nicht beherrscht, musst du die leider selbst schreiben.

Also, Fragen bzgl C++11 Features beantworte ich eigentlich gerne (wenn ich das denn kann). Aber ich muss gestehen, dass dieser Thread hier etwas abschreckend ist. Erst wusste ich nicht so, wo das Problem ist, bzw welche Kopie du vermeiden willst und dann gibts hier so viel Code, den man noch stark hätte vereinfachen können...

Ja stimmt haette man in ein verstaendliches Beispiel packen koennen. Tut mir leid ich versprech Besserung.

krümelkacker schrieb:

...
Der Unterschied ist, dass hier der Konstruktor auch mit einem Lvalue aufrufbar ist, wobei in dem Fall der Vektor kopiert würde. Du hast also mit einem Konstruktor mit pass-by-value Parameter beide Fälle erschlagen.

Laut C++11 Regeln bekommt foo vom Compiler generierte Kopier- und Move-Operationen, die elementweise kopieren und moven. Falls Dein Compiler noch keine Move-Operationen für eine Klasse selbt generieren kann und auch die =default;-Syntax noch nicht beherrscht, musst du die leider selbst schreiben.

Super danke hat wunderbar funktioniert. Muss unbedingt nochmal ueber das ganze RValue Theme drueberschaun. Bin da noch nicht 100% drin.
Aber hoert sich auf jeden Fall logisch an.

Das =default kannt ich noch gar ned. Aber leider unterstuetzt das VS2010 nicht :(.

Jetzt sagt mein Profiler auch das das compressen die Zeit verbraet.

Vielen dank und gute Nacht.
stuxn

Regel Nummer 1: Optimierungen anschalten, sonst macht der Compiler je nachdem gar nix.

Ja, verbieten darfst du die Kopien auch nicht. Denn dann lässt du eine Kopie ja nicht zu. Aber du willst das kopieren in manchen Fällen ja "nur" verschnellern.

Es ist nur so, dass bei einem temporären Returnwert, das Ergebnis (also das temporäre Objekt) ja nichtmehr gebraucht wird (in der Funktion/Methode), daher kann man dieses auch direkt in das Zielobjekt schieben.

Optimierungen verändern doch nicht die Semantik ...

Skym0sh0 schrieb:

Ich meine das wird wegoptimiert, Stickwort Copy-Elision und Return Value Optimization.

Hmm also bei split irgendwie nicht. Wenn ich den Copy-Ctor im private Bereich erstelle kann ichs nicht mehr Kompilieren.

Es steht schwarz auf weiss im Standard, dass der Compiler in den Fällen wo er eine Kopie "weglassen" darf, trotzdem prüfen muss, ob es einen Copy-Ctor gibt der an der Stelle verwendet werden könnte und dürfte.

Es ist also per Definition nicht möglich durch private machen des Copy-Ctor zu prüfen ob der Compiler copy-elision macht.

Der Sinn dahinter ist, dass es anders furchtbar verwirrend wäre. Dann würde es nämlich drauf ankommen wie schlau der Compiler ist, ob du einen bestimmten Code compilieren kannst oder nicht. Und eine kleine Änderung die mit der kopierten Klasse gar nichts zu tun hat, könnte dazu führen dass es auf einmal nicht mehr geht.