Auto und Smartpointer Performance

volkard

Ich bin dafür, daß husti mir geeignete Drogen bezahlt, damit ich ihn mir chemisch ausblenden kann.

SeppJ

hustbaer schrieb:

SeppJ schrieb:

Natürlich kostet der mehr als ein unique_ptr. Ist schließlich ein ganz anderes Konzept und keine Zauberei. Aber was soll das mit Threadsicherheit zu tun haben?

Das hat viel mit Threadsicherheit zu tun, weil atomare Operationen einfach viel viel teurer sind als nicht-atomare.

Ich bezog mich darauf, dass angedeutet wurde, dass shared_ptr deswegen langsamer wäre als unique_ptr, weil shared_ptr threadsicher ist. Dabei hat der shared_ptr vor allem erst einmal mehr/andere Funktionalität als unique_ptr und ist deswegen komplexer.

hustbaer

@SeppJ
Also es ging darum denke ich

Gast3 schrieb:

SmartPointer sind im Normalfall doch threadsafe (interner Counter) oder nicht?
das kostet definitiv - somit sollte ein std::shared_ptr mehr kosten als ein std::unique_ptr

Und aus meiner Sicht ist das halt einfach richtig.

Ich sehe das so:
shared_ptr muss die Zugriffe auf den internen Counter irgendwie threadsafe machen. unique_ptr muss das nicht (und hat auch sonst keinen erwähnenswerten Overhead).
Also muss shared_ptr langsamer sein als unique_ptr .

Das ist und bleibt mMn. einfach wahr, ganz unabhängig davon ob man auch anders zu dem Schluss "muss langsamer sein" kommen kann.

Damit hat der Umstand dass shared_ptr den Zugriff auf den internen Counter threadsafe machen muss sehrwohl etwas damit zu tun dass er langsamer ist/sein muss.

Im Gegensatz dazu muss "ist komplexer" aber nicht automatisch immer "ist langsamer" bedeuten.

SeppJ

Die Tatsache, dass shared_ptr überhaupt einen Zähler braucht und unique_ptr nicht, ist dabei nicht erwähnenswert? Das ist doch der Unterschied überhaupt!

hustbaer

OK, verstehe.
Doch, klar ist das erwähnenswert.

Macht aber die Überlegung von Gast3 mMn. immer noch nicht falsch. Vielleicht unnötig kompliziert, aber nicht falsch.

RHBaum

Macht aber die Überlegung von Gast3 mMn. immer noch nicht falsch.

Japp, aber die Konsequenz daraus sollte nicht sein, den shared_ptr als Klasse zu eliminieren, sondern 1 Stufe höher im Design, die Referenz-Zählung an sich.

Nur weil ich Instanzen auch in anderen Klassen verwende muss ich ja auch nicht üeberall Referenzzaehlung verwenden (COM Syndrom ^^ ist aber auch super bequem ! )
Ich muss halt nur nen eindeutigen Besitzer haben und den Lifecycle garantieren ^^ aka das der Besitzer alle Anwender überlebt ^^

Ciao ...

Techel

RHBaum schrieb:

1 Stufe höher im Design, die Referenz-Zählung an sich

Dann hast du einen unique_ptr. shared_ptr haben durchaus eine Berechtigung.

Problem ist das es scheinbar keine std::shared_ptr variante im Standard gibt bei der man das counter-locking beeinflussen/überschreiben kann - ergo sind alle std::share_ptr Nutzung in den meisten C++ Umgebungen erstmal threadsafe

ich finde es schade das man sowas im Standard nicht bedacht hat (und Zero Cost Abstraktion komplett ignoriert hat) std::string und std::string_view (in C++17) wäre da ein vergleich einer vom Standard erlaubten resourcenschonendere Nutzung

mein vorheriges Kommentar ziele eher darauf ab das die meisten gar nicht wissen mit welchen Kanonen da geschossen wird - kommt ja aus dem Standard und ist bestimmt alles super-schnell geil

RHBaum

kommt ja aus dem Standard und ist bestimmt alles super-schnell geil

Mit der Einstellung kann man sich sicher gut bei Fachzeitschriften (Heise Verlag) profilieren und dann Columnen schreiben, wo rauskommt, das C# die Schnellste Programmiersprache ist, kurz vor Java, und C++ weit abgeschlagen hinter Visual Basic liegt.

Das man ne std::mapstd::string,std::string mit nem Java Dictionary verglichen hat, kann man dann gut mit der "üblichen" Verwendung begründen

Sorry musste sein ...

Dann hast du einen unique_ptr. shared_ptr haben durchaus eine Berechtigung.

genau das mein ich doch
Es gibt durchaus Fälle wo shared_ptr ne Berechtigung haben, genau dann wo es keinen eindeutigen verantwortlichen(Besitzer) gibt ....
Und das sollte doch im Synchronen Context eher die seltene Ausnahme sein ...
Beio Multithreaded kann es sicher häufiger vorkommen, aber da hat der Lock ja dannn auch seine Berechtigung ...

Ciao ...

Sorry musste sein ...

du hast die einleitende Ironie im Vorsatz aber schon wahrgenommen - der mit den Kanonen und Spatzen - oder?