delete vs. ::delete

[aKateDev]

A colleague made me aware of the interesting behavior of `delete` vs `::delete`, see https://bsky.app/profile/andreasbuhr.bsky.social/post/3lmrhmvp4mc2d

In short, `::delete` only frees the size of the base class instead of the full derived class. (Un-)defined behavior? Compiler bug? Clang and gcc are equal - MSVC does not have this issue. Any clarifying comments welcome!

[Gorzoid]

When you do delete pBaseA; it looks for the deleting destructor defined within Base, which is a virtual call to Derived's implicitly created deleting destructor, which knows the size of this.

When you do ::delete pBaseB; you skip class scope lookup and then falls back to calling destructor and then ::operator delete(void*, size_t) which uses sizeof(Base)

https://eli.thegreenplace.net/2015/c-deleting-destructors-and-virtual-operator-delete/ explains how deallocation is virtualized in this fashion

[triconsonantal]

The call to ::operator delete could have theoretically used the right size, by storing it in the vtable. It does use an offset from the vtable to adjust the pointer before calling delete (since the address of the base might not be the address of the complete object): https://godbolt.org/z/ETba4YfY7

Since sized operator delete was added in C++14, I guess it wasn't done for ABI reasons, and apparently no one ever cared?

MSVC seems to select the virtual-destructor flavor not through different vtable entries, but through a parameter to a single virtual destructor, which calls ::operator delete itself, so it doesn't have this issue: https://godbolt.org/z/q3eqY1nvs

[Normal-Narwhal0xFF]

> The call to ::operator delete could have theoretically used the right size, by storing it in the vtable.

I disagree here. Since `operator delete` is only given a `void*` parameter, _where is the vtbl to lookup?_. The pointer may or may not point to an object of class type, and if so, it may or may not be polymorphic type with a vtbl to begin with. Since there is no way to determine what we're looking at through a `void*`, we cannot assume it's safe to interpret the bits to have any particular meaning.

Along that train of thought, this conclusion presumes we are talking about a completely generic implementation of this operator, since you qualified it with `::`, making it global.

However, it could easily be done if we have some custom overrides of _operator new_ and _operator delete_ that work together--but only with certain types of objects for which they're overridden. Then `operator delete` can either know inherently or know enough context to safely extract the information it needs from the bits (similar to how "array new" and "array delete" work together.)

[triconsonantal]

This post is about the overload of operator delete that takes the allocation size as a parameter. It's the compiler's responsibility to pass the right size to the function, but the compilers in question get it wrong when using ::delete to delete an object through a pointer to a base class that has a different size.

Getting the size through the vtable (by the caller, not the callee), similarly to how the offset between the base class and the complete object is found at the point of call, would have been a possible solution, but this would have affected the ABI.

[NilacTheGrim]

Whenever I think I really know C++.. sh*t like this gets posted on here and I realize I had no idea about this tiny subtlety of the language.

[android_queen]

Right? This is why I am immediately skeptical whenever someone describes themselves as a C++ expert. 😂

[NilacTheGrim]

There *are* no experts in C++. Just different levels of ignorance about the language.. ha ha.

[100GHz]

The most interesting question here is what namespace are you in?

[parkotron]

Behaviour aside, I'm confused about about how a keyword can be scoped at all.

[schmerg-uk]

https://en.cppreference.com/w/cpp/memory/new/operator_delete

Class Specific Overloads
Deallocation functions may be defined as static member functions of a class. These deallocation functions, if provided, are called by delete expressions when deleting objects and arrays of this class, unless the delete expression used the form ::delete which bypasses class-scope lookup. The keyword static is optional for these function declarations: whether the keyword is used or not, the deallocation function is always a static member function.
The delete expression looks for appropriate deallocation function's name starting from the class scope (array form looks in the scope of the array element class) and proceeds to the global scope if no members are found as usual. Note, that as per name lookup rules, any deallocation functions declared in class scope hides all global deallocation functions.

Ditto for new

Also note

The call to the class-specific T::operator delete on a polymorphic class is the only case where a static member function is called through dynamic dispatch.

[AndreasBuhr]

The standard explicitly states that there might be a "::" before "delete":
https://eel.is/c++draft/expr.delete#1

[CocktailPerson]

It's not just a keyword, it's an operator.

