Memory manager deal

On my free time lately I've been trying to get this damn memory allocation/deallocation/construction class figured out, but my experience working with stuff at this low of a level is limited and resources are scarce it seems. Anyway, the basic gist of my class right now is you can tell it to allocate space for n objects of type T for you, and then it returns a pointer to that space. I believe I have that working fine, but I can't for the life of me figure out what I need to do to get objects constructed on that space in array form (it's for my vector class, and other data structures for those of you who helped me in the past) without requiring a default constructor or copy constructor. Maybe one of those has to be there? I don't know, because there's not much on the web about this topic it seems.

The logic of my construction is kind of iffy too. Since the memory class has the construct method (seems standard), how does it know where to put the objects? Does the user side have to supply a pointer to the given area? Or can I somehow make the memory manager know where the next element should be, but at the same time let it be used for multiple instances? And if the user has to supply the exact location, how does that work? Do they just keep passing in the pointer to the beginning of the memory with incrementing offsets?
closed account (zb0S216C)
How are you allocating your memory?

Wazzak
Last edited on
without requiring a default constructor or copy constructor.


A copy constructor is already going to be a requirement for a vector style container because you'll have to copy/move all the objects when the array needs to be reallocated. So that's pretty much going to be expected. Copy (or at least Move) constructors are required for any objects you put in an std::vector.

And since it's already an expected requirement, you might as well use it when adding items to the vector initially.


The only way around it that I can think of would be to have some kind of callback mechanism where the user can provide their own function to construct the object. But talk about overly complicated and counter-intuitive.


Since the memory class has the construct method (seems standard), how does it know where to put the objects?


I'm not sure I know what you mean by "the memory class". Are you talking about the vector class?

Anyway... there are two different parts to object creation:

1) allocating the memory for the object(s)
2) calling the object constructor.

Likewise, teardown consists of the same 2 parts, reversed:

1) calling the object destructor
2) freeing memory for the object(s)



std::vector allocates space for 'capacity' objects. So if each object is 16 bytes, and you have capacity=16... it will have 256 bytes allocated.

As elements are added to the vector, it will begin constructing objects (using placement new, or really an 'std::allocator' interface which typically just wraps placement new) within that allocated memory.
> And if the user has to supply the exact location, how does that work?
> Do they just keep passing in the pointer to the beginning of the memory with incrementing offsets?
Yes. allocator.construct( size++, elemen );
where `size' points to past the constructed region.
How are you allocating your memory?

I was using malloc(sizeof(T) * n), but switched to new to stay consistent. I was mixing malloc and new and delete. Now it's all C++ style.

A copy constructor is already going to be a requirement for a vector style container because you'll have to copy/move all the objects when the array needs to be reallocated.

That's a good point. It's reasonable to assume the user has made a copy constructor if the default doesn't suffice.

I'm not sure I know what you mean by "the memory class"

Sorry I meant the allocator class. I refer to it more as a memory manager class because it does more than just allocate.

So a push_back() method may look something like:

1
2
3
4
5
void push_pack(T element)
{
   allocator.construct(size++, element);
   //with some error checking and bounds checking and what not
}
Yep. That's basically it.
Well I'll be damned. In my head I had this much more complicated.
although you'd have to give the allocator a pointer and not the size. So it'll probably look closer to this:

1
2
3
4
void push_pack(const T& element)
{
   allocator.construct( &memory[size++], element);
}


Assuming 'memory' is a pointer of type T* which points to allocated (but not fully constructed) memory.
That makes more sense. I was going to perform the pointer arithmetic in the allocator class, but makes more sense here.
> although you'd have to give the allocator a pointer and not the size.
1
2
3
4
T 
   *begin, //start of allocated memory
   *size, //one pass the constructed memory
   *end; //one pass the allocated memory 
I would expect a variable named 'size' to be the size. Not a pointer.
@ResidentBiscuit
Not sure if you noticed this yet, but with a minor change to the deallocate declaration (add size_t) your allocator works with std::vector, at least with T = int
http://ideone.com/pTt7vh

EDIT: The next step might be making your vector allocator aware.
Last edited on
@Naraku, ill have to check this out when I get to my computer. If you pulled that off my source forge page, it's outdated at this point. Ill get the newest one uploaded tomorrow. I should really learn to use git efficiently -_-
Ooh nice guide. Bookmarking this. I have the memory manager finally pushed out there so it's a little easier to get to. And the file is updated if anyone wants to actually download it.

Not sure if you noticed this yet, but with a minor change to the deallocate declaration (add size_t) your allocator works with std::vector, at least with T = int

Why would size need to be passed in there? Shouldn't deallocate already just free everything that was allocated to that pointer? And at some point I'll need this to work with linked structures as well (I think, haven't gotten there yet).

EDIT:
Also pushed out the most recent copy of the vector class, with some integration of the memory manager
Last edited on
Topic archived. No new replies allowed.