Home/ Questions/Q 7248501
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-28T22:08:48+00:00

Say, the code class Derived: public Base {….} Base* b_ptr = new( malloc(sizeof(Derived)) )

  • 0

Say, the code

    class Derived: public Base {....}

    Base* b_ptr = new( malloc(sizeof(Derived)) ) Base(1);
    b_ptr->f(2);
    Derived* d_ptr = new(b_ptr) Derived(3);
    b_ptr->g(4);
    d_ptr->f(5);

seems to be reasonable and LSP is satisfied.

I suspect that this code is standard-allowed when Base and Derived are POD, and disallowed otherwise (because vtbl ptr is overwritten). The first part of my question is: please point out precise precondition of such an overwrite.

There may exist other standard-allowed ways to write over.

The second part of my question is: is there any other ways? What are their precise preconditions?

UPDATE: I do NOT want to write code like this; I am interested in theoretical possiblity (or impossibiliy) of such a code. So, this is “standard nazi” question, not a question “how can I …”. (Has my question to be moved to other stackoverflow site?)

UPDATE2&4: What about destructors? Supposed semantics of this code is “Base instance is (destructively) updated by slice of Derived instance”. Let us assume, for the sake of simplicity, that Base class has a trivial destructor.

UPDATE3: The most intersting for me is the validity of access via b_ptr->g(4)

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You really need to do b_ptr = d_ptr after placement-new of Derived, in case the Base subobject isn’t first in the layout of Derived. As written, b_ptr->g(4) evokes undefined behavior.

    The rule (3.8 basic.life):

    If, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, a new object is created at the storage location which the original object occupied, a pointer that pointed to the original object, a reference that referred to the original object, or the name of the original object will automatically refer to the new object and, once the lifetime of the new object has started, can
    be used to manipulate the new object, if    :

    • the storage for the new object exactly overlays the storage location which the original object occupied,
      and
    • the new object is of the same type as the original object (ignoring the top-level cv-qualifiers), and
    • the type of the original object is not const-qualified, and, if a class type, does not contain any non-static
      data member whose type is const-qualified or a reference type, and
    • the original object was a most derived object (1.8) of type T and the new object is a most derived object of type T (that is, they are not base class subobjects).

    You also should probably be destroying the old object before reusing its memory, but the standard doesn’t mandate this. However failure to do so will leak any resources owned by the old object. The full rule is given in section 3.8 (basic.life) of the Standard:

    A program may end the lifetime of any object by reusing the storage which the object occupies or by explicitly calling the destructor for an object of a class type with a non-trivial destructor. For an object of a class type with a non-trivial destructor, the program is not required to call the destructor explicitly before the storage which the object occupies is reused or released; however, if there is no explicit call to
    the destructor or if a delete-expression (5.3.5) is not used to release the storage, the destructor shall not be implicitly called and any program that depends on the side effects produced by the destructor has undefined behavior.

    • 0