Additions of pointer contents in C++ (although not what you may be thinking)

Started by
5 comments, last by MaulingMonkey 16 years, 11 months ago
During some development of my fabled memory manager class, would anyone happen to know a way to *combine* the contents of two pointers, or at the very least increase their bounds? Theoretically I think this should be possible, but was wondering if this was worth putting effort into researching. If you're not quite sure what it is I'm asking, a quick hypothetical. Let's say I use ::operator new(x) to allocate x bytes of memory. Now let's say I want to combine all of those x bytes with another array made with the same ::operator new(x) method. Would it be possible to take all x bytes from the first, all x bytes from the second and combine them into a new array with a final size of 2x? Physical contiguity would be a real plus, but if I can specify the final 'slot,' most likely the null terminator of the first array, to actually be a pointer to the beginning of the next set of memory I believe this would work. I'd like to be able to overwrite this new chunk of data with something along the lines of an independent class (this is for a memory pool) As far as I can tell it seems more or less impossible, but my knowledge of the little tricks of C++ is admittedly limited.
clb: At the end of 2012, the positions of jupiter, saturn, mercury, and deimos are aligned so as to cause a denormalized flush-to-zero bug when computing earth's gravitational force, slinging it to the sun.
Advertisement
when you allocate memory off the heap, it will look for the smallest possible portion of memory that meets your demand. in order to append one heap location to another you'd need those two locations to be contiguous. this would not be possible in most cases. there would be some times when there is some extra space left after the first allocation, but you wouldn't be able to specify that location without writing your own operating system. therefore, your only option would be to intentionally allocate more space than you need each time you allocate, which would give you a guaranteed buffer zone if you wanted to "increase" the size later. hwoever, as you can see, it would be completely impossible to make two random heap locations contiguous without reallocating their combined size.
Well, if you just want to be able to dynamically increase the size of an array of other kind of list without reallocating, then you can implement it as a linked list. If you want to be able to use the array access operators on this, just overload them. With this implementation, if you have one pointer to an array, and another pointer to an array, you could just link the two together...and be able to treat it as one large contiguous array. does that solve your problem?
The pieces don't quite fit together right here.

I think some aspect(s?) of your C++ comprehension have been confused, but I can't put my finger on what. Every time this has happened to me before, I've been able to deduce a clear question to ask for clarification. Not this time. It's like I've seen the leaning tower of Pisa - it was constructed with a level foundation, and all the blocks fit together right, but still, something is not quite right. And it's not quite right in a way that makes me unable to understand exactly what it is you're asking. (Maybe one of those perpetual staircases might have been a better analogy? Probably -- I'm perplexed, and going in circles, yet still gaining no understanding in this perpetual self-loop)

So lets try another angle: Can you show us psuedo-C++-code of what this might look like if you could accomplish this in C++?
yahastu.. you spy
Actually now that I think about it this wasn't as good/practical as I thought... The core idea was to make 'blocks' of memory in specific sizes (maybe like 64KB, although this is 100% arbitrary) and group/concatenate(sp?) them in order to make a final 'block' with at least as much capacity as was requested (i.e. if we requested like 392kb or whatever we'd take 7 blocks for a total of 448KB and return that. If it is possible, I'd definitely like to go with it as it's very intuitive. If not, oh well.
clb: At the end of 2012, the positions of jupiter, saturn, mercury, and deimos are aligned so as to cause a denormalized flush-to-zero bug when computing earth's gravitational force, slinging it to the sun.
Quote:Original post by InvalidPointer
Actually now that I think about it this wasn't as good/practical as I thought... The core idea was to make 'blocks' of memory in specific sizes (maybe like 64KB, although this is 100% arbitrary) and group/concatenate(sp?) them in order to make a final 'block' with at least as much capacity as was requested (i.e. if we requested like 392kb or whatever we'd take 7 blocks for a total of 448KB and return that. If it is possible, I'd definitely like to go with it as it's very intuitive. If not, oh well.


What you can do is create a larger block, and then keep track of your own "subblocks" of whatever size (the simplest form of tracking would be an extra array of bits marking each block free or not free). Allocation then is a matter of finding requested_size/block_size blocks in a row that are free (rounding up) -- growing is a matter of checking if the block(s) after your existing range are all free -- and merging arbitrary already "allocated" blocks is left in the realm of "bad ideas".

But no, you can't simply merge a random set of blocks in a way that any arbitrary class is going to be able to handle.

This topic is closed to new replies.

Advertisement