Allocate dynamic memory Borland C++ 4.5

I will put aside the reason _why_ you want to allocate memory in an embedded system -- usually this is a Bad Idea, so expect someone (maybe me, if I get time) to question you closely on what you're trying to do, and why.

I'm pretty sure that the memory allocation only works up to 65536. This is consistent with the limitations of Borland under DOS (and, perhaps, of DOS itself). Remember that the 80186 is pretty much a 16-bit processor with a strange memory paging scheme. So it's really easy to write a memory allocator that only works on blocks up to 2^16.

I suspect that you're going to have to make your own memory allocator. You could test this by dredging through the header files ("new.h" is, I think, the one you want to look for) and see what the argument is to the default new [] operator. I suspect that it'll be of type int, which means that 65536 turns to zero. You can do the same thing for malloc -- if it takes a 16-bit integer, then the memory system simply cannot allocate more.

Assuming that there isn't a "huge_malloc" (or something) already, you'll probably have to make one -- and you'll have to make a "malloc" and a "free" to go along with it. Then, to add insult to injury, if my suspicions are correct you won't be able to use new [] _at all_, and will, instead, have to do it the old fashioned way.

On the plus side, there's plenty of nice memory allocators out there, so you don't have to be on your own.

I think you are going to be hosed by the 64k segmentation limit even if you do write a memory allocator that can get you more than the 64K - in multiple bytes. There are int86 calls that deal with this, I had many reboots trying to use them many years ago. Get a hold of the old "Programmers PC Sourcebook", this lists all the int86 calls.

I think this is going to be hard row to hoe.

Good Luck, Mike

I don't think a "PC Sourcebook" is going to have much relevance to an

It's been a long time, but IIRC Borland C(++) had hmalloc() [maybe with leading underscore] which could allocate chunks equal/larger than

malloc/free can be used in C++ if you are careful: e.g., a C++ object located in a malloc'd block must be created using placement new() and destroyed *manually* by calling its destructor (~) function ... do NOT call delete() on such objects or you'll completely f_ up your heap.

If applicable, the malloc'd block itself should be free()'d when you're done with it. Again, do not use delete().

You need to keep a huge pointer to the base address of your block, and if you subdivide it, use huge pointers and huge arithmetic when creating new pointers into the block. You can convert them to far pointers to hand out to other code if the subdivisions themselves are smaller than 64K.

The really important points are to use placement new() and _not_ to use delete().

Hope this helps, George

an

of

NULL

Thanks George, but What do you mean when you say placement new()?

--------------------------------------- Posted through

Normally when you call new(), it allocates a memory block from the heap and then constructs the desired object (or array of objects) in that block.

Placement new() is a variant that *only* constructs the desired object in an already existing memory block whose address is passed to the new() call.

These links are (mostly) consecutive on the same page - start with the

One problem with placement new() is that there is no array version. To create an placed array, you need to determine the size of the elements and step a pointer performing a placement new() at the desired address of each element individually. Then to destroy the placed array, you must step through again calling the destructor of each element individually. [This implies that every element type must have both constructor and destructor - even if they are trivially empty.]

This is actually what new[] does after allocating a heap block, and what delete[] does before releasing the block ... but you must do it all manually to (re)use an already existing block instead of allocating a new one.

Hope this helps, George

an

of

(0xFFFF

Thanks Tim

--------------------------------------- Posted through