Can 'delete []' truncate?
Author
Howdy folks~
Trying to write my own memory vector class, and one of it's jobs is to shorten itself by half if only a quarter of the memory it owns is being used.
All the data it has allocated is stored in an "unsigned char * array" that is created using "array = new unsigned char[vectorsize * type_size];"
It'd be pretty wasteful to deallocate the orignal data array when half of it is still good. But as I understand it, for 'delete []' to work, you have to pass the original pointer that 'new' returned. I might be wrong about that though.
So I was wondering if it'd be possible to free only a section of the end of the array instead of the whole thing. I know it's probably a trivial concern, but I'm curious~
Thanks!
Nope. You'd have to allocate again, the amount you wanted. Copy everything over then free the original pointer.
new/delete keeps a bunch of bookkeeping information about each allocation, and won't split something already allocated, and won't let you free anything but the exact pointer that was returned with new.
new/delete keeps a bunch of bookkeeping information about each allocation, and won't split something already allocated, and won't let you free anything but the exact pointer that was returned with new.
Is there any reason why you can't just use std::vector<unsigned char>? This would safe you from having to worry about the underlying memory handling, as std::vector takes care of it for you.
Quote:Original post by Clairvoire
and one of it's jobs is to shorten itself by half if only a quarter of the memory it owns is being used.
Normal implementations of the closest thing in the standard library (std::vector) don't attempt to do this, presumably for good reason.
Author
Quote:Original post by KulSeran
Nope. You'd have to allocate again, the amount you wanted. Copy everything over then free the original pointer.
new/delete keeps a bunch of bookkeeping information about each allocation, and won't split something already allocated, and won't let you free anything but the exact pointer that was returned with new.
nngh, I was afraid of that. Thanks for letting me know though, it was worth a try.
Quote:Original post by DevFredQuote:Original post by Clairvoire
Trying to write my own memory vector class
Why?
Well, I figured it would be a good learning experience, which it has, haha. I'm also a little, um, uneasy around anything that involves STL Templates.. I do like to worry about how my memory is being moved around, maybe a little too much~
Quote:Original post by Zahlman
Normal implementations of the closest thing in the standard library (std::vector) don't attempt to do this, presumably for good reason.
You've got a point there. It probably would be pretty pointless to resize the vector to a smaller size unless the circumstances were pretty extreme. Probably if it shrunk to 1/16th the size, and stayed that way for a while. Or maybe not, eheh, I always forget how cheap memory is these days. xD
Quote:Original post by ClairvoireQuote:Original post by KulSeran
Nope. You'd have to allocate again, the amount you wanted. Copy everything over then free the original pointer.
new/delete keeps a bunch of bookkeeping information about each allocation, and won't split something already allocated, and won't let you free anything but the exact pointer that was returned with new.
nngh, I was afraid of that. Thanks for letting me know though, it was worth a try.Quote:Original post by DevFredQuote:Original post by Clairvoire
Trying to write my own memory vector class
Why?
Well, I figured it would be a good learning experience, which it has, haha. I'm also a little, um, uneasy around anything that involves STL Templates.. I do like to worry about how my memory is being moved around, maybe a little too much~Quote:Original post by Zahlman
Normal implementations of the closest thing in the standard library (std::vector) don't attempt to do this, presumably for good reason.
You've got a point there. It probably would be pretty pointless to resize the vector to a smaller size unless the circumstances were pretty extreme. Probably if it shrunk to 1/16th the size, and stayed that way for a while. Or maybe not, eheh, I always forget how cheap memory is these days. xD
If you are concerned about how your memory is being used by the STL then provide your own allocator. There is no need to rewrite the whole datastructure for that reason. Open <vector> and check out the declaration for std::vector, its last parameter is an allocator type that is defaulted to the std::allocator.
This is something i have done myself however i have a good reason for doing it and an understanding of the benefits. It appears to me that this is something where, if you have to ask how to do it, then you probably shouldn't be.
I don't mean to sound patronising, but i suggest that you probably don't NEED to do this. If you are really only doing it for learning then fine. :).
You need to write your own heap manager that supports such operation.
Allocate one huge block of memory, the provide pointers into that for use by your vector. Implement realloc operation on top of that.
At this point you'll realize the problems that occur due to holes and fragmentation, as well as the cost of managing such structure.
First, learn what STL is, and *why* it works in the way it does. Those classes aren't clumsy, they are ideally suited for C++.
Continue here, and realize that the methods discussed will be as good as it gets for a very long time.
Allocate one huge block of memory, the provide pointers into that for use by your vector. Implement realloc operation on top of that.
At this point you'll realize the problems that occur due to holes and fragmentation, as well as the cost of managing such structure.
First, learn what STL is, and *why* it works in the way it does. Those classes aren't clumsy, they are ideally suited for C++.
Continue here, and realize that the methods discussed will be as good as it gets for a very long time.
Actually, I'd say that if you are uneasy about what the STL is doing behind your back, spend some time exploring the STL. The code style takes a little getting used to, but honestly it IS good code and I have yet to see any STL class in any STL implementation where I couldn't figure out what it was doing and how. Get to know your library! It's the right cure for the I Don't Trust What I Can't See syndrome.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
