Prev: Calling shared_from_this inside object's constructor
Next: some quirks of Koenig lookup rule?
From: Alberto Ganesh Barbati on 4 May 2008 08:17
xushiwei ha scritto:
> http://xushiwei.com/cancel-overriding-the-default-operator-new-delete
>
> * Motivation
>
> I don't think we need to override the DEFAULT operator new/delete.
> This makes your code doesn't work well together 3rdparty code (if it
> also overrides them).
>
> Why overriding the DEFAULT operator new/delete is bad?

It *is* bad for libraries. It *is not* bad for applications. I have
worked on at least one project where we definitely needed to override
the global operator new and delete. It was on an embedded platform where
the default implementation was unsuitable and therefore allowing the
compiler to ignore the overrides, as you suggest, would make the
application stop working properly. That is even worse than "breaking the
code", because the programmer has no mean to get the original behaviour
without significantly rewriting the whole program.

I definitely hope that this suggestion won't be considered.

Ganesh

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: dizzy on 4 May 2008 22:13
xushiwei wrote:

> Allowing to override the DEFAULT operator new/delete means the DEFAULT
> operator new/delete are special operators. When we have more than one
> implementations of an operator, the compiler/linker will report a
> redefining error. However, it allows there are two implementations of
> the DEFAULT operator new/delete (one of them is implemented as
> default). It sounds good. But, This gives a hint that there may have
> many implementations of the DEFAULT operator new/delete. When this
> happens, the compiler/linker doesn't know what should it do, and it
> reports a defining error. The C++ programmers have to solve such
> accidents, especially when they use 3rdparty codes You know, there
> are many libraries overriding the DEFAULT operator new/delete. But
> unfortunately, they take a risk of conflict with each other.

It is the same problem as name clashing (in the global namespace for
example). It is useful in several contexts, if used alot it has a high
chance of name colision (for example if you want to add support to print
std::vector<T> you can write a template overload for operator<< and
std::ostream& in the global or std:: namespace but clearly that has the
potential of conflict with other such overloads from other code so better
not).

I don't think the feature should be removed just because you personally
don't find it useful (many people don't find operator overloading useful,
yet they won't ever be removed, hopefully).

--
Dizzy


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 | 
Pages: 1
Prev: Calling shared_from_this inside object's constructor
Next: some quirks of Koenig lookup rule?