Why GCC prefers global size-unaware deallocation function?

[Ruslan Garipov]

Oops! I was confused with English languagw again, sorry!

> or a (possibly multi-dimensional) array thereof

This still refers " class type with a non-trivial destructor". Therefore, 
(10.4) comes into play in my case:

> (10.4) Otherwise, it is unspecified whether a deallocation function with a 
> parameter of type std::size_t is selected.

Thanks for help, anyway!

Yours truly,
brigadir15 at gmail dot com.



On December 4, 2016 7:50:17 PM Avi Kivity <avi@scylladb.com> wrote:

>
>
> On 12/04/2016 02:26 PM, Ruslan Garipov wrote:
>> I have the following `operator delete` replacements:
>>
>> void operator delete[](void* p)
>> {
>>    /* Implementation does not matter. */
>> }
>>
>> void operator delete[](void* p, std::size_t size)
>> {
>>    /* Implementation does not matter. */
>> }
>>
>> My question is why, in the following code, GCC 6.2 calls `void
>> operator delete[](void*)` and not the second replacement:
>>
>> char* str = new char[14];
>> delete[] str;
>>
>>
>> According to 5.3.5 Delete [expr.delete]:
>>
>>> (10.3) If the type is complete and if, for the second alternative (delete 
>>> array) only, the operand is a pointer to a class type with a non-trivial 
>>> destructor or a (possibly multi-dimensional) array thereof, the function 
>>> with a parameter of type std::size_t is selected.
>> Therefore, I believe `operator delete[](void*, std::size_t)` must be
>> called, doesn't it?
>>
>
> char is not a class type with a non-trivial destructor, so the second
> condition does not hold.
>
> Under the hood, if C++ allocates an array with non-trivial destructors,
> it must also store the size of the array so it knows how many
> destructors to call, and can then use the stored size of the array to
> call the sized deallocator function.  In this case, there's no need to
> call the destructors, so C++ only allocates 14 chars, and does not store
> the size.