Subject: Re: [boost] [context] new version - support for Win64
From: Oliver Kowalke (k-oli_at_[hidden])
Date: 2011-01-16 05:53:25
Am 16.01.2011 11:42, schrieb vicente.botet:
> ----- Original Message -----
> From: "Oliver Kowalke"<k-oli_at_[hidden]>
> Sent: Sunday, January 16, 2011 11:25 AM
> Subject: Re: [boost] [context] new version - support for Win64
>> Am 16.01.2011 10:50, schrieb vicente.botet:
>>>> In the docu the interface of boost::context is described (reference
>>>> part) - to be more correct context::jump_to() throws if the context is
>>> Where is written in the documentation that "the code jumped into via context::jump_to() must not throw"
>> section 'Context Management' sub-section 'launching' -> Warning
> I see now. Can you add the constraint on the reference section? Can we force this by the C++ type system?
no - you can't prevent that a user throws an exception.
>>>>>>> * Could you clarify your sentence "Frame-unwind-tables instead of setjmp/longjmp based exception handling must be used in order to catch exception inside called function."
>>>>>> for instance gcc supports both strategies how exceptions are
>>>>>> modelled/propagated. calling ::longjmp() is equivalent to throw
>>>>>> statement. Functions written in C++ will have unwind information by default.
>>>>> And how this translates to the user? Do the user needs to do someting specific?
>>>> do not invoke a compiler argument which enables sj/lj-exception model
>>> This is clear :) Sorry, I ignored this. Could the library prevents the users if this is not the case?
>> It depends on the used compiler and I believe it is not worth the
>> trouble - a warning in the docu should be enough
> I think everything that can be reported to the user clearly is worth the effort. Note that otherwise you could have a lot of users asking you why this doesn't works, and you saying: "There is a warining on the documentation.". If you can you must.
I don't believe you will get an information how the compiler has
implemented the exception model.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk