Re: C++ exception handling question [solved]
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.
> >
> > Personally, I wonder about the quality of a program design that
> > requires that objects that are initialized at different times be
> > stored is a single contiguous block of RAM. I think that pointers and
> > references have long been known as a way to free oneself of this
> > problem. But, I'm not a professional.
>
> It happens especially when porting sotware written for other systems,
> especially software that has its own memory allocation subsystem. For
> example, it may use compressing garbage collection, or multiple stacks.
> Reserving address space separate from allocating storage within that
> space is a natural thing to do. But I agree, malloc is not the proper
> tool for this, and I too would prefer to have a malloc that commits to
> making the storage available, and otherwise indicates that it cannot.
We agree, and you've helped me. When I posted the 'solved' message
with comments, I hoped to get a message into the archive that would be
discovered future programmers who were having trouble getting C++
exception handling to work. The problem is not C++ exception handling,
but is a 'feature' of the kernel that interfers with C++ exception
handling. Now this thread will surely not be missed. Thanks.
--
Paul E Condon
pecondon@mesanetworks.net
Reply to: