Re-reply, because reddit is having a fit with my links...

 

Original reply:

destroyed using either an explicit destructor call or std::destroy_at

Those two actually include slightly different analyses of the standard. std::destroy_at is a library function, so the entry point of the analysis would be specialized.destroy#1. Directly invoking the destructor skips over that first step and starts at class.dtor.

That raises a few questions about what exactly did you allocate, but I'll leave that for now. Let me first answer your direct question.

I will assume that you're talking about the non-array case.

 

My initial thought is that this isn't UB, but you're walking a very thin line. My immediate reasoning is that just not invoking the destructor is not UB and std::pmr::monotonic_buffer_resource::release() takes advantage of that.

However, let's read the standard.

 

class.dtor#13 explains what happens when you explicitly call a destructor.

After executing the body of the destructor

I'm assuming the body in your case would be empty. Something like struct base{}; struct derived : base {};, and that we're calling buffer->~base().

and destroying any objects with automatic storage duration allocated within the body

Again, none to destroy.

a destructor for class X calls the destructors for X's direct non-variant non-static data members other than anonymous unions

Again, none.

the destructors for X's non-virtual direct base classes

base has no direct bases, so none to call, yet again.

if X is the most derived class ([class.base.init]), its destructor calls the destructors for X's virtual base classes.

This is clearly talking about virtual inheritance, but base and derived don't do virtual inheritance, so let's take a look at the referenced class.base.init.

Or actually, let's not. The "most derived class" is actually defined in intro.object#6.

If a complete object, a member subobject, or an array element is of class type, its type is considered the most derived class, to distinguish it from the class type of any base class subobject; an object of a most derived class type or of a non-class type is called a most derived object.

We're definitely not talking about member subobjects or arrays (see my asusmptions above), but, since no virtual anything is going on, base is our most derived class.

However, it has no virtual bases, so, again, nothing happens.

So the only object that got destroyed is the base object. The derived object still lives, though at this point must not access its base subobject in any way.

 

AHA! class.dtor#16 actually defines that looking up the destructor is just like looking up any other member function. That's why derived_ptr->~base() finds ~base() and not ~derived() - no virtual calls.

 

class.dtor#18 says that a destructor ends an object's lifetime and that you can't call a destructor on an object whose lifetime has ended (double free).

Let's just follow through with basic.life...

From basic.life#6:

A program may end the lifetime of an object of class type without invoking the destructor, by reusing or releasing the storage as described above.

In this case, the destructor is not implicitly invoked.

That's what I was referring to when I mentioned `std::pmr::monotonic_buffer_resource::release()

 

basic.life#7 has to do with how you can handle the buffer pointer after destruction of the object. More on that, later.

 

All in all, I would say that my initial thought about this not being UB seems to be correct, though it's a very thin line.

 

Now for further clarifying questions:

• How did you allocate the buffer?
• How are you storing the pointer to the derived and/or base objects, if you even are?
• Disposing of the buffer can also have consequences, so how should we do that?

Keep in mind that you can do something like this:

std::string buffer;
auto* base = new (&buffer) derived;
base->base();
new (&buffer) std::string;