Re: [boost] [function] function wrapping with no exception safetyguarantee

Subject: Re: [boost] [function] function wrapping with no exception safetyguarantee
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2010-10-08 12:30:04

On Fri, Oct 8, 2010 at 4:45 AM, Domagoj Saric <dsaritz_at_[hidden]> wrote:
>
> "Bryce Lelbach" <admin_at_[hidden]> wrote in message
> news:20101007224448.75308cb8_at_Pegasus...
>>
>> I think this is great, for selfish reasons. I'm currently working on a
>> project that uses the clang and LLVM API. clang and LLVM coding
>> conventions are to compile w/o exceptions and without RTTI. I'm able to
>> compile the Boost that I use (Spirit/Proto/Fusion
>> + deps mostly) without RTTI (after a minor fix to the provided Boost
>> workaround), but getting jazz to compile without exceptions is a larger
>> task. This would make it easier.
>
> Ability to turn off RTTI, specify on-empty policy which uses target functors
> instead of if-empty-then (with provided assert-on-empty, throw-on-empty and
> nop-on-empty handlers/functors), work w/o exceptions or work in an
> exception-enabled environment but only mark itself as a nothrow function, as
> well as many other improvements (reduced template bloat, compiler-specific
> optimizations, etc.) is already done (in an alpha-msvc only state):
> https://svn.boost.org/svn/boost/sandbox/function/boost/function
> http://article.gmane.org/gmane.comp.lib.boost.devel/195351
> ...
>
> Considering that interest again seems to be on the rise, maybe Doug Gregor
> will finally find the time to go through all/some of these proposals and
> that some changes will finally be made...and I might also finally finish my
> code/changes now that I've started working with GCC...

I haven't taken the time to look at your project yet either, but
thanks for reminding the list that it's available in the sandbox. I
have to say that I don't find the idea of gutting the current
implementation to be particularly attractive. Boost.Function is
already proven and familiar, and there's more we can still do with it.
Plus, it takes time to study a lot of new code.

Daniel Walker