Date: Sun, 12 Feb 2023 11:57:37 -0500
On Sun, Feb 12, 2023 at 11:54 AM Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Sunday, 12 February 2023 08:41:21 PST Jens Maurer via Std-Proposals wrote:
> > That's already the specified behavior when you provide your own
> > definition of global "operator new" and global "operator delete":
> > You replace those functions program-wide.
> >
> > The implementation you use may behave differently when DLLs
> > are involved; please discuss this with your implementer.
>
> It does and that cannot be changed on Windows without a major overhaul of just
> how the "dynamic linking" part of "dynamic linking libraries" work. In other
> words, this is not just a (compile-time) linker problem, it's mostly a program
> loader and file format problem.
>
> Even macOS/Darwin adopted some of the characteristics that are problematic, so
> I don't know how well it works on those OS and, if it does work, just how.
It should also be noted that the standard explicitly says that "A C++
program shall provide at most one
definition of a replaceable allocation or deallocation function." So
if you replace it, and include a DLL that also replaces it... what is
supposed to happen?
By default, this is ill-formed and a diagnostic is required. But this
is dynamic linking; we're well past the stage in the practical process
of compilation where a "diagnostic" is possible. You could have a
dynamic linking error if the two programs disagree on what allocation
functions to use.
But regardless of the resolution, I rather suspect that this wouldn't
solve the OP's problem.
<std-proposals_at_[hidden]> wrote:
>
> On Sunday, 12 February 2023 08:41:21 PST Jens Maurer via Std-Proposals wrote:
> > That's already the specified behavior when you provide your own
> > definition of global "operator new" and global "operator delete":
> > You replace those functions program-wide.
> >
> > The implementation you use may behave differently when DLLs
> > are involved; please discuss this with your implementer.
>
> It does and that cannot be changed on Windows without a major overhaul of just
> how the "dynamic linking" part of "dynamic linking libraries" work. In other
> words, this is not just a (compile-time) linker problem, it's mostly a program
> loader and file format problem.
>
> Even macOS/Darwin adopted some of the characteristics that are problematic, so
> I don't know how well it works on those OS and, if it does work, just how.
It should also be noted that the standard explicitly says that "A C++
program shall provide at most one
definition of a replaceable allocation or deallocation function." So
if you replace it, and include a DLL that also replaces it... what is
supposed to happen?
By default, this is ill-formed and a diagnostic is required. But this
is dynamic linking; we're well past the stage in the practical process
of compilation where a "diagnostic" is possible. You could have a
dynamic linking error if the two programs disagree on what allocation
functions to use.
But regardless of the resolution, I rather suspect that this wouldn't
solve the OP's problem.
Received on 2023-02-12 16:58:15