BW> Good point, I just used a quick example.  My real question was about
 BW> whether this would raise any objections, or if there's a better way to
 BW> get the job done.  I was confused about the way pointers were passed to
 BW> a function, and I still am to be honest about it!!  :-)
Before I start, I'll just say that I came into this half way through. I'm 
catching up on what has been quoted here. It looks like someone wants to do a 
realloc with a pointer returned by new.
If I'm wrong, I'll plead forgiveness in advance.
In the case of strings, you might be better off using a string class,  
escpecially if it has convertion member functions to and from const char*, 
which come into play without you having to think about it.
If you know and are very sure indeed that new and delete map onto malloc() 
and free(), and does no extra activity, (except maybe a throw), then you 
could use realloc() itself. There are various objections to this, which I'm 
sure some helpfu bunny will leap in and point out.
The quoted function will not copy the old contents. If this is not required, 
then that's fine and dandy, but if you want to copy realloc(), then you would 
need to do this.
I haven't tested it, and I'm sure I've missed a few things. 
char* new_realloc(char*oldblk, size_t newsize)
{
        char *newblk=new char[newsize+1];
        if (newblk != NULL)
        {
                strncpy(newblk,oldblk,newsize);
                newblk[newsize]='\0';
                delete []oldblk;
        }
        return newblk;
}
This assumes a character string, and that the contents of the "oldblk" string 
is a null-terminated string.
If you want a realloc() for any type of data, which can include null 
characters in the middle, then you could usethis slightly dodgy function.
void* new_realloc(char *oldblk, size_t newsize)
{
        void *newblk=(void*)new char[newsize];
        if (newblk != NULL)
        {
                memmove(newblk,oldblk,newsize);
                delete []oldblk;
        }
        return newblk;
}
It's dodgy, because if you are expanding a block, you will be copying from 
out of oldblk's bounds. If you don't have any MMU checks on memory bounds, 
you might be okay.
Alteratively, if you know of a way to obtain a new'd block's size, in a 
function which for no good reason I'll call GetChunkSize(), replace the 
memmove call with...
memmove(newblk,oldblk,min(newsize,GetChunkSize(oldblk));
with an extra function
inline size_t min(size_t a, size_t b)
{
        return (a> The lack of a test for NULL on the delete is troublesome,
 BW>   I have never heard of testing the results of delete, I thought it
 BW> returned void???  I have been checking new allocations though...
KK might have meant the pszP parameter is not checked. I don't know.
--- Spot 1.3a Unregistered
---------------