Ah-ha you're right that since C++11 it does that. Ok so my apologizes
for not being aware of that.

I just tested the attached shared library test and it does indeed return:

int main()
void foo()
1) new(size_t), size = 4
3) delete(void*)
2) new[](size_t), size = 40
5) delete[](void* ptr)

I'll test it under Windows later as well.


Regards,

On 2/20/23 14:51, Julien Villemure-Fréchette via Std-Proposals wrote:
> > But there's still the issue where a user would like to use a more
> efficient
> thread-local or allocation rate based allocator.
>
> global operator new and delete can be replaced by a non inline, non
> static global operator new with equivalent signature; any uses of a
> new/delete expression (with equivalent signature) or direct call to
> operator new/delete from anywhere, including the standard library, will
> pick the user definition, no declaration of this replacement need to be
> in scope (ie, it is always implicitly visible, as would be the default
> implementation provided by the standard library).
>
> See overloads 1-8 of operator new
> https://en.cppreference.com/w/cpp/memory/new/operator_new
> <https://en.cppreference.com/w/cpp/memory/new/operator_new>
>
> overloads 1-12 of
> https://en.cppreference.com/w/cpp/memory/new/operator_delete
> <https://en.cppreference.com/w/cpp/memory/new/operator_delete>
>
> Note: As explained in the specification, providing a single replacement
> for `operator new(size_t)` and `operator `delete(void*)` is sufficient
> to cover all non alignment-aware overloads.
>
> Julien V.
>
>
> On February 20, 2023 12:20:57 p.m. EST, Thiago Macieira via
> Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Saturday, 18 February 2023 21:42:30 PST Phil Bouchard via
> Std-Proposals
> wrote:
>
> But there's still the issue where a user would like to use a
> more efficient
> thread-local or allocation rate based allocator.
>
>
> And what's stopping you and them from using a different allocator?
> You *can*
> replace malloc for your application. I do that for mine.
>
> Replacing it for already-compiled DLLs is a different story. But
> since DLLs are
> not part of the standard, its discussion is out of scope. The fact
> is that
> DLLs allow two functions called "malloc" to exist in two different
> DLLs and be
> called from another set of two different DLLs, without a problem[*],
> so long as
> one set doesn't try to free() pointers from the other. The C++
> standard calls
> this "violation of the One Definition Rule".
>
> BTW, replacing malloc() is not a required part of the C or C++
> standards. It's
> an extension to them that most toolchains support.
>
> [*] you usually don't want this, but it's *possible* by design.
>
>

-- 
Logo <https://www.fornux.com/>  
*Phil Bouchard*  facebook icon
<https://www.linkedin.com/in/phil-bouchard-5723a910/> 
CTO
T: (819) 328-4743
E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com>
8 rue de la Baie| Gatineau (Qc), J8T 3H3 Canada
Banner <https://goglobalawards.org/> Le message ci-dessus, ainsi que les
documents l'accompagnant, sont destinés uniquement aux personnes
identifiées et peuvent contenir des informations privilégiées,
confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce
message par erreur, veuillez le détruire.
This communication (and/or the attachments) is intended for named
recipients only and may contain privileged or confidential information
which is not to be disclosed. If you received this communication by
mistake please destroy all copies.