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

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

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.

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.