Das Publikum ist ein Mischmasch von Programmierern mit unterschiedlichen Backgrounds (C++, C#, Java, JavaScript).

Ich find' den Vortrag gut, weil er genau das rüberbringt, was viele Umsteiger (von X zu C++) oder Anfänger wissen sollten - nämlich: wie gutes, modernes C++ aussieht. Da geht es um "Value Types" vs "Reference Types", scope-based life-time, Ausnahmesicherheit, C++11 Neuheiten (sofern sie von Microsoft schon unterstützt werden), etc.

Ein paar Fehler tauchen zwar hier und da auf den Folien auf...

vector<unique_ptr<dings>> nodes;
...
nodes.push_back(new dings);

darf nicht kompilieren, da unique_ptr's Konstruktor explicit ist. Oder:

class circle : shape {...

Hier hat er "public" vergessen.

...aber so schlimm ist das jetzt nicht. Sind halt eher Flüchtigkeitsfehler.

Oder:

class circle : shape {...

Hier hat er "public" vergessen.

Das war evtl C++/CLI.

krümelkacker schrieb:

Oder:

class circle : shape {...

Hier hat er "public" vergessen.

Das war evtl C++/CLI.

Nein, es geht zu 99% um C++. Am Ende sieht man etwas C++/Cx und WinRT.

Den Video-Link findet ihr auf dieser Seite:
http://www.reddit.com/r/cpp/comments/kirs4/writing_modern_c_code_how_c_has_evolved_over_the/

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

Danke für die Erinnerung. Hab darauf gewartet, dass das Video hochgeladen wird. Werde es mir wahrscheinlich heute dann ansehen, sofern ich Zeit finde

Grüssli

C++ fehlt ja an sich eine gute Anbindung nach außen (außer der C-Variante, die Herb da so schön zusammenfasst) und man ist dann so oder so auf plattformabhängige Wege angewiesen. Da freue ich mich doch, wenn ein solch einfacher Weg angeboten wird, mit der Plattformwelt zu kommunizieren. Schade natürlich, dass WinRT nur in der Metro-Umgebung vorhanden ist, zumindest meine ich gelesen zu haben, dass man es nicht in der Desktopumgebung benutzen kann.

Was meint ihr dazu?

Nachtrag: ops thema verfehlt, sollte doch mehr um C++ drehen

Es zeigt mir, dass mein C++, das ich schreibe schon ziemlich modern ist

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?

C++ fehlt ja an sich eine gute Anbindung nach außen (außer der C-Variante, die Herb da so schön zusammenfasst) und man ist dann so oder so auf plattformabhängige Wege angewiesen. Da freue ich mich doch, wenn ein solch einfacher Weg angeboten wird, mit der Plattformwelt zu kommunizieren. Schade natürlich, dass WinRT nur in der Metro-Umgebung vorhanden ist, zumindest meine ich gelesen zu haben, dass man es nicht in der Desktopumgebung benutzen kann.

Ist zwar ein wenig im falschen Thread, siehe:
http://www.c-plusplus.net/forum/292706

Aber gebe jetzt trotzdem hier eine Antwort. Ich hab bis anhin wenig über WinRT gelesen und habe nun angefangen mich damit zu beschäftigen. Sicher ist es grundsätzlich toll, da es eine eher angenehme OO Schnittstelle anbietet. Aber eine Anbindung über eine C Schnittstelle, konntest du auf Linux, Mac, jeglichem Windows, usw. verwenden. Es gibt auch noch mehr Anbindungsmöglichkeiten, welche Herb Sutter nicht gezeigt hat und plattformunabhängig sein können (z.B. über TCP/IP Protokolle). WinRT geht nur auf Win8 und nur für Metro. Ich sehe daher aktuell C++/CX nur als Schnittstellensprache, um eine C++ Bibliothek im Metro UI zu benutzen. Grundsätzlich ähnlich wie C++/CLI, was man nur benutzt, wenn man eine C++ Bibliothek in .Net benutzen möchte.
Der Nutzen davon erscheint mir daher sehr fragwürdig zu sein. Vor allem wenn man den Metro Bereich zu .Net (also C++/CLI) vergleicht, dann ist Metro ein verdammt kleiner eingeschränkter Bereich. Der Einsatzzweck von C++/CX sehe ich im Bereich des Desktops grundsätzlich fast gar nicht. Bei mobilen Geräten mit Win8 dagegen könnte es durchaus interessant werden. Aber das ist schlussendlich aktuell eher ein Nischenbereich.

Man muss sehen, was die Zukunft bringt.

Grüssli

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

Grüssli

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.

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

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).

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.

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.

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 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

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.

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.

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

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

Gerade streikte scheinbar der Server...