Re: C++ exception handling question [solved]

[hendrik@topoi.pooq.com]

On Mon, Nov 13, 2006 at 12:58:58PM -0700, Paul E Condon wrote:
> On Mon, Nov 13, 2006 at 02:05:20PM -0500, hendrik@topoi.pooq.com wrote:
> > On Mon, Nov 13, 2006 at 10:41:52AM -0700, Paul E Condon wrote:
> > > 
> > > I'm not a professional programmer, so my standards of reasonableness
> > > are not tempered by 'real world' experience. I use C++ to write
> > > simulation code for my research in biodiversity. It seems to me, from
> > > reading the doc.s, that realloc() should be used in the situation that
> > > you describe. It is possible to keep track of all places in the code
> > > that new objects are brought into use and check if space is available
> > > within the previously allocate block, and then use realloc() to expand
> > > the allocation if needed.
> > 
> > Doesn't realloc allocate new space, which means that the objects inside 
> > that space get moved?  Then you have to track down all the places where 
> > addresses of these objects are kept.
> 
> When it must allocate an entirely new block of RAM, reealloc() moves
> all existing data from the old block to the new block, It always
> returns a pointer to the block after allocating, unless it fails to
> allocate the requested extra RAM. Then it returns a null pointer.
> There is not much to track down. Everything in the new block is at
> exactly the same offset relative to the new pointer that it was at
> relative to the old pointer.
> 
> Actually, I'm not sure that it really does this. It may play with
> relocation registers to make it appear to the running program that
> it has moved the data, or it may play with the relocation registers
> so that it never has to actually return a pointer value that is 
> different from the calling pointer value. It all depends on what
> is available in the hardware memory management of the CPU chip.

Let's hope that it does do this, for efficiency's sake.  So if we always 
use offsets to access objects in the bigspace we'll be OK.  But if we 
use addresses there will be trouble becaues we have to locate all the 
addresses anywhere and change them.  Unles the software we are porting 
is specifically written for this, we're in trouble.

By the way, the ancient software I've had the pleasure of portinh 
where this issue came up was written for a nonmultiprogramming machine 
in which it was reasonable to allocate all of memory.  No one else was 
available to use it anyway.

-- hendrik