cpp-netlib-devel

[cpp-netlib-devel] BOOST_NO_EXCEPTIONS (and -fno-exceptions)

[Hochhaus, A. <aho...@sa...>]

Hello,

As cpp-netlib is being written for potential future inclusion in boost
it might be worth allowing complication without exceptions when
BOOST_NO_EXCEPTIONS is specified. That way projects which disallow
exceptions can compile with -fno-exceptions. Looking at the cpp-netlib
code it seems that very few sites utilize exceptions so it would
likely be a minimally invasive patch.

Thanks for consideration,
Andy

Re: [cpp-netlib-devel] BOOST_NO_EXCEPTIONS (and -fno-exceptions)

[Dean M. B. <mik...@gm...>]

On Mon, Mar 14, 2011 at 4:17 AM, Hochhaus, Andrew
<aho...@sa...> wrote:
> Hello,
>
> As cpp-netlib is being written for potential future inclusion in boost
> it might be worth allowing complication without exceptions when
> BOOST_NO_EXCEPTIONS is specified. That way projects which disallow
> exceptions can compile with -fno-exceptions. Looking at the cpp-netlib
> code it seems that very few sites utilize exceptions so it would
> likely be a minimally invasive patch.
>

Thanks for the suggestion Andy. I remember having to look for bare
calls to 'throw' and replacing them with BOOST_THROW -- with the
intention that BOOST_NO_EXCEPTIONS would require users to provide
their own exception handler function. I hoped that these would be
sufficient, although I'm not sure whether you're looking for anything
more specific with regards to BOOST_NO_EXCEPTIONS.

HTH

-- 
Dean Michael Berris
http://about.me/deanberris

Re: [cpp-netlib-devel] BOOST_NO_EXCEPTIONS (and -fno-exceptions)

[Hochhaus, A. <aho...@sa...>]

Hi Dean,

Thanks!

On Sun, Mar 13, 2011 at 7:17 PM, Dean Michael Berris
<mik...@gm...> wrote:
> I remember having to look for bare
> calls to 'throw' and replacing them with BOOST_THROW -- with the
> intention that BOOST_NO_EXCEPTIONS would require users to provide
> their own exception handler function.

Right. As you say, my understanding is that replacing the "bare throw"
calls with boost::throw_exception() allows for a user supplied
alternative definition in the event that BOOST_NO_EXCEPTIONS is
supplied.

http://www.boost.org/doc/libs/1_46_1/libs/exception/doc/throw_exception.html

> I hoped that these would be
> sufficient, although I'm not sure whether you're looking for anything
> more specific with regards to BOOST_NO_EXCEPTIONS.

The only other thing that I can think of is to "#ifndef
BOOST_NO_EXCEPTIONS" comment out all "try {" clauses and "} catch  {
... }" blocks in cpp-netlib. This should be a safe assumption as the
user supplied throw_exception is never allowed to return (so no need
to handle error conditions).

An example of commenting out the "try ... catch" stuff can be seen in
this patch to the thread library.

https://svn.boost.org/trac/boost/attachment/ticket/2100/boost_thread_BOOST_NO_EXCEPTIONS_20110306.diff

With those two changes, I believe that compilation should succeed with
-fno-exceptions.

Thanks for your work on this amazing library.
-Andy

Re: [cpp-netlib-devel] BOOST_NO_EXCEPTIONS (and -fno-exceptions)

[Hochhaus, A. <aho...@sa...>]

Hi Dean,

