Tech Off Thread

10 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

C++ allocation operators

Back to Forum: Tech Off
  • User profile image
    rhm

    Has anyone got any idea why a class would implement the new and delete operators but not do anything special with them? I've got a whole load of code and every class has the following code at the top:-

    public:

        void* operator new(size_t,void* anAddress)
          {
            return anAddress;
          }
        void* operator new(size_t size)
          {
            return Standard::Allocate(size);
          }
        void  operator delete(void *anAddress)
          {
            if (anAddress) Standard::Free((Standard_Address&)anAddress);
          }


    Is this just a waste of time or is there a point to it?

  • User profile image
    W3bbo

    I thought "new" and "delete" were keywords, not operators.

  • User profile image
    rhm

    "keyword" just means any sequence of letters that's part of the language and thus not available for use as an identifier. A keyword can be an operator too as is the case with new and delete. Like other operators, they can be overriden by a class. The idea is that you can implement custom memory allocation schemes for particular classes like pooling or whatever.

    My question above is why override new and delete and then do basically what would happen anyway (as far as I can tell)?

  • User profile image
    DoomBringer

    overriding the new keyword, maybe for doing singletons, I dunno.  But singletons are usually done through the constructor, so I dunno.

  • User profile image
    Sophocle

    rhm wrote:


        void* operator new(size_t,void* anAddress)
          {
            return anAddress;
          }
        void* operator new(size_t size)
          {
            return Standard::Allocate(size);
          }
        void  operator delete(void *anAddress)
          {
            if (anAddress) Standard::Free((Standard_Address&)anAddress);
          }
    Is this just a waste of time or is there a point to it?


    The first new operator overload is for the new with placement syntax, instead of creating instances on the free store it will use the address you provided.
    This is useful for using preallocated memory (e.g. a buffer) to store your objects and still have the construtors and destructors called for these objects.
    Apparently this first overload is just the default one that would be generated by the compiler anyway.
    The second new and the delete operator overload are apparently defined because the coder wanted to use a custom allocator.
    If the first new overload seems useless but is still present it may be that the compiler is requiring it if you overload the new(size_t) one ( just a guess), try removing the new(size_t, void*) definition and see if the code still compiles and link.


  • User profile image
    rhm

    Thanks.

    I'd thought the Standard::Allocate() was part of the standard library, but it's not, it is a custom allocator, although looking at the code provided, it doesn't do anything special.

    The code comes from a large C++ project that like all large cross-platform C++ projects contains a lot of stuff you'd rather not think about, so it has it's own typedefs for all the basic types, it's own memory management (including Handle types), it's own string classes and container classes. And being pre-template C++ code, it even has it's own generic container pre-processor system.  What I'd like to do is port it into managed code using C++/CLI to eliminate all that crufty overhead code.

    What bothers me though is that in managed code you have to decide whether a class has ref or value semantics whereas in normal C++ a class can be instantiated in either way. Of course well designed C++ classes make it clear which way they like to be instantiated, but some of those in this project are used both ways. Oh well Smiley

  • User profile image
    Sophocle

    Instead of porting it to managed C++ couldn't you just 'upgrade' your code to the current C++ standard (use the STL) and clean it up (remove all useless multiplatform preprocessor stuff).
    Unless you really want/need to use winforms.
    For non GUI application managed C++ looks to me just like another overhead.



  • User profile image
    rhm

    What Managed really gains us is it simplifies the memory management massively. Nearly half of the classes in the project are handles for actual classes. Obviously I could get rid of those with a template now, but the real concern is this whole business of handle-based memory management where every bit of code that uses an object has to think about the lifetime of that object in some way.

    Unfortunately for garbage collection to work robustly you have to have a concrete barrier between value and reference types - specifically you can't ever have a reference to an object that's on the stack or allocated as part of another object. Dealing with that is pretty easy in new code, but when you've got a project where that barrier isn't observed it's a bit of a pain.

  • User profile image
    Sophocle

    There might be a lighter solution to your memory management problems than going managed.
    I am using smart pointers (namely the smart pointers library from Boost). No more memory leaks and dangling pointers problems since I don't have to worry about dynamically allocated objects lifetime anymore.
    And it is really easy to replace regular pointers with smart ones where ever there is  dynamic allocation in legacy code.




  • User profile image
    kriskdf

    rhm wrote:
    Has anyone got any idea why a class would implement the new and delete operators but not do anything special with them?


    One reason may be to help troubleshoot heap corruption.  Another may be to help troubleshoot memory leaks.  Those functions they call could have conditional compilation (or add special code as needed).

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.