[aspectc-user] overloaded operator ++() and ++(int)

[Hans VB]

Hello,

>
> To summarize: It is (1) not guaranteed that the copy constructor will 
> be  executed. If it is executed, the execution is not in the cflow of 
> your operator++ (2).

I'm not sure I understand how i can not be guaranteed. This is not 
standard behaviour? (i.e. compilers have different behaviour in this? I 
did notice g++ has no problem with returning references with conversion 
operators, while vc++ does have)

>
> Now AspectC++ come into play: If you weave execution advice for the 
> operator ++ the generated wrapper function will allocate memory space 
> for the result object and initialize it with the result of the orginal 
> (wrapped) function by using the copy constructor. This copy 
> construction can't be avoided by compiler optimizations. This copy 
> constructor execution is *in* the cflow! However, this temporary 
> result object is then return by the wrapper function to the caller, 
> which might again result in a copy constructor execution. This 
> (second) copy construction is not in the cflow! That's how it is 
> currently implemented. Can you confirm that the copy constructor is 
> executed twice in your code?
>
my recap :

A function returning an object (not a reference ofcourse) will call the 
copy constructor. If execution-advice is attached to this function, that 
copy constructor will be in the cflow of the execution, since it is used 
to copy the return value to the local return-storage of the 
execution-advice.
The execuction-advice itself on the other hand returns its local copy 
which in turn calls the copy constructor. This copy constructor is not 
in the execution-advice, but should belong in call-advice.

I only detect one relevant constructor-call though. Of which I am not 
sure if it is the original or the advice-induced. I suppose it is the 
advice-induced because adding !cflow("B B::operator %(...)") doesn't 
filter it.

(I have ofcourse a second construction since operator ++(int) uses a 
temp variable itself for implementing its behaviour - but this is not 
relevant!)

> From the language point of view I would prefer the copy construction 
> of the result object to be in the cflow of the call, but not in the 
> cflow of the execution. This brings us back to the problem with call 
> advice for operator ++(int) :-(. I think it would be best to with 
> fixing the call advice problem. Do you agree?

That makes sense, ofcourse.

Greets,
Hans