On Mon, Mar 14, 2011 at 12:13 AM, Dean Michael Berris
<mik...@gm...> wrote:
>> On Sun, Mar 13, 2011 at 7:17 PM, Dean Michael Berris
>> <mik...@gm...> wrote:
>> The only other thing that I can think of is to "#ifndef
>> BOOST_NO_EXCEPTIONS" comment out all "try {" clauses and "} catch  {
>> ... }" blocks in cpp-netlib. This should be a safe assumption as the
>> user supplied throw_exception is never allowed to return (so no need
>> to handle error conditions).
>>
>> An example of commenting out the "try ... catch" stuff can be seen in
>> this patch to the thread library.
>>
>> https://svn.boost.org/trac/boost/attachment/ticket/2100/boost_thread_BOOST_NO_EXCEPTIONS_20110306.diff
>>
>> With those two changes, I believe that compilation should succeed with
>> -fno-exceptions.
>>
>
> Interesting. I think I need to think about that a little. There are a
> few places where the exception mechanism is relied upon to convey
> information to the user of the library -- like when an HTTP GET
> actually fails, etc. I think it ought to be able to design interfaces
> that take an lvalue reference to an optional error, or maybe just a
> boost::system::error_code (maybe it's time that I implement a
> boost::network::error_code that plays well with Boost.System much like
> how Boost.Asio has the same).
>
> It might not be as simple as that too as with the asynchonous client
> implementation relies on portable Boost.Exception types that are
> encapsulated in Boost.Thread futures.

I just learned about BOOST_{TRY,CATCH,CATCH_END,RETHREOW} from:

third-party/boost/boost/detail/no_exceptions_support.hpp

I think using these (combined with BOOST_THROW_EXCEPTION) is
preferable to #ifndef BOOST_NO_EXCEPTIONS guarding that I previously
suggested. Just thought I would mention them as they may be helpful.

Thanks,
-Andy

Re: [cpp-netlib-devel] BOOST_NO_EXCEPTIONS (and -fno-exceptions)

[Dean M. B. <mik...@gm...>]

On Thu, Mar 31, 2011 at 6:11 AM, Hochhaus, Andrew
<aho...@sa...> wrote:
> Hi Dean,
>
> On Mon, Mar 14, 2011 at 12:13 AM, Dean Michael Berris
> <mik...@gm...> wrote:
>>> On Sun, Mar 13, 2011 at 7:17 PM, Dean Michael Berris
>>> <mik...@gm...> wrote:
>>> The only other thing that I can think of is to "#ifndef
>>> BOOST_NO_EXCEPTIONS" comment out all "try {" clauses and "} catch  {
>>> ... }" blocks in cpp-netlib. This should be a safe assumption as the
>>> user supplied throw_exception is never allowed to return (so no need
>>> to handle error conditions).
>>>
>>> An example of commenting out the "try ... catch" stuff can be seen in
>>> this patch to the thread library.
>>>
>>> https://svn.boost.org/trac/boost/attachment/ticket/2100/boost_thread_BOOST_NO_EXCEPTIONS_20110306.diff
>>>
>>> With those two changes, I believe that compilation should succeed with
>>> -fno-exceptions.
>>>
>>
>> Interesting. I think I need to think about that a little. There are a
>> few places where the exception mechanism is relied upon to convey
>> information to the user of the library -- like when an HTTP GET
>> actually fails, etc. I think it ought to be able to design interfaces
>> that take an lvalue reference to an optional error, or maybe just a
>> boost::system::error_code (maybe it's time that I implement a
>> boost::network::error_code that plays well with Boost.System much like
>> how Boost.Asio has the same).
>>
>> It might not be as simple as that too as with the asynchonous client
>> implementation relies on portable Boost.Exception types that are
>> encapsulated in Boost.Thread futures.
>
> I just learned about BOOST_{TRY,CATCH,CATCH_END,RETHREOW} from:
>
> third-party/boost/boost/detail/no_exceptions_support.hpp
>
> I think using these (combined with BOOST_THROW_EXCEPTION) is
> preferable to #ifndef BOOST_NO_EXCEPTIONS guarding that I previously
> suggested. Just thought I would mention them as they may be helpful.
>

Cool!

If you can give me a pull request that would allow me to integrate
your changes in the library that would be *awesome*.

Thanks Andy!

-- 
Dean Michael Berris
http://about.me/deanberris