octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to return to top level and release memory


From: Andy Adler
Subject: Re: How to return to top level and release memory
Date: Sat, 30 Aug 2003 20:38:22 -0400 (EDT)

On Sat, 30 Aug 2003, John W. Eaton wrote:
> On 29-Aug-2003, Andy Adler <address@hidden> wrote:
> | Currently, when I detect a singular sparse matrix, I throw
> | an error, using the following
> |
> |  error("sparse: %s", str); octave_throw_bad_alloc ();
> |
> | Is there a proper way to get out of a deeply nested function,
> | (freeing memory on the way), and back to the interpreter?
>
> Throwing an exception will do the right thing if all resources are
> allocated in constructors and deallocated in destructors, because in
> the process of handling the exception, destructors are called for all
> "live" objects (simplified explanation).  But there is no magic way to
> handle resources that are allocated/deallocated outside of
> constructors/destructors, though the auto_ptr class can help.

Thanks for the info. I'll check if I'm doing this

> We use exceptions for this purpose now when handling interrupts.
> Inside the interrupt handler, we set a flag (octave_interrupt_state)
> and then throughout the rest of Octave we have the OCTAVE_QUIT macro,
> which expands to
>
>   do
>     {
>       if (octave_interrupt_state)
>         {
>           octave_interrupt_state = 0;
>           octave_throw_interrupt_exception ();
>         }
>     }
>   while (0)

Just for my curiosity, why is the "do {} while(0)" necessary?
Wouldn't a bare block have the same effect?

>  So we probably need a generic error exception.  In keeping
> with the way that the error function works in .m files (automatically
> terminating execution of the current function) we should probably
> consider making the C++ error function do the same, throwing the new
> generic error exception for you.

I would like this. I've never felt entirely comfortable with "error()".
The semantics of this call were never quite clear to me. I think this
proposal corresponds better to what the programmer expects.

andy



reply via email to

[Prev in Thread] Current Thread [Next in Thread]