From: Dean M. B. <mik...@gm...> - 2011-03-31 01:58:39
|
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 |