Jump to content
  • Advertisement
Sign in to follow this  
NFalcon

Need the Type in overloaded new

This topic is 4049 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello. I am currently trying to write a memory manager and I am doing it by overloading the new operator. (Now I know a lot of you will be upset to hear that and will probably complain and say "You shouldn't do that!", but I'm not here to discuss that!) My problem is this: When overloading new I malloc the new information like so, but I also want to store the memory which is allocated into a hash table which I have created and sort the object based off of it's type or better it's size. void* operator new(size_t size) { void* temp = malloc(size); // Storing the variable in the hash CMemPool::GetInstance()->HashTable.pushback(temp); return temp; } The issue is, I can't get an appropriate type or find a way to pass in my size without screwing with the hash tables functionality (And I don't want to do that). The reason I can't get these is because inside new the temp is created as a void* and every item gets stored inside of bucket 4, because of the size of the pointer... =( Is there anyway I can get the type which is allocated inside of new or get the size of the chunk of memory the pointer is pointing to? [Edited by - NFalcon on June 14, 2007 6:04:31 PM]

Share this post


Link to post
Share on other sites
Advertisement
I believe this isn't possible.

The type of class (is it even class?) is irrelevant to the global new operator.

The only way I see is by defining an allocator for each class you intend to pool.


#include <new>
using namespace std;

template < class T >
void mark_allocation
{
// generate some id for T, typeid would be good
// mark that in bucket
}

class X
{
public:
void* operator new(size_t)
{
mark_allocation<T>();
// allocate from pool
}
};

// ...

int main ()
{
X* ptr = new X;
}



Note I'm not sure about syntax above and I can't verify it now.

Share this post


Link to post
Share on other sites
Or just pool them by size (which is what many mem managers do). You already have the size info so just round it up to the nearest bucket size

-me

Share this post


Link to post
Share on other sites
Am I missing somthing? You don't know the type, but you know the size (it's a parameter after all). Rather than storing pointers in the hash table, store this struct:
    struct AllocationInfo
{
void * address;
size_t size;
};

Share this post


Link to post
Share on other sites
Thats seems like a very good idea. I shall give it a shot. I had thought before that it might cause problems or changes within my hash table if I stored structures instead of the pointers them selves, but after hearing you mention it I really think this should work. Thanks!

Share this post


Link to post
Share on other sites
If you need to know the type, you shouldnt overload ::operator new(). You should overload the new operator for your type. Have it pass it's type to a global pool allocator.

The right thing to do if you're trying to write a memory manager is to replace ::operator new. The wrong thing to do is to combine memory management and object management. A good design will have an object (the memory manager) have one clear, unambiguous purpose. Not two. Two is not a reasonable number. The only reasonable numbers are zero, one, and infinity.

Share this post


Link to post
Share on other sites
Well the reason behind wanting the size and/or the type was not because I wanted to manage objects and memory at the same time, it was because I wanted to see which items were possibly not getting removed when they should be by which bucket they were being placed into.

Share this post


Link to post
Share on other sites
Quote:
Original post by NFalcon
Well the reason behind wanting the size and/or the type was not because I wanted to manage objects and memory at the same time, it was because I wanted to see which items were possibly not getting removed when they should be by which bucket they were being placed into.


This is much better done by stack walking (see google for examples). There you don't rely on type, but on the point in code (file, line) where the allocation was made. So there's no guessing as to what or where.

After all, what would you do if your leak report said 786 ints were not deleted?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!