Program namespaces partitioning and new/delete operators

G

GianGuz

Global new and delete operators can be overloaded to suite particulars
needs. Typically they are overloaded to insert useful debugging/trace
informations. What I would to discuss here concerns the possibility of
overload these operators not at the global level namespace but
into different program namespaces.

For instances:
#include<iostream>

using namespace std;

namespace A {

void* operator new(size_t size) {

cout << "New A " << endl;

return ((void*) malloc(size * sizeof(char)));
}

int f() {

int *x = new int(0);
int y = *x;

delete x;

return y;
}

}

namespace B {

void* operator new(size_t size) {

cout << "New B " << endl;

return ((void*) malloc(size * sizeof(char)));
}

int f() {

int *x = new int(1);
int y = *x;

delete x;

return y;
}

}

int main() {

cout << "A::f() " << A::f() << endl;

cout << "B::f() " << B::f() << endl;
}

The idea is that we can partition the program into different
logical namespaces that share a common memory allocation policy,
instead of redefining new/delete operators for any object
we think should have a different one.
Specialized and Local allocation policies have been proved to be
very useful due to the lack of specific optimized capabilites of the
std new operator in many context (see: Alexandrescu MCPPD 4.1)
This can be useful also when we have to plugin with third
party (open source - we need access to complete srcs) softwares.
We can add our allocation support simply embedding them
into the logical namespace that suites better that library.
Namespaces can so be imagined in a class like hierarchy
in which we have:

(here new/delete operators were redifined to give a
global general behaviour)
Global Namespace

(here new/delete operators were redifined to give global
general optimizations)
--> Memory Mamagement Allocation Namespace

(here new/delete operators were redifined to give specific
component optimizations)
--> Program Component 1
..
..
..

(here new/delete operators were redifined to give specific
component optimizations)
--> Program Component N

(here new/delete operators were redifined to give debug information)
--> Debugging Information Namespace

(here new/delete operators were redifined to give specific
component debugging information)
--> Program Component 1
..
..
..

(here new/delete operators were redifined to give specific
component debugging information)
--> Program Component N

}

and so on...

Have you already experienced something like that?
And in which context?

Thanks,

Gianguglielmo
 
T

Tom Widmer

GianGuz said:
Global new and delete operators can be overloaded to suite particulars
needs. Typically they are overloaded to insert useful debugging/trace
informations. What I would to discuss here concerns the possibility of
overload these operators not at the global level namespace but
into different program namespaces.

The first thing to mention, in case you don't realise this, is that you
cannot overload operators new and delete at any namespace scope except
the global one. If your compiler lets you, it is a non-standard
extension. I tried it for fun, and got the following:
GCC: compiles and works as you expect (e.g. calls the namespace versions)
VC7.1: compiles but calls ::eek:perator new in each case
Como: diagnoses the error correctly
Have you already experienced something like that?
And in which context?

Well, it's all a bit academic since you can't do it, but in any case I
don't like the idea of tying namespace to allocation strategy - the two
are pretty orthogonal.

Tom
 
G

GianGuz

My compiler (gcc 3.3.4) allowed it. It is strange that this feature is
considered non-standard.
Why namespace overload of that operators should be forbidden?!
Gianguglielmo
 
T

Tom Widmer

GianGuz said:
My compiler (gcc 3.3.4) allowed it. It is strange that this feature is
considered non-standard.
Why namespace overload of that operators should be forbidden?!

How should operator new be looked up? Which namespace should be selected
for the new call? The one in which the call is made or the one of which
the type being created is a member? What about built in types?

I think it would be far too error prone, bearing in mind that new and
delete calls must be perfectly matched.

Tom
 
J

Jonathan Mcdougall

GianGuz said:
My compiler (gcc 3.3.4) allowed it. It is strange that this feature is
considered non-standard.
Why namespace overload of that operators should be forbidden?!

See 3.7.3.1[1] Allocation functions [basic.stc.dynamic.allocation]

"An allocation function shall be a class member function or a global
function; a program is ill-formed if an allocation function is
declared in a namespace scope other than global scope or declared
static in global scope."

Because they are a basic feature, being able to overload them at
namespace level would greately complicate things both for the compiler
and the user. For example,

int *ptr = 0;

namespace N
{
void *operator new(std::size_t s)
{
// return whatever
}

void operator delete(void *p)
{
// whatever
}

void f()
{
ptr = new int; // N::new or ::new ?
}
}


int main()
{
N::f();

delete ptr; // N::delete or ::delete
}

What about the fact that namespaces are open for modifications in other
translation units? Or ADL ?

As you see, this brings many problems for relatively small benefits.


Jonathan
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top