[PATCH] Add configure flag for operator new (std::nothrow)

[Jonathan Wakely]

On 6 November 2015 at 09:02, Daniel Gutson
<daniel.gutson@tallertechnologies.com> wrote:
>
> El 5/11/2015 22:56, "Jonathan Wakely" <jwakely.gcc@gmail.com> escribió:
>>
>> On 5 November 2015 at 23:31, Daniel Gutson
>> <daniel.gutson@tallertechnologies.com> wrote:
>> > On Thu, Nov 5, 2015 at 2:11 PM, Jonathan Wakely <jwakely.gcc@gmail.com>
>> > wrote:
>> >> On 5 November 2015 at 20:52, Daniel Gutson wrote:
>> >>> Real use cases: statistics and logging. It's a (one time) callback
>> >>> reporting that something went wrong,
>> >>> but not intended to fix things e.g. by attempting to free more memory.
>> >>
>> >> Why can't that be done by replacing operator new with a user-defined
>> >> function, instead of modifying the default one?
>> >>
>> >> A program that wants to make use of the altered semantics is
>> >> non-portable because it relies on a custom libstdc++ configuration
>> >> option, and has to install a custom new-handler that relies on the
>> >> altered libstdc++ behaviour. Replacing operator new to do the logging
>> >> is portable and requires no custom configuration.
>> >>
>> >> (I'm not rejecting the patch, but am still trying to make sure it's a
>> >> useful change.)
>> >
>> > The issue is, as I understand it, to do the actual work of operator
>> > new, i.e. allocate memory. It should force
>> > us to copy most of the code of the original code of operator new,
>> > which may change on new versions of the
>> > STL, forcing us to keep updated.
>>
>> It can just call malloc, and the replacement operator delete can call
>> free.
>
> It can but the actual code of operator new is optimized and more complex
> (for example by using intrinsics). The user might not want to deal with the
> STL implementation internals.

By this argument users should never replace operator new at all. I
don't find that convincing.

If they don't want to deal with implementation details then they don't
have to. The default implementations are optimized because they are
used by everyone and it would be silly to ship them without making
easy optimisations, but that doesn't mean that users have to do the
same thing in their own replacement allocation functions. Using
__builtin_expect makes a small difference when looping on the result
of malloc, but if you were to provide a replacement that doesn't loop
then the difference for a single branch is not very significant. If
profiling shows it matters then it's easy to use __builtin_expect
(it's not an implementation detail, it's a public function documented
in the manual and available for users, and most code bases I've worked
on have used it somewhere).




>>
>> That is very unlikely to need to change (which is corroborated by the
>> fact that the default definitions in libsupc++ change very rarely).
>>
>> Relying on a non-standard configuration of a single implementation
>> seems far more fragile than writing a custom new/delete.
>>
>> > This is important when having legacy code that uses operator new (but
>> > doesn't use a new_handler),
>>
>> Such code won't be affected by the proposed patch anyway, because if
>> there is no new-handler then there is no change in behaviour, it
>> returns after the first call to malloc.
>
> I didn't explain myself correctly: what I meant is that this is useful when
> dealing with legacy library that does not use a new_handler, which gives
> room to define the one for the statistics, logging and leds diagnostics in
> the user code. Indeed the library code doesn't get affected, but get
> "sniffed" by the user's handler.

OK, but a user's replacement operator new would have the same effect,
without affecting the library code.