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

[krümelkacker]

volkard schrieb:

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.

[Dravere]

krümelkacker schrieb:

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

[Gast]

Seid ihr Eigentlich auch so feindlich gegenüber der Entscheidung von MS, per Spracherweiterung das "neue" COM mit in die Programmiersprache zu bauen? Die Jungs in der Kommentarliste auf der build-Seite waren da ja sehr militant irgendwie.

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?

[Zeus]

Windows 8 wird auf Desktoprechner floppen, evtl ist die Orientierung auf Tablets nicht zu übersehen, aber eine Desktop, wo die Startleiste nur 4 Befehle kennt und ein Explorer der eher auch Poweruser glücklich machen soll - Microsoft's Aussage. Zu Widersprüchlich. Endlich mit C# native Programme zu bekommen, aber nur für Metro. Hmpf. Im Detail sehr spannend, aber zusammengesetzt reißt es nicht vom Hocker.

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

[XSpille]

Interessantes Video...

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?

[Gast]

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?

[Dravere]

Decimad schrieb:

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

[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

[Gast]

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.

[Gast]

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:

[hmmmmmmmm]

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