[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: semantics of attribute const on constructors
From:       Matthias Kretz <kretz () compeng ! uni-frankfurt ! de>
Date:       2011-02-25 19:04:52
Message-ID: 201102252004.52654.kretz () compeng ! uni-frankfurt ! de
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]