[Video, Englisch, Herb Sutter]: Netter Vortrag zum Thema "modernes C++"

Dravere

Hab jetzt auch das Video geschaut. Es ist eine wirklich gute Präsentation, welche man ruhig gewissen Leuten zeigen sollte. Am meisten gefreut hat mich die Aussage: "Wir wollten variadic templates für VS11 bringen, haben es aber leider nur nicht ganz geschafft, da es ein wenig mehr Arbeit war, als wir erwartet hatten. Wir sind allerdings fast soweit und werden es liefern und das nicht erst in 2-4 Jahren."
Mit dem Service Pack?

Das Zitat (31:00) von Stroustrup über Garbage Collection und C++, kannte ich noch nicht. Aber sehr witzig

Grüssli

krümelkacker

XSpille schrieb:

Nur eine Aussage von Herb Sutter gefällt mir überhaupt nicht:

Herb Sutter schrieb:

instead of new, prefer make_shared as your default allocator

Ein so teurer Pointer als default?

Hast Du das mal ausprobiert? Bzw: Was lässt Dich glauben, dass make_shared langsamer als new ist?

Ich find's schade, dass es kein make_unique gibt. Dann hätte man sich neben "delete" auch "new" komplett sparen können in 99,9% aller Fälle. Außerdem hätte es Vorteile bzgl Ausnahmesicherheit.

void func(unique_ptr<foo>, unique_ptr<bar>) {}

int main() {
  func(unique_ptr<foo>(new foo), unique_ptr<bar>(new bar));
}

ist nicht Ausnahmesicher. Falls der foo- oder der bar-Konstruktor eine Ausnahme schmeißt, könnte das hier in einem Speicherleck enden. Die Reihenfolge der Auswertung ist ja nicht festgelegt. Bevor überhaupt irgendein unique_ptr existiert, kann schon ein Objekt erzeugt worden sein und beim zweiten eine Ausnahme fliegen. Mit make_unique würde das dann sicher sein:

void func(unique_ptr<foo>, unique_ptr<bar>) {}

int main() {
  func(make_unique<foo>(), make_unique<bar>());
}

da die make_unique-Funktion den rohen Zeiger sofort einem unique_ptr übergeben würde...

Ich glaube, das mit der Garbage Collection steht schon in D&E drin (The Design and Evolution of C++). Kann mich aber irren. Bin nur grad' zu faul, nachzugucken.

XSpille

Decimad schrieb:

Na ich weiß nicht, ob das wirklich eine so schlechte Aussage ist (falls da nicht auch irgendein Kontext gegeben war). Zu welchem Zweck hast du denn in deinem sauberen und modernen C++ Quelltext in letzter Zeit Objekte auf dem Heap alloziert?

Also generell sind Objekte, die ich auf dem Heap alloziere an irgendein Objekt gebunden. In der Regel programmiere ich mit Hilfe von boost-Libraries und da gibt es z. B. den boost::ptr_vector, der die Objekte wieder freigibt.
Kurzzeitig weise ich sie einem unique_ptr zu, dessen Objekt ich dann an den Vektor gebe.

#include <iostream>
#include <boost/ptr_container/ptr_vector.hpp>

struct Foo{
	Foo(int i){}
	~Foo(){ std::cout << "delete" << std::endl;}
};

struct Bar{
	boost::ptr_vector<Foo> vector;
	void add(std::unique_ptr<Foo>&& obj){
		Foo* foo = obj.get();
		vector.push_back(foo);
		obj.release();
	}
};

int main(){
	Bar bar;
	std::unique_ptr<Foo> ptr(new Foo(4));
	bar.add(std::move(ptr));
}

Solange der Zugriff ausschließlich durch einen Thread geschieht und der Besitz an einem Objekt hängt, sehe ich keine Nötigkeit zu shared_ptr...

Oben sollte man beachten, dass

vector.push_back(obj.release());

nicht threadsicher wäre...

Aber auch ohne boost, würde ich in der Regel ein

std::vector<std::unique_ptr<Foo> > vec;
	vec.push_back(std::move(std::unique_ptr<Foo>(new Foo(0))));

bevorzugen...

