Re: Using this in initialization list??
* James Kanze:
On May 6, 1:07 pm, Neelesh <neelesh.bo...@gmail.com> wrote:
On May 6, 1:51 pm, James Kanze <james.ka...@gmail.com> wrote:
On May 6, 6:22 am, Neelesh <neelesh.bo...@gmail.com> wrote:
On May 6, 5:36 am, huil...@gmail.com wrote:
Is the following code valid?
template < typename F >
struct base1
{
base1(const F& f):f(f){}
const F& f;
};
template < typename E1, typename E2 >
struct base2
{
base2(const E1& e1, const E2& e2):e1(e1),e2(e2){}
const E1& e1;
const E2& e2;
};
template < typename F1, typename F2 >
struct derived : base1<F1>
,base2<base1<F1>,F2>
{
derived(const F1& f1, const F2& f2)
:base1<F1>(f1)
,base2<base1<F1>,F2>(static_cast<base1<F1> const&>(*this), f2) // is
this okay?
{}
};
Yes, the code is valid and the static_cast is not needed.
12.6.2p7
...because the meminitializer are evaluated in the scope
of the constructor, the this pointer can be used in the
expressionlist of a meminitializer to refer to the object
being initialized.
No, it's not valid. The expression *this is an lvalue
expression with type derived. Type derived has a
non-trivial constructor. According to ?3.8:
[...] The lifetime of an object of type T begins when:
-- storage with the proper alignment and size for type
T is obtained, and
-- if T is a class type with a non-trivial constructor
(12.1), the constructor call has completed.
Furthermore:
Before the lifetime of an object has started but after
the storage which the object will occupy has been
allocated or, after the lifetime of an object has ended
and before the storage which the object occupied is
reused or released, any pointer that refers to the
storage location where the object will be or was located
may be used but only in limited ways. Such a pointer
refers to allocated storage (3.7.3.2), and using the
pointer as if the pointer were of type void*, is
well-defined. Such a pointer may be dereferenced but the
resulting lvalue may only be used in limited ways, as
described below. If the object will be or was of a class
type with a non-trivial destructor, and the pointer is
used as the operand of a delete-expression, the program
has undefined behavior. If the object will be or was of
a non-POD class type, the program has undefined behavior
if:
[...]
-- the pointer is used to access a non-static data
member or call a non-static member function of the
object, or
-- the pointer is implicitly converted (4.10) to a
pointer to a base class type, or
-- the pointer is used as the operand of a static_cast
(5.2.9) (except when the conversion is to void*, or
to void* and subsequently to char*, or unsigned
char*).
There's no exception that I can see for the this pointer.
hmm...yes..agreed. In fact, in the current case, 3.8p6 applies
more appropriately:
if the original object will be or was of a nonPOD class type, the
program has undefined behavior if:
[...]
? the lvalue is implicitly converted (4.10) to a reference to a base
class type, or
[...]
The lvalue (*this) has been converted to reference to base
class type (base<F1>&) in the constructor of derived class,
which would result in undefined behavior.
However, I believe that this is somewhat strange and I donot
see any obvious reason of not allowing this.
I can't either. I think the case the standard is trying to
address is that of some external pointer. Something along the
lines of:
Derived* p = static_cast< Derived* >(
::operator new( sizeof Derived ) ) ;
new ( p ) Derived ;
and then the base class constructor calls a function which tries
to convert p to a Base*. There are very good reasons why this
should be undefined behavior. And those reasons really apply to
just about any pointer except this; the compiler can only do the
conversion correctly if it knows (more or less) how much has or
has not been constructed (at least if the base is virtual).
AFAICS the compiler doesn't need to know how much has been constructed, but it
does need to know location of the base class subobject, which can be a run-time
value in the case of a virtual base.
This location must be known at the latest when execution of the Derived
constructor's body starts, because there Base might be referred to.
So what it boils down to is whether a C++ compiler is permitted to allocate a
virtual base subobject dynamically, in which case the location might not be
known until it has been constructed.
I think the base class subobject cannot be dynamically allocated, for reasons
that I have partially forgotten but which were convincing to me at the time I
analysed this, but as I recall Dave Abrahams thought yes, it can be. Anyway, it
seems it's the same situation as with assuming that std::string has a contiguous
buffer. Even though the current standard doesn't guarantee that, one would be
Really Hard Pressed to find an extant compiler where std::string has a
non-contiguous buffer, and likewise, one would be Really Hard Pressed to find a
compiler where a virtual base class object is allocated dynamically...
And when it's not allocated dynamically, as one can assume for the in-practice,
then the compiler has all the information that it needs for the cast --
namely, the offset of the Base subobject relative to any particular Derived
object -- at compile time. And it needs to pass that offset so that it's known
when execution of the Derived constructor's body starts. So there's then no
reason why it can't be available also when the mem initializer list is executed,
even for routines called from the mem initializer list, because all the compiler
needs to do is to store it wherever general code assumes that it is stored.
And so it seems that the standard really should make an exception for the case
of up-conversion from Derived of this or *this after execution of a Derived
constructor's mem-initializer list has begun.
For it's common practice, and it's counter-productive to have compilers warn
about it or (as some future compiler might do) outright reject it.
And if that turns out to be difficult to get that idea through the politics,
then IMHO at least an exception for Derived with no virtual bases.
For in that case, as I recall, there's really no problem that isn't already
addressed (e.g. one problem is dereferencing a pointer passed elsewhere before
relevant part has been constructed, and as I recall that's already addressed).
Cheers,
- Alf
--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!