Is it valid to initialize a base class with placement new?

[Juha Nieminen]

Assume I have a class Base, and then this:

struct Derived: public Base
{
AnotherClass member;
};

Also assume that I'm allocating an object of type 'Derived' with a
custom allocator and that, for whatever reason, I don't want to call the
constructor of 'Derived', but instead I want to build the object by
first making a placement new for the 'Base' and then another for the
'member'. (Yes, I know this might sound like a bit of a silly thing to
want, but just humor me, please.) Is it valid to do that?

The code would be something like this:

Derived* ptr = allocator.alloc ate(1);
new (static_cast<Ba se*>(ptr)) Base(baseParame ters);
new (&ptr->member) AnotherClass(ot herParameters);

This compiles (and doesn't crash), but is it valid?

[Triple-DES]

On 3 Sep, 22:17, Juha Nieminen <nos...@thanks. invalidwrote:

* Assume I have a class Base, and then this:

struct Derived: public Base
{
* * AnotherClass member;

};

[snip]

* The code would be something like this:

Derived* ptr = allocator.alloc ate(1);
new (static_cast<Ba se*>(ptr)) Base(baseParame ters);
new (&ptr->member) AnotherClass(ot herParameters);

* This compiles (and doesn't crash), but is it valid?

As others have pointed out, it is not valid (UB). If you want a
concrete refutation from the standard, see 12.7/1

"For an object of non-POD class type (clause 9), before the
constructor begins execution and after the destructor finishes
execution, referring to any nonstatic member or base class of the
object results in undefined behavior"

DP

[Juha Nieminen]

Thomas J. Gritzan wrote:

However, why don't you simple do:
new (static_cast<vo id*>(ptr)) Derived(paramet ers);

Since the number of parameters can be anything, I would need to use a
variadic template to forward the parameters to the constructor of the
member variable. (I can't assume that the member variable supports
copy-constructing.)

Well, I ended up with a compromise: I created 7 constructors for
'Derived', taking 0-6 parameters. Hopefully up to 6 parameters will be
enough until the next C++ standard is widely implemented...

[Juha Nieminen]

to***********@y ahoo.co.uk wrote:

Just use a preprocessor macro (assuming you're using a capable
compiler)...

You mean using a macro with a variable number of arguments? Is that
standard C++ yet?

[Triple-DES]

On 5 Sep, 11:19, Juha Nieminen <nos...@thanks. invalidwrote:

* Since the number of parameters can be anything, I would need to use a
variadic template to forward the parameters to the constructor of the
member variable. (I can't assume that the member variable supports
copy-constructing.)

* Well, I ended up with a compromise: I created 7 constructors for
'Derived', taking 0-6 parameters. Hopefully up to 6 parameters will be
enough until the next C++ standard is widely implemented...

What compiler are you currently using? GCC 4.3+ has variadic
templates, FWIW.

DP

[anthonypon]

On Sep 5, 6:21*pm, Juha Nieminen <nos...@thanks. invalidwrote:

tony_in_da...@y ahoo.co.uk wrote:

Just use a preprocessor macro (assuming you're using a capable
compiler)...

* You mean using a macro with a variable number of arguments? Is that
standard C++ yet?

Nope, but it's very widely supported and better than undefined
behaviour.

Tony

[Juha Nieminen]

Triple-DES wrote:

What compiler are you currently using? GCC 4.3+ has variadic
templates, FWIW.

Yes, but I'm making a library I'm going to distribute, so I have to
stick to the current C++ standard...

[Juha Nieminen]

Alf P. Steinbach wrote:

You have a bad design, and try to compensate with bad coding.

Instead fix the design.

In this case it's more a question of language limitation (fixed in
C++0x) than design.

[Juha Nieminen]

Alf P. Steinbach wrote:

Have you considered replacing

Derived* ptr = allocator.alloc ate(1);
new (static_cast<Ba se*>(ptr)) Base(baseParame ters);
new (&ptr->member) AnotherClass(ot herParameters);

with e.g.

Derived d( new AnotherClass( otherParameters ) );

Just for example?

In this application in question that's precisely what I'm trying to
avoid. (The app in question would become completely moot.)

Ok, enough riddles. I made something which I think should work about
ok, and a webpage for it:

http://warp.povusers.org/RefPtr/

Probably not a novel idea, but it might be useful to someone, maybe.

("Why not simply use boost::shared_p tr?" Because boost::shared_p tr has
the size of two pointers and a payload of a whopping 44 bytes, at least
with linux gcc, making each (unshared) shared_ptr instance consume a
grand total of 56 bytes of RAM in a 32-bit system (2*4 bytes for the two
pointers, 44 bytes for the payload and 4 bytes for the clib memory
allocator payload), while my RefPtr consumes a grand total of 8 bytes
(sizeof(RefPtr) = 4, plus the intrusive reference counter). Sure, it's
not as versatile, but in many situations that doesn't matter.)

[Thomas J. Gritzan]

Juha Nieminen schrieb:

Alf P. Steinbach wrote:

>Have you considered replacing

Derived* ptr = allocator.alloc ate(1);
new (static_cast<Ba se*>(ptr)) Base(baseParame ters);
new (&ptr->member) AnotherClass(ot herParameters);

with e.g.

Derived d( new AnotherClass( otherParameters ) );

Just for example?

In this application in question that's precisely what I'm trying to
avoid. (The app in question would become completely moot.)

How about this:

struct Holder
{
unsigned char SomeSpace[sizeof(...)];
size_t Count;
};

Holder* ptr = allocator.alloc ate(1);
new (ptr) Holder(basePara meters);
new (ptr->SomeSpace) AnotherClass(ot herParameters);

Ok, enough riddles. I made something which I think should work about
ok, and a webpage for it:

http://warp.povusers.org/RefPtr/

Probably not a novel idea, but it might be useful to someone, maybe.

Do you know this article? (by Andrei Alexandrescu)
http://www.informit.com/articles/art...31529&seqNum=6
On the following pages it describes some useful technics for smart
pointer implementations .

--
Thomas

[Juha Nieminen]

Thomas J. Gritzan wrote:

How about this:

struct Holder
{
unsigned char SomeSpace[sizeof(...)];
size_t Count;
};

Holder* ptr = allocator.alloc ate(1);
new (ptr) Holder(basePara meters);
new (ptr->SomeSpace) AnotherClass(ot herParameters);

That might be one possible solution (at least to avoid having to write
all the constructors, or the variadic template constructor).