Question: 'set_new_handler(terminate)' removes need to handle std::bad_allocexception?

[Asfand Yar Qazi]

Hi,

Just wondering, if I do a:

std::set_new_ha ndler(std::term inate)

I won't have to worry about a std::bad_alloc being thrown when I do a
'new ...' or a 'new(nothrow) ...', right?

Its just that I'm writing a Ruby extension, and I tried wrapping C++
code in a generic exception-catching net, but it broke (I got all sorts
of wierd and not-so-wonderful errors.) It seems that Ruby uses
setjmp/longjmp for exceptions, and that is incompatible with the G++
3.2.2 way. Oh well...

Thanks in advance,
Asfand Yar


--

http://www.it-is-truth.org/

[Attila Feher]

Re: Question: 'set_new_handle r(terminate)' removes need to handle std::bad_alloc exception?

Asfand Yar Qazi wrote:[color=blue]
> Hi,
>
> Just wondering, if I do a:
>
> std::set_new_ha ndler(std::term inate)
>
> I won't have to worry about a std::bad_alloc being thrown when I do a
> 'new ...' or a 'new(nothrow) ...', right?
>
> Its just that I'm writing a Ruby extension, and I tried wrapping C++
> code in a generic exception-catching net, but it broke (I got all
> sorts of wierd and not-so-wonderful errors.) It seems that Ruby uses
> setjmp/longjmp for exceptions, and that is incompatible with the G++
> 3.2.2 way. Oh well...[/color]

The setjmp/longjmp pair is incompatible with any C++ code using non-trivial
classes. Anyway I think that setting the new handler to terminate should
avoid bad_alloc. However it will not avoid things. If you do get a longjmp
while you are in C++ code _none_ of your desctructors will run. I mean if
the longjmp jumps over the C++ code back to the original calling C. Also,
it will only avoid this particular exception, in this particular case. So
if you use the Standard Library or anything else using exceptions you are
better off having a catch(...) on your C++ functions (I guess they are
callbacks from C?) and turn those exceptions into something Ruby can
understand.

--
Attila aka WW

[Asfand Yar Qazi]

Re: Question: 'set_new_handle r(terminate)' removes need to handle

> The setjmp/longjmp pair is incompatible with any C++ code using non-trivial[color=blue]
> classes. Anyway I think that setting the new handler to terminate should
> avoid bad_alloc. However it will not avoid things. If you do get a longjmp
> while you are in C++ code _none_ of your desctructors will run. I mean if
> the longjmp jumps over the C++ code back to the original calling C.[/color]

Thanks for the heads-up: I didn't know that. This is only for stuff
allocated on the stack, right? If I compiled Ruby with C++ instead of
C, would this problem remain? I mean, I'd be moving from C++ to... C++!

As for the destructors problem with regards to heap allocated objects,
Ruby has its own garbage collector, and allows one to specify ones own
freeing routine, so I just pass it a pointer to a 'void
delete_MyType(M yType* p) {delete p;}' function along with the objects
pointer, and it frees it OK.
[color=blue]
> Also,
> it will only avoid this particular exception, in this particular case. So
> if you use the Standard Library or anything else using exceptions you are
> better off having a catch(...) on your C++ functions (I guess they are
> callbacks from C?) and turn those exceptions into something Ruby can
> understand.
>[/color]

That's what I'm saying: I already tried that 'wrapping' and for some
strange reason, it really mucked up Ruby's internal state.

Thanks,
Asfand Yar



--

http://www.it-is-truth.org/

[Alexander Terekhov]

Re: Question: 'set_new_handle r(terminate)' removes need to handle

Hi WW,

Attila Feher wrote:
[...][color=blue]
> The setjmp/longjmp pair is incompatible with any C++ code using non-trivial[/color]

http://www.codesourcery.com/archives/c++-pthreads/msg00126.html

[color=blue]
> classes. Anyway I think that setting the new handler to terminate should
> avoid bad_alloc. However it will not avoid things. If you do get a longjmp
> while you are in C++ code _none_ of your desctructors will run. I mean if
> the longjmp jumps over the C++ code back to the original calling C. Also,
> it will only avoid this particular exception, in this particular case. So
> if you use the Standard Library or anything else using exceptions you are
> better off having a catch(...) on your C++ functions (I guess they are
> callbacks from C?) and turn those exceptions into something Ruby can
> understand.[/color]

http://www.codesourcery.com/archives/c++-pthreads/msg00291.html

regards,
alexander.

[Attila Feher]

Re: Question: 'set_new_handle r(terminate)' removes need to handle std::bad_alloc exception?

Alexander Terekhov wrote:[color=blue]
> Hi WW,
>
> Attila Feher wrote:
> [...][color=green]
>> The setjmp/longjmp pair is incompatible with any C++ code using
>> non-trivial[/color]
>
> http://www.codesourcery.com/archives.../msg00126.html
>[color=green]
>> classes. Anyway I think that setting the new handler to terminate
>> should avoid bad_alloc. However it will not avoid things. If you
>> do get a longjmp while you are in C++ code _none_ of your
>> desctructors will run. I mean if the longjmp jumps over the C++
>> code back to the original calling C. Also, it will only avoid this
>> particular exception, in this particular case. So if you use the
>> Standard Library or anything else using exceptions you are better
>> off having a catch(...) on your C++ functions (I guess they are
>> callbacks from C?) and turn those exceptions into something Ruby can
>> understand.[/color]
>
> http://www.codesourcery.com/archives.../msg00291.html[/color]

In theory.. :-(

--
Attila aka WW

[Asfand Yar Qazi]

Re: Question: 'set_new_handle r(terminate)' removes need to handle

Bog it all to Hell - I'm getting the aborts out!

Waiting for a scripting language compatible with C++ exceptions,
Asfand Yar



--

http://www.it-is-truth.org/