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

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

  • X

    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 👍

    0
  • 3

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

    0
  • X

    Dravere schrieb:

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

    Gerade streikte scheinbar der Server...

    0

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

    0
  • K

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

    0
  • X

    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

    0
  • K

    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.

    0
  • V

    Auch Java ist nicht ernsthaft langsamer als C++. Wir sollten alle nach Java umsteigen.

    0
  • X

    Ich habe nur gesagt, dass es in vielen Fällen wie mit Kanonen auf Spatzen schiessen ist, wenn man einen shared_ptr verwendet. Abstrakt gefragt: Wozu in der Sahara statt eines normalen Stahlbolzen einen Bolzen verwenden, der bis -30°C haltbar ist?
    Ich denke es ist offensichtlich, dass er einen höheren Speicherverbrauch hat und dafür brauche ich ein Argument, das mir diesen rechtfertigt. Die 3 Zeilen Code sind es für mich nicht. Selbst wenn du das Objekt an mehreren Stellen verankerst ohne genaue Besitzdefinition ist für mich shared_ptr noch lange nicht zwangsläufig die richtige Wahl. Solange alles in einem Thread geschieht, reicht für mich ein 'normaler' nicht-threadsicherer Zähler aus. Wenn natürlich verschiedene Threads darauf arbeiten, würde ich ebenfalls einen shared_ptr verwenden.

    Wenn ich jetzt ein Pfennigfuchser wäre, dann würde ich sagen, dass bei einem move zusätzlich zum Kopieren des Zeigers auf das Objekt auch noch des Zeiger auf den Counter kopiert werden muss... Aber darum geht es mir eigentlich nicht.
    Mir geht es darum, dass alle immer den Porsche nutzen, obwohl ein Clio ausreicht.

    Bezüglich des unique_ptr:
    Ich bin (generell) ein Befürworter des unique_ptr und wollte nur klarstellen, dass er auch einen minimalen Overhead haben kann. Übrigens wollte ich ursprünglich 'meistens' statt 'manchmal wegoptimiert' schreiben, dachte mir aber sei lieber vorsichtig 😉 Ich sehe es absolut wie du, dass dieser Unterschied nicht nennenswert ist. Diesen nehme ich (i. d. R.) wegen Exceptionsicherheit gerne in Kauf. Hier habe ich einen klaren Nutzen.

    Wenn ich den Nutzen des threadsicheren Referenzzählers verwenden möchte, dann kann ich gerne den shared_ptr verwenden. Klar kommt das vor, aber nicht so oft, dass ich dessen Verwendung als 'default' anpredigen würde.

    0
  • ?

    (Herb Sutter, Microsoft) && modernes "C++" in einem Wort.
    Hahahahahahahahahahaha

    Die Deppen von M$ haben ja noch nicht mal die einfachsten Sachen von C++11 umgesetzt. Mit modernem C++ hat das garnichts zu tun. Das Ding überhaupt C++ zu nennen grenzt schon an frechheit.

    Nur zum vergleich:

    http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx

    vs

    http://gcc.gnu.org/gcc-4.7/cxx0x_status.html <----- So muss das aussehen

    Zum Glück kann ich richtig modern Programmieren unter einem richtig modernen OS (Linux)

    ________________________________

    "Es ist besser für den Pinguin zu Sterben, als zu Microsoft zu leben"
    - Mein Motto

    0
  • K

    Die Vortragende auf der Build-Konferenz wollen sich und ihr Produkt natürlich auch verkaufen. Das nervte schon ein bisschen.

    Gleich nachdem Sutter sagte, dass der Microsoft Compiler der erste gewesen sei, der Rvalue-Referenzen unterstützt hat, hat er sich korrigiert: einer der ersten Compiler.

    Bei seiner Verwendung von std::for_each in den Beispielen habe ich gedacht: "Das benutzt Du nur, weil ihr noch keine for-range-Schleife im Compiler implementiert habt". Aber einen Vorteil hat std::for_each dann doch noch. Es sagt genau das aus, was da passiert: Eine Schleife über alle Elemente, während im for-range Loop ein break versteckt sein könnte.

    Auch ich habe mich über den "prefer shared_ptr and make_shred as default over new" gewundert und an unique_ptr gedacht. Aber er relativiert das ja später...

    Ob der Microsoft-Compiler nun schon viel C++11 kann oder nicht, sein Vortrag ist immer noch gut.

    0

  • Linuxoid schrieb:

    (Herb Sutter, Microsoft) && modernes "C++" in einem Wort.
    Hahahahahahahahahahaha

    Die Deppen von M$ haben ja noch nicht mal die einfachsten Sachen von C++11 umgesetzt.

    Du hast genau gar nicht verstanden worum es bei modernem C++ geht.

    0

  • Ich glaub er hat auch keine Ahnung wer Herb Sutter ist...

    0
  • Z

    dot schrieb:

    Ich glaub er hat auch keine Ahnung wer Herb Sutter ist...

    Reicht wohl das Mr. Sutter bei Microsoft arbeitet, eingebildet 😃

    0

  • Linuxoid schrieb:

    Zum Glück kann ich richtig modern Programmieren unter einem richtig modernen OS (Linux)

    Na gottseidank, dann kannst du ja jetzt wieder spielen gehen, während die großen sich unterhalten...

    0
  • ?

    hustbaer schrieb:

    Du hast genau gar nicht verstanden worum es bei modernem C++ geht.

    Herb Sutter hat die ganze Zeit fast nur über die C++11 features gelabert.

    std::for_each in verbindung mit Lambdas,
    RValue Referenz,
    share_ptr unique_ptr,

    einiges ging auch schon mit c++98 (smart_pointer, vector)
    vieles aber nicht.

    Das kuriose ist, dass der MSVC++ der Compiler mit der schlechtesten C++11 unterstützung ist, also sollte HS aufhören das Teil als C++11 Compiler zu bezeichnen, sondern korreckt als C++0x Compiler oder C++98 mit baby C++11 features.

    0
  • A

    Linuxoid schrieb:

    Das kuriose ist, dass der MSVC++ der Compiler mit der schlechtesten C++11 unterstützung ist,...

    Das sehe ich etwas anders... Zumindest einiges der Funktionen die ich dringend vermisst habe sind enthalten (u.a. auto). Es gibt andere Compilerhersteller, wo man nur ansatzweise Änderungen zwischen den Versionen bemerkt (z.B. habe ich dieses Gefühl beim C++ Builder).

    0

  • Das Problem ist doch auch nicht der C++11 Support. Das eigentliche Problem ist doch, dass es von M$ ist und wenn ich was von M$ verwende, bin ich voll nicht 1337 alta, hab ich recht?

    0
  • K

    dass alle immer den Porsche nutzen, obwohl ein Clio ausreicht

    Wenn ich fuer das gleichen Preis einen Porsche bekomme, dann nehme ich wohl nicht den Clio.

    0
  • 3

    knivil schrieb:

    dass alle immer den Porsche nutzen, obwohl ein Clio ausreicht

    Wenn ich fuer das gleichen Preis einen Porsche bekomme, dann nehme ich wohl nicht den Clio.

    Der Porsche hat aber höhere Spritkosten.

    0
Anmelden zum Antworten