Shared Pointer als unbenannter Parameter

[TNA]

Skym0sh0 schrieb:

Erklär mal mehr was du vorhast.

Die Funktion soll von einem Job asynchron ausgeführt werden und wird im dazu als std::function mit std::bind übergeben. Der Job selber hängt an einem Shared Pointer. Der Job muss garantiert mindestens so lange leben bis die Funktion ausgeführt wurde aber auch nicht länger, falls nicht nötig.

[TNA]

Arcoth schrieb:

Der Compiler darf die Seiteneffekte (um die es dir geht) nicht wegoptimieren.

Compiler optimieren doch ständig Kopien (z.B RVO) weg? Woher weiß der denn immer, dass die Kopien keine Seiteneffekte haben die ich gerne hätte?

[cooky451]

Indem er sicht die Konstruktoren und Destruktoren anschaut, natürlich. Aber das was du da machen willst klingt generell erst mal nach Schwachsinn. Kannst du das mal in einem kleinen Codebeispiel demonstrieren? (pref < 120 Zeilen)

[TNA]

cooky451 schrieb:

Aber das was du da machen willst klingt generell erst mal nach Schwachsinn. Kannst du das mal in einem kleinen Codebeispiel demonstrieren? (pref < 120 Zeilen)

Ich denke das wird schwierig. Ich denke ich habe schon recht erschöpfend erklärt was ich selber machen möchte. Das Jobinterface und die Implementierung ist nicht vom mir und darf ich hier auch nicht veröffentlichen.

Was ich machen möchte sieht in etwa so aus:

shared_ptr<job_t> myJob = make_Job("MyJob");
myJob->append_async_call(bind(myfunc,myjob));

[cooky451]

Ja, die Lebenszeit ist da garantiert, schwachsinnig sieht das allerdings immer noch aus.

[TNA]

Wirklich gefallen tut mir das auch so nicht, aber ich denke mit dem Job-Interface geht es nicht wirklich besser.

[Columbo]

TNA schrieb:

Compiler optimieren doch ständig Kopien (z.B RVO) weg?

Das ist eine Ausnahme. Du solltest auf jeden Fall folgenden Absatz kennen:

12.8/31 schrieb:

When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the copy/move constructor and/or destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy/move operation as simply two different ways of referring to the same object, and the destruction of that object occurs at the later of the times when the two objects would have been destroyed without the optimization¹²³.
This elision of copy/move operations, called copy elision, is permitted in the following circumstances (which may be combined to eliminate multiple copies):

• in a return statement in a function with a class return type, when the expression is the name of a non-volatile automatic object (other than a function or catch-clause parameter) with the same cv-unqualified type as the function return type, the copy/move operation can be omitted by constructing the automatic object directly into the function’s return value
• in a throw-expression, when the operand is the name of a non-volatile automatic object (other than a function or catch-clause parameter) whose scope does not extend beyond the end of the innermost enclosing try-block (if there is one), the copy/move operation from the operand to the exception object (15.1) can be omitted by constructing the automatic object directly into the exception object
• when a temporary class object that has not been bound to a reference (12.2) would be copied/moved to a class object with the same cv-unqualified type, the copy/move operation can be omitted by constructing the temporary object directly into the target of the omitted copy/move
• when the exception-declaration of an exception handler (Clause 15) declares an object of the same type (except for cv-qualification) as the exception object (15.1), the copy/move operation can be omitted by treating the exception-declaration as an alias for the exception object if the meaning of the program will be unchanged except for the execution of constructors and destructors for the object declared by the exception-declaration.

¹²³) Because only one object is destroyed instead of two, and one copy/move constructor is not executed, there is still one object destroyed for each one constructed.

Ersteres davon ist NRVO - das Dritte wird dann bei (N)RVO auch noch angewendet.

[Bashar]

Arcoth schrieb:

12.8/31 schrieb:

When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the copy/move constructor and/or destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy/move operation as simply two different ways of referring to the same object, and the destruction of that object occurs at the later of the times when the two objects would have been destroyed without the optimization¹²³.

Folgt aus dem letzten Satz nicht, dass es in diesem konkreten Fall egal ist, ob die Kopie wegoptimiert wird? Die Zerstörung findet zu dem Zeitpunkt statt, an dem das letzte der beiden Objekte (Kopie und Original) zerstört würde, also lebt der Smart-Pointer auf jeden Fall solange, wie er soll.

(Ich kann mir die RVO-Regeln nämlich nicht merken.)

[Columbo]

Bashar schrieb:

Folgt aus dem letzten Satz nicht, dass es in diesem konkreten Fall egal ist, ob die Kopie wegoptimiert wird?

Es ging nie um copy-elision, sondern darum, dass der ganze Parameter wegoptimiert wird, was natürlich nie erlaubt ist (außer vielleicht, wenn er ein Aggregat ist und nicht verwendet wird o.ä.).

Aber du hast Recht, das macht hier keinen Unterschied.

[Bashar]

Arcoth schrieb:

Bashar schrieb:

Folgt aus dem letzten Satz nicht, dass es in diesem konkreten Fall egal ist, ob die Kopie wegoptimiert wird?

Es ging nie um copy-elision

Compiler optimieren doch ständig Kopien (z.B RVO) weg?

Hab ich aus deinem Posting rauskopiert.

[Columbo]

Korrigiere: Es ging dem TE nie darum, das möglicherweise irgendeine Temporary elidiert wird, sondern es ging darum, ob der Parameter überhaupt existiert. Ob eine Temporary elidiert wird, ist, wie du ja sehen hast, vollkommen irrelevant, da irgendein shared_ptr -Objekt in der Funktion existieren muss.

[Bashar]

Das Zitat ist vom TE.

[Columbo]

Bashar schrieb:

Das Zitat ist vom TE.

Weiß ich. Ich habe darauf offensichtlich auch geantwortet.

Aber copy elision ist für sein Problem unwichtig. Denn das weg-optimieren von Kopien oder Parametern sind zwei völlig verschiedene Dinge, von denen für ihn nur letzteres zählt.

[Bashar]

Das Wegoptimieren von Kopien ist die einzige Optimierung, die das beobachtbare Verhalten ändern darf. Wenn es darum nie ging, ging es um nichts.

[Columbo]

Bashar schrieb:

Das Wegoptimieren von Kopien ist die einzige Optimierung, die das beobachtbare Verhalten ändern darf. Wenn es darum nie ging, ging es um nichts.

Gut erkannt.