Hi,
On Friday 25 February 2011 19:37:27 Jonathan Wakely wrote:
> On 25 February 2011 17:05, Matthias Kretz wrote:
> > I'm saying that the way I thought about const + ctor seems logical (if
> > you are not a compiler developer at least :-) ). Regardless of how well
> > defined "return value" is in the standards, to me as C++ developer the
> > ctor acts as a function that takes some input and leaves as output a
> > constructed object.
>
> But it definitely doesn't *return* that object, any more than the
> destructor does.
Yes. Now, in light of the clear definition of "return value" my previous text
looks stupid. I'd write it differently now - but with the same content. Take
it as what the average C++ developer will take away from the docs (I actually
consider myself above average - though not in terms of how fluent I am in
correct C++ terminology) ... BTW, my notion of return value comes from looking
at the generated asm. It certainly is a return value for the code I'm writing.
While I'm convinced that you can derive the behavior of const + ctor in GCC
from the docs, I'm neither convinced that other developers won't have the same
problem, nor that it wouldn't make sense to be able to declare const ctors.
In my case I'm working around it by having the ctor call a const C-function
whose return value initializes the data. This should, hopefully, result in the
same effect.
Another aside: The classes I'm working on have their member data not in memory
in many places (basically wrapping an SSE/AVX register) and through inlining
the this pointer completely disappears. That's the level I'm thinking on.
What does the destructor now have to do with it? A dtor either has side
effects (e.g. free) or it is not required.
Regards,
Matthias
--
Dipl.-Phys. Matthias Kretz
http://compeng.uni-frankfurt.de/index.php?id=mkretz