Klar ist es etwas mehr Arbeit, aber das ist mir lieber als so teuere Pointer...
Natürlich gibt es Situationen, wo Reference-Couting sinnvoll ist, aber es ist in meinen Augen bei weitem kein Default.

Gruß,
XSpille

Du sprichst hier Fälle an, bei denen die Zeiger "wegabstrahiert" werden nach außen, zu welchen Herb explizit sagt, dass man da alles rauskitzeln kann und direkt mit Zeigern arbeiten kann (oder unique_ptr, oder irgendwas.

Nochmal: Wofür allozierst du in deinem Quelltext Objekte auf dem Heap? (Nicht wie, denn mit make_shared werden sie ja auch gebunden, wie in deinen Beispielen).

krümelkacker

XSpille schrieb:

vec.push_back(std::move(std::unique_ptr<Foo>(new Foo(0))));

Vermeide überflüssige std::move-Aufrufe und bau Dir zwecks Ausnahmesicherheit ein make_unique. (siehe Deinen anderen Thread)

template<class T, class...Args>
inline unique_ptr<T> make_unique(Args&&...args) {
  return unique_ptr<T>(new T(std::forward<Args>(args)...);
}

Ich wüsste jetzt nicht, warum make_shared langsamer sein sollte als dieses make_unique.

Der Vorteil von unique_ptr ist aber, dass er ein release() anbietet.

314159265358979

XSpille schrieb:

vec.push_back(std::move(std::unique_ptr<Foo>(new Foo(0))));

Hier kannst du das move sowieso weglassen, wir habens hier ja schon mit einem RValue zu tun

Was shared_ptr angeht: Sehe ich so wie XSpille. Ich habe shared_ptr erst 1-2 mal gebraucht. In allen anderen Fällen hat mir unique_ptr gereicht.

XSpille

krümelkacker schrieb:

void func(unique_ptr<foo>, unique_ptr<bar>) {}

int main() {
  func(unique_ptr<foo>(new foo), unique_ptr<bar>(new bar));
}

ist nicht Ausnahmesicher.

Danke für den Hinweis! Generell wußte ich es, hätte es aber nicht beachtet ^^
Aber in der Regel, speichere ich solche Objekte vor dem Funktionsaufruf in Variablen, so dass es exceptionsicher ist. Naja... Oder im Forum mal in kurzer Form wie im Post oben Aber ist ja nur ein Parameter

krümelkacker schrieb:

Was lässt Dich glauben, dass make_shared langsamer als new ist?

Ich glaube nicht, dass es bei der Erzeugung (merkbar - eine zusätzliche 0 Zuweisung(?) und Mutex-Initialisierung(?)) langsamer ist, aber wenn man sich das Objekt aus dem Vektor holt und es zuweist, dann wird der Mutex zu erhöhen des Zählers gelöscht (oder sehe ich etwas falsch). Wenn man nur mit der Referenz auf den shared_ptr arbeitet, macht er ja nicht wirklich Sinn, oder? Und gerade in C++0x/C++11-Zeiten mit auto hat man so einen unnötigen lock schnell drin.

Gruß,
XSpille

XSpille

314159265358979 schrieb:

XSpille schrieb:
vec.push_back(std::move(std::unique_ptr<Foo>(new Foo(0))));
Hier kannst du das move sowieso weglassen, wir habens hier ja schon mit einem RValue zu tun

Da hast du allerdings Recht...
Da siehst du, dass ich wie ich im Post gerade gesagt habe, normalerweise erst in einer Variable zwischenspeicher...

EDIT: Ich glaub das std::move ist bezüglich Optimierung sogar schädlich

krümelkacker

XSpille schrieb:

Ich glaube nicht, dass es bei der Erzeugung (merkbar - eine zusätzliche 0 Zuweisung(?) und Mutex-Initialisierung(?)) langsamer ist, aber wenn man sich das Objekt aus dem Vektor holt und es zuweist, dann wird der Mutex zu erhöhen des Zählers gelöscht (oder sehe ich etwas falsch). Wenn man nur mit der Referenz auf den shared_ptr arbeitet, macht er ja nicht wirklich Sinn, oder? Und gerade in C++0x/C++11-Zeiten mit auto hat man so einen unnötigen lock schnell drin.

Da gibt's keinen Mutex. Der Referenzzähler wird eher als "atomic int" implementiert werden. So oder so hinkt der Vergleich auch, da Du unique_ptr nicht kopieren kannst, nur moven. Und bei shared_ptr's move-ctor erwarte ich, dass er genauso effizient sein wird, da hier der Referenzzähler gar nicht angefasst werden muss.

Was ich meine ist, dass euer Fokus im Moment total auf Exception-Safety in eurem Implementierungsdetail (Welchen außenstehenden interessiert schon, dass ihr Zeiger in einem vector speichert?) liegt. Zumindest liest es sich für mich im Moment so. (Zu denen Herb sagt: macht was ihr wollt um die volle Geschwindigkeit rauszukitzeln, wenn da unique_ptr und sowas nahe-optimal und automatisch Exception-Safe ist, nur zu!)

Ein anderer Fall wären allerdings geteilte Ressourcen oder solche dynamische Dinge, die tatsächlich die Schnittstellengrenzen überschreiten, bei denen die Lebenszeitverwaltung auch ohne Exceptions eine enorme Problematik darstellen kann. Hier halte ich den Ratschlag mit shared_ptr nicht für so abgrundtief falsch und mit make_shared natürlich bestmöglich umgesetzt.

Damit hat er doch eigentlich alles erschlagen, finde ich. Das Problem war maximal, dass er die Ausnahme (20 Minuten?) vor der Faustregel nannte.

314159265358979

In der MSVC Implementierung wirds über AtomicIncrement und AtomicDecrement gemacht. Gibt dazu auch ein nettes Video, das ich gerade nicht finde.

krümelkacker

@Decimad:

Wurde im Beispiel mit dem set<Widget> load_huge_data() nicht sowieso schon immer die Kopie wegoptimiert?

XSpille

krümelkacker schrieb:

Der Referenzzähler wird eher als "atomic int" implementiert werden.

Hatte ich nicht in Betracht gezogen... Aber somit hast du aber einen Zugriff der Caching verhindert(, oder?) und minimale Speicherverschwendung.

Herb Sutter schrieb:

macht was ihr wollt um die volle Geschwindigkeit rauszukitzeln, wenn da unique_ptr und sowas nahe-optimal und automatisch Exception-Safe ist, nur zu!

Ich bin (inzwischen ) absoluter Befürworter von unique_ptr.

krümelkacker schrieb:

So oder so hinkt der Vergleich auch

Klar kommt es auf die Anforderungen an. Aber in sehr vielen Fällen, benötigt man den Referenzzähler, der wie ich denke deswegen unnötig ist. Beim unique_ptr hat man auch einen leichten Overhead, der sich vermutlich auch manchmal wegoptimieren läßt(?), aber mit dem Bonus der Exceptionsicherheit.

Der shared_ptr hat zweifelsohne auch einen wichtigen Nutzen, jedoch (auch wenn) ich mich wiederhole, in meinen Augen sollte er nicht als 'default' verwendet werden.

EDIT: Für Objekte, die sich von verschiedenen Resourcen geteilt werden, ist für mich ein shared_ptr auch ein absolutes muss

314159265358979

Ich finde den Link zum Video nicht, wäre jemand so freundlich, ihn mir zu geben?

XSpille

Dravere schrieb:

Oder gleich hier:
http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-835T

Gerade streikte scheinbar der Server...

hustbaer

"that's not the pointer you're looking for"

krümelkacker

XSpille schrieb:

krümelkacker schrieb:

Der Referenzzähler wird eher als "atomic int" implementiert werden.

Hatte ich nicht in Betracht gezogen... Aber somit hast du aber einen Zugriff der Caching verhindert(, oder?) und minimale Speicherverschwendung.

Wo? Wann? Im Vergleich zu was? Wie gesagt, wenn Du einen shared_ptr move-konstruierst, muss man den Referenzzähler nicht anfassen. Und wenn du per make_shared das Ding erzeugst, bleibt es bei einer einzigen Allozierung. Gut, die fällt dann etwas größer aus, da "strong counter", "weak counter", und ein oder zwei Zeiger dabei ist/sind.

XSpille schrieb:

Beim unique_ptr hat man auch einen leichten Overhead, der sich vermutlich auch manchmal wegoptimieren läßt(?), aber mit dem Bonus der Exceptionsicherheit.

Was für ein Overhead? Wenn Du eine Implementierung verwendest, wo sizeof(unique_ptr<int>) != sizeof(int*) gilt, geh Dich beim Hersteller beschweren mit dem Stichwort "empty base class optimization". Sonst wüsste ich gerade nicht, was Du für einen Overhead meinen könntest.

hustbaer schrieb:

"that's not the pointer you're looking for"

Ja, da musste ich auch schmunzeln.

XSpille

krümelkacker schrieb:

Wo? Wann? Im Vergleich zu was? Wie gesagt, wenn Du einen shared_ptr move-konstruierst, muss man den Referenzzähler nicht anfassen.

Wann konstriert man einen shared_ptr denn mal per move? Ich gehe im Moment einfach von einem Vektor aus, über den ich iteriere. Entweder ich iteriere mit Hilfe einer Referenz auf die Objekte, dann brauch ich keinen shared_ptr, sondern kann auch einen unique_ptr nehmen oder einen Container, der den Besitz behält.
Ich glaube das ist so ein klassischer Fall. Sobald man natürlich jetzt mit mehreren Threads auf den Vektor zugreift und keine klare Zuordnung mehr hat, wem das Objekt gehört, dann ist natürlich ein shared_ptr auch meiner Meinung nach sehr zu empfehlen. Vielleicht denkst du gerade auch an einen komplett anderen Anwendungsfall und wir reden aneinander vorbei... Lass es mich wissen

krümelkacker schrieb:

Was für ein Overhead?

Sobald du eine virtuelle Funktion mit rvalue-Referenz als Parameter hast.
Als Programmierer, weißt du evtl. per Konvention, dass man das Objekt nach dem Funktionsaufruf nicht mehr löschen darf, aber der Compiler muss von beiden Fällen ausgehen und muss innerhalb der Funktion den Zeiger auf 0 setzen und der Destruktor von unique_ptr muss einen delete 0 ausführen

krümelkacker

XSpille schrieb:

krümelkacker schrieb:

Wo? Wann? Im Vergleich zu was? Wie gesagt, wenn Du einen shared_ptr move-konstruierst, muss man den Referenzzähler nicht anfassen.

Wann konstriert man einen shared_ptr denn mal per move?

Dann, wenn man ihn mit unique_ptr vergleichen will, zum Bleistift. Du behauptest doch, beim Einsatz von shared_ptr wo auch unique_ptr gereicht hätte, gäb's einen Laufzeit-Overhead. Wenn dem so ist, musst Du auch so fair sein, shared_ptr-Instanzen auch move-zu-konstruieren, da unique_ptr-Instanzen ja auch nie kopiert werden.

XSpille schrieb:

krümelkacker schrieb:

Was für ein Overhead?

Sobald du eine virtuelle Funktion mit rvalue-Referenz als Parameter hast.
Als Programmierer, weißt du evtl. per Konvention, dass man das Objekt nach dem Funktionsaufruf nicht mehr löschen darf, aber der Compiler muss von beiden Fällen ausgehen und muss innerhalb der Funktion den Zeiger auf 0 setzen und der Destruktor von unique_ptr muss einen delete 0 ausführen

Du schnippelst mir da zuviel vom Kontext weg. Ich weiß schon gar nicht mehr, worum's ging. *nochmal-nachguck* Aha, ein angeblicher Overhead von unique_ptr. Aber im Vergleich wozu? Zu einem Raw-Pointer? Naja, wenn Du überall einen raw-Pointer statt unique_ptr einsetzt und die fehlenden Operationen (delete) manuell ausführst, kannst Du dir vielleicht das ein oder andere Setzen/Überprüfen auf 0 sparen. Dass das irgendeinen nennenswerten Unterschied in der Laufzeit macht, wage ich zu bezweifeln.

[Video, Englisch, Herb Sutter]: Netter Vortrag zum Thema &quot;modernes C++&quot;

[Video, Englisch, Herb Sutter]: Netter Vortrag zum Thema "modernes C++"