Program namespaces partitioning and new/delete operators

Discussion in 'C++' started by GianGuz, Dec 20, 2004.

  1. GianGuz

    GianGuz Guest

    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
     
    GianGuz, Dec 20, 2004
    #1
    1. Advertising

  2. GianGuz

    Tom Widmer Guest

    GianGuz wrote:
    > 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
     
    Tom Widmer, Dec 20, 2004
    #2
    1. Advertising

  3. GianGuz

    GianGuz Guest

    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
     
    GianGuz, Dec 20, 2004
    #3
  4. GianGuz

    Tom Widmer Guest

    GianGuz wrote:
    > 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
     
    Tom Widmer, Dec 20, 2004
    #4
  5. GianGuz wrote:
    > 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
     
    Jonathan Mcdougall, Dec 20, 2004
    #5
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. BobRoyAce

    Application "partitioning"

    BobRoyAce, Jan 24, 2005, in forum: ASP .Net
    Replies:
    2
    Views:
    342
    Suhaib Khan
    Jan 24, 2005
  2. Darrel

    Folder 'partitioning'

    Darrel, Apr 13, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    362
    Lau Lei Cheong
    Apr 13, 2006
  3. set partitioning

    , May 1, 2006, in forum: Python
    Replies:
    9
    Views:
    479
    Boris Borcic
    May 2, 2006
  4. Max Muermann

    [GOLF]: partitioning an array

    Max Muermann, Dec 7, 2006, in forum: Ruby
    Replies:
    6
    Views:
    107
    Trans
    Dec 7, 2006
  5. rajasekhar
    Replies:
    5
    Views:
    91
    -Lost
    Apr 21, 2007
Loading...

Share This Page