🔒 Locked

overloading operator delete(void*, size_t);

Started by temp_ie_cant_thinkof_name Jan 19, 2004 at 3:21 AM 3 replies 250+ views

Original Post

Jan 19, 2004 at 3:21 AM

There is absolutely zero documentation published on the internet that tells you how exactly the function definition of this would work. MSDN and my SDK Documentation both say the same thing: It's good for putting in base classes where the size of the derived class is unknown. I understand that, b/c the size of the class hiearchy changes and thus the size of the derived objects. What I don't understand is how to actually use that size information passed in implicitly as a parameter. Would I do: class A {public: void operator delete(void* ptr, size_t size) { delete(size) p; }}; like you can do with new if you overload it, or what? Oh yeah, I'm concerned b/c the example of the thing I'm implementing also overloads this, however, they don't use the size parameter besides checking it with the size initially passed into the class; if the sizes don't match then the deletion isn't done, otherwise they just call delete ptr; Which is completely pointless IMO. That's why I'm about to just overload operator delete(void* ptr), and worry about inheritance when it comes... [edited by - temp_ie_cant_thinkof_name on January 19, 2004 4:23:30 AM] [edited by - temp_ie_cant_thinkof_name on January 19, 2004 4:24:01 AM]

SiCrane

Mod

473

SiCrane

Jan 19, 2004 at 4:09 AM

operator delete(void *, size_t) is useful when doing a custom memory manager or possibly a logging memory manager. If all you''re going to do is call ::operator delete() or free(), then the size parameter is pretty worthless.

Possible uses for the size paramter: for memory pooling, returning the memory block to the correct pool, for logging, marking how many bytes are being freed, for heap consistency checks or for marking byte patterns in freed areas.

temp_ie_cant_thinkof_name

Author

temp_ie_cant_thinkof_name

Jan 19, 2004 at 11:06 AM

Hmmm... That''s what MSDN, documentation, and anybody else says. I''m specifically doning object pooling. Now...how do I implement this checking of size? B/c for each deletion of a derived class, my embedded object''s delete class is only called once, or is it... Am I supposed to embed an object pool in each and every derived class? I guess I should... Does this mean I have to check for the size being deleted in each destructor? B/c potentially each base class in the hierarchy has this. Well, I see how it works now, thanks SiCrane.

SiCrane

Mod

473

SiCrane

Jan 19, 2004 at 11:40 AM

Here''s a more concrete example. Let''s pretend that I have three memory pools in my program. An 8 byte pool, a 32 byte pool, and a 64 byte pool. Any memory allocation for less than or equal to 4 bytes goes to the first pool and so on. So I could have code like this (where pool08, pool32 and pool64 are probably global objects):


class BaseObject {
  public:
    virual ~BaseObject() {} // needs a virtual destructor or all hell breaks loose
    void * operator new(size_t size) {
      if (size <=  8) return pool08.alloc();
      if (size <= 32) return pool32.alloc();
      if (size <= 64) return pool64.alloc();
      else return ::malloc(size);
    }
    void operator delete(void * ptr, size_t size) {
      if (size <= 8) {
        pool08.free(ptr);
        return;
      } else if (size <= 32) {
        pool32.free(ptr);
        return;
      } else if (size <= 64) {
        pool64.free(ptr);
        return;
      } else {
        ::free(ptr);
      }
    }
};

In this manner every derived class will be allocated from the correct pool, and when deleted it''s memory will be returned from the correct pool. You don''t need to embed the pool in every derived class, nor do you need to do special checking in the derived classes'' destructors.

TangentZ

Jan 19, 2004 at 11:42 AM

Zero documentation?

Have you read Effective C++, More Effective C++...etc, etc? o_O

Kami no Itte ga ore ni zettai naru!

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.