Date: Tue, 24 Sep 2019 09:01:09 -0700
On Tuesday, 24 September 2019 08:45:17 PDT José Luis March Cabrelles via Std-
Discussion wrote:
> If not, a call to the program-defined function cannot be omitted. And if
> not, how can a compiler that translates a call in translation unit T1
> know whether it is calling the default library function or a program
> defined allocation function defined in translation unit T2?
It doesn't. It is calling the function and shouldn't / cannot care where it is
defined, if it's not in the same translation unit as the call point.
I understand the "can be omitted" as "you cannot count on it to be an
observable effect". The compiler is allowed to elide calls to new away.
> Another relevant section is C++14, Section 3.7.4 Dynamic storage
>
> duration [basic.stc.dynamic], Paragraph 2:
> "The library provides default definitions for the
> global allocation and deallocation functions. Some
> global allocation and deallocation functions are
> replaceable (18.6.1). A C++ program shall provide at
> most one definition of a replaceable allocation or
> deallocation function. Any such function definition
> replaces the default version provided in the library
> (17.6.4.6)."
>
> This wording suggests that the program defined allocation function is
> also to be called "replaceable", even though it has to be unique and
> that seems to stretch the meaning of the word "replaceable".
It just means that you can override it only once. Two replacement functions
are ill-formed. The library's new is replaceable, your replacement isn't.
> The question whether a call to program-defined global allocation
> function can be omitted is relevant if the program-defined function
> implements side effects other than just allocating memory. While having
> such side effects may not be advisable, the standard does not restrict
> it. Here is some example code: https://cpp.godbolt.org/z/ft9I_M
Which is why the standard tells you that the calls may be suppressed. And
depending on your definition, memory allocation is an observable side effect
on its own.
Discussion wrote:
> If not, a call to the program-defined function cannot be omitted. And if
> not, how can a compiler that translates a call in translation unit T1
> know whether it is calling the default library function or a program
> defined allocation function defined in translation unit T2?
It doesn't. It is calling the function and shouldn't / cannot care where it is
defined, if it's not in the same translation unit as the call point.
I understand the "can be omitted" as "you cannot count on it to be an
observable effect". The compiler is allowed to elide calls to new away.
> Another relevant section is C++14, Section 3.7.4 Dynamic storage
>
> duration [basic.stc.dynamic], Paragraph 2:
> "The library provides default definitions for the
> global allocation and deallocation functions. Some
> global allocation and deallocation functions are
> replaceable (18.6.1). A C++ program shall provide at
> most one definition of a replaceable allocation or
> deallocation function. Any such function definition
> replaces the default version provided in the library
> (17.6.4.6)."
>
> This wording suggests that the program defined allocation function is
> also to be called "replaceable", even though it has to be unique and
> that seems to stretch the meaning of the word "replaceable".
It just means that you can override it only once. Two replacement functions
are ill-formed. The library's new is replaceable, your replacement isn't.
> The question whether a call to program-defined global allocation
> function can be omitted is relevant if the program-defined function
> implements side effects other than just allocating memory. While having
> such side effects may not be advisable, the standard does not restrict
> it. Here is some example code: https://cpp.godbolt.org/z/ft9I_M
Which is why the standard tells you that the calls may be suppressed. And
depending on your definition, memory allocation is an observable side effect
on its own.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel System Software Products
Received on 2019-09-24 11:03:19