Frederick Gotham wrote:
, then using "placement new" to construct an object of the class does the
following:
(1) Calls the constructor of the member object, "member".
(2) Calls the MyStruct constructor for the object itself.
It's the MyStruct constructor which recursively invokes the member
constructors.
This is conceivibly quite realistically like:
mystruct_obj.member.string();
mystruct_obj.MyStruct();
Not really, since explicit constructor calls return new temporary
objects. There is no such thing as an in place constructor call on an
object.
However, take a look at the following life-cycle of a DIY object, paying
particular attention to the way in which we destruct the object:
char *const mem = new char[sizeof(MyStruct)]; /* Allocate the memory */
MyStruct *const p = ::new(mem) MyStruct(5); /* Construct the object */
p->~MyStruct(); /* Destruct the object */
delete [] mem; /* Deallocate the memory */
Notice that when we are destructing the object, it looks as though we're
"Destructing" is awkward; you want "destroying". :)
simply invoking the MyStruct destructor -- but in actuality, we're really
doing:
p->member.~string();
p->~MyStruct();
Not really, it's the MyStruct::~MyStruct which is handling the
recursion to the other destructors.
This is inconsistent with the way in which we construct the object!
Not in the least. The top-level constructor recurses to the constituent
constructors, and the top-level destructor recurses ot the constituent
destructors. I don't see the consistency.
But not only that, it's misleading because we are _not_ simply calling the
destructor -- we're doing more than that, we're invoking the constructors
of all base classes and subobjects.
For consistency, we should have either
had:
Solution (1) -- Not favourable
char *const mem = new char[sizeof(MyStruct)];
MyStruct &obj = reinterpret_cast<MyStruct&>(*mem);
obj.MyClass(5); /* Construct! */
This is stupid because obj is an invalid object with indeterminate
contents.
The placement new syntax makes more sense, because it takes in
uninitialized memory, plus the identity of a class, and puts the two
together.
A constructor is not an ordinary member function of an object. It's a
special member that belongs to the class. The constructor takes memory
which may have indeterminate contents, and turns it into an object.
Solution (2) -- Quite favourable
char *const mem = new char[sizeof(MyStruct)];
MyStruct *const p = ::new(mem) MyClass(5);
::delete(p) MyClass; /* Placement delete! */
This "placement delete" would have to assume that the memory came from
new. But in general, when placement new is used, the memory does not
come from new.
For this placement delete to be useful, it would have to call the
destructor only, and not try to do anything else with the memory. Then
it would be complementary to placement new, which does not allocate
memory.
The second solution is favourable, as it makes no mention of calling
Solution to what problem? That the placement new syntax does not
resemble in-place destruction syntax isn't a problem; it's esthetics.
Construction and destruction are not intended to be symmetrical. What
about this:
{
MyStruct x(3);
}
Where is the symmetry here? Explicit syntax instantiates the object,
yet the destruction is invisible.
Construction takes place in an enviornment in which the object doesn't
exist yet. It's a function that is invoked on the environment to
produce the object. Destruction is something that happens to the
object.
Then there is the fact that C++ is a brutally ugly language with
ill-conceived syntax throughout. If you insist on consistency, don't
use C++.
My own opinion is that there should be a "placement delete", whose purpose
it is to destruct an object.
And there is. You merely don't like its spelling:
``pointer->~Class();'' You'd rather that the parser require "delete
(pointer) Class''. You can do this with the preprocessor:
#define placement_delete (X) (X)->~
And so:
placement_delete (pointer) Class();
now macro-expands to:
(pointer)->~Class();
Hahaha. That shows you how ridiculous and trivial are obsessions for
syntactic sugar.
The DIY invocation of a destructor via "obj.~Class();" should either:
(1) Be forbidden, as it is for constructors.
Invocation of constructors isn't forbidden.
(2) Just call _that_ destructor, exactly as if it were a member
function, without invoking any other destructors (such as those of base
objects or subobjects.
Doh.