[aspectc-user] overloaded operator ++() and ++(int)
hans.vanbroeckhoven at telenet.be
Tue May 24 13:59:43 CEST 2005
> 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
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
(I have ofcourse a second construction since operator ++(int) uses a
temp variable itself for implementing its behaviour - but this is not
> 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.
More information about the aspectc-user