Well, I''ll be d*****. You''re right, Mithrandir. I could have sworn that there was a C library function guaranteeing that, at the cost of heap fragmentation. My bad.

Why not just make your own function to do it? It should be too hard, if you know the size of the block as it is. I really don''t see why realloc() doesn''t work tho. it should. Maybe it has something to do with how realloc() knows just how large the data space at the pointer is.. Anyone know just how it does know that? And speaking of realloc(), I just looked it up and read something I hadn''t known before. Error? It looses your data completely. How nice of it.

Anyway, lets make this function. void *remem(void *aPtr, uint aOrigSize, uint aNewSize); should be sufficient. It is a habbit of mine to begin all arguments with ''a'' to seperate them from other variables.

Since we don''t have access to more knowledge of the system, we have to do this an ugly way and just deal with it. So, we make a temperary holding space like this: char *temp = new char[aNewSize]; and then we copy memcmp(aPtr,temp,aNewSize); and delete aPtr; (make an alternate rememC() that free()''s it instead and uses malloc() for temp!)

Finally, return the temp and we have the final functions:

void *remem(void *aPtr, uint aOrigSize, uint aNewSize)
{
char *temp = new char[aNewSize];
memcmp(aPtr,temp,aNewSize);
delete aPtr;
return temp;
}

This could definatly be optimized. But you get the idea.

Thats nice, but doesn''t call the constructors for the newly allocated objects. Also, the memcmp() would slow it down too much (for what I need it for, anyway).

www.elf-stone.com

and the "delete aPtr" would destruct that object...
I think that if you''re lucky it might work, nut I wouldn''t count on it. And I wouldn''t count on it working the same way every time you do it (hence quite useless, though others might disagree with me)

You are not going to get any better than allocating the new block of memory, copying from the old block to the new block and deleting the old block.

realloc() never guaranteed that the new block will be at the same address. That is the reason it returns a pointer. This returned pointer could very well be different to the pointer you passed to it.

I made my own realloc() equivalent that uses new and delete. MEM_Alloc() and MEM_Free() are just wrappers around new and delete.

void *MEM_Realloc(void *ptr, unsigned long newSize, unsigned long oldSize){  if (!ptr)    return MEM_Alloc(newSize);  else  {    void *temp = MEM_Alloc(newSize);    if (temp)      memcpy(temp, ptr, newSize > oldSize ? oldSize : newSize);    MEM_Free(ptr);    return temp;  }}

This routine requires that you pass the size of the old block along with the size of the new block so it can correctly copy the contents of the old block to the new block.

quote:

---

Original message by ironfroggy

And speaking of realloc(), I just looked it up and read something I hadn''t known before. Error? It looses your data completely. How nice of it.

---

Err, no it doesn''t. Here''s the excerpt from MSDN on realloc()...

The size argument gives the new size of the block, in bytes. The contents of the block are unchanged up to the shorter of the new and old sizes, although the new block can be in a different location. Because the new block can be in a new memory location, the pointer returned by realloc is not guaranteed to be the pointer passed through the memblock argument.

quote:

---

Original message by benjamin bunny

Thats nice, but doesn''t call the constructors for the newly allocated objects. Also, the memcmp() would slow it down too much (for what I need it for, anyway).

---

The call to new for the new memory block would call the constructors for those objects. Then the memcpy will copy the contents of the old objects over the new objects. What exactly do you need it for? Maybe you need a linked list where you can allocate blocks of objects and when required, allocate an extra block and just link it to the last object in the old block.

Steve ''Sly'' Williams  Code Monkey  Krome Studios

templatevoid Realloc(T *memPtr, int sizeOfVar, int sizeToAdd, bool array){	delete [] memPtr;	memPtr = new T[sizeOfVar + sizeToadd]} 

Nasty example, but it should work.

It will not work whatever you say (at least not for generic objects, perhaps for some objects).

And why would you want to do that anyway? The only reason I can think of is when you have an array of objects allocated with new[] and you want to reallocate that array.

Most people above have suggested a scheme where you copy old data into a new object allocated with ''new'' and then the old one is deleted with ''delete''. This will only work for singular objects (new != new[] and delete != delete[]) and since "reallocating" an object to make it larger/smaller isn''t very well defined (it wouldn''t be the same object anymore) those suggestions are no good.

If you want to have a dynamically resizable array of objects use the appropriate STL template class (as alot of people also have suggested) such as ''vector''.

I have a question about realloc...

If you request more memory to be allocated, and there is no more memory available, then realloc returns NULL. But was the memory de-allocated? I suspect it isn''t, but I need to be sure.

In general, realloc tries to allocate memory first. If that succeeds, it copies the existing data to the new location. Finally it frees the old memory. So if realloc cannot allocate memory it doesnt do the copying or the freeing. But if realloc returns NULL then you''re probably up the creek already...

Well, better to quit and display the message "out of memory" than to perform an illegal operation.