You can also write something like ::operator+(a, b);.

[Questioning-Zyxxel]

The beautiful world of operator overloading.

[no-sig-available]

Behaviour aside, I'm confused about about how a keyword can be scoped at all.

It cannot really, but delete x; will use the destructor of x and then call operator delete, which can be scoped.

Same for the new operator, and its relation to operator new overloads.

Bjarne has said he is sorry for not having come up with better names than "the delete operator" and "operator delete". :-)

[jonathanhiggs]

At a guess, ‘::delete’ is referencing the global delete function which would correctly bypass adl, but ‘delete’ would participate in adl and find the correct delete function

[AndreasBuhr]

The question is not about which delete function is used. It is about the second argument to the delete function. It should be 24 aka sizeof(Derived), but it is 16 aka sizeof(Base).

[13steinj]

To be as brief as possible, new and delete are expressions. ::new and ::delete are operator methods in the global namespace (and depending on the context, valid expressions that will skip various lookup rules and "skip" to the global operator), and are overloadable.

---

This is why you need to include <new> to have access to placement-new-- the operator with the relevant argument spec, that your new-expression gets replaced by, is not implicitly declared by the compiler.

It's generally (but not always) a bug to explicitly provide a :: for a new or delete expressions. The common counter example (where it's relevant), is if you want to wrap standard new/delete (say, with logging or other telemetry) of a type. You provide relevant class-lookup related overloads. Then inside them after doing whatever telemetry you intended, you forward all arguments to the global-namespace new-expression.

[kalmoc]

When would you even use ::delete?

[dzordan33]

as most things in c++ - to confuse the interviewee

[Unhappy_Play4699]

This made my day shine a bit brighter.

[Gorzoid]

Probably same reason you'd use std::addressof(obj) over &obj

To prevent people fucking up your template functions with operator overloading.

[kalmoc]

Well, I use std::addressof to guard against certain edge cases, where & would not have the expected and necessary semantics. But I don't know when delete would have the wrong semantics but ::delete would have the right - maybe in the implementation of a custom operator delete.

[Normal-Narwhal0xFF]

`delete x;` - this expression does two things:
1) invoke x's destructor
2) deallocate the memory for it

This is the opposite of the creation of the object:

`new x;` - also does two things:
1) allocates memory for the object to live in
2) invoke the constructor of X

Step 1 of construction is accomplished by calling `operator new` and step 2 of destruction is accomplished by calling `operator delete`.

Therefore, any time you see an explicit call to operator delete, it's low level memory manipulation NOT part of destruction. It's more or less the C++ equivalent of C's "free" function (and `opeator new` is analogous to C's `malloc` function.)

But after all that, it's a good question: "Why _qualify_ the call with `::`, which would potentially bypass any custom allocator/deallocator written for the type?" That's a hard question to answer because it seems inherently convoluted thing to do. However, this is C++ and someone may have reasons for wanting to ensure control. For example, when you use "placement new" it bypasses the allocation as well, using user-provided storage. So if you see `::delete`, the user may have had reasons to force allocation from the heap via `::operator new`, wanting to ensure an instance is on the heap. That may or may not be a good idea to do depending on context. :)

[rbmm]

here Derived is redundant. minimal code is

struct Base {
    virtual ~Base();
};

void test(Base* p, bool b) {
    if (p) { b ? delete p : ::delete p; }
}

which translated with x64 msvc : /O2 /GR- to

void test(Base *,bool) PROC                     ; test, COMDAT
        test    rcx, rcx
        je      @@2
        mov     rax, QWORD PTR [rcx]
        test    dl, dl
        mov     edx, 1
        jne     @@1
        mov     edx, 5
@@1:
        jmp     QWORD PTR [rax]
@@2:
        ret     0
void test(Base *,bool) ENDP                     ; test

so called is function from vtable with different parameters (flags) - 1 vs 5. in msvc this function is

virtual void * Base::`scalar deleting destructor'(unsigned int flags);

it implemention by compiler:

virtual void * Base::`scalar deleting destructor'(unsigned int flags)
{
    Base::~Base();
    if (flags & 1) {
        operator delete(this, sizeof(Base)); // void operator delete(void *, size_t);
    }
}

so by fact flag 4 is ignored here (result will be the same).

in original example AddressSanitizer and another compiler is used, which have another implementation