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
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