Boost logo

Boost :

From: Andy Little (andy_at_[hidden])
Date: 2006-02-16 08:09:59


"Fred Bertsch" wrote
>> > 4. For embedded environments that cannot use exceptions, I suggest using
>> > boost::config to disable the throwing() behavior, and provide an
>> > "isValid/isOpen" accessor function which would allow embedded developers to
>> > interrogate the state of the object. When exceptions are turned on, this
>> > function would always return true.
>>
>> The only problem I see to this behavior in my experience is that many
>> times you develop a class for an embedded environment without exceptions
>> (because of limitations) and you want to also test it in PC platforms or
>> reuse use that code in another project and environment that do use
>> exceptions.

It might be useful to specify some use cases where you are running in an
embedded environment with separate processes that need shmem and you have no
exceptions, and if no-exceptions is policy or forced by compiler. Its just that
that seems to be quite a narrow set. Some use cases would help.

Since the code has not exception support (you don't program
>> with exceptions AND error returns) you want the code to continue working
>> in the new environment when the exceptions are thrown.
>>
>> That's why I would prefer overloading the constructors with an
>> additional std::nothrow parameter for no-exception environments to
>> disable exception and use is_valid() approach instead of defining a
>> macro.

Sorry for being dim. Whats a std::nothrow parameter?

>> This code would still work in new environments when the code is
>> used somewhere else where exceptions are enabled.
>>
>> After the long debate about RAII I don't know if this solution would be
>> accepted by boost members or only compile-time configuration is accepted.
>
> This issue seems to be the only controversial point so far in this
> review. :) I'd like to elicit some feedback on this so that I can
> close up the review as quickly as possible after it ends tomorrow.
>
> Ion is proposing a solution that solves many of the problems with a
> two stage construction process. It is still possible to use the
> constructors with std::no_throw and get an invalid state. I shouldn't
> comment on the no-exceptions, embedded world that Ion is hoping to
> placate with his strategy, but in the world where exceptions are
> possible, it should be easy to tell that you're tripping over
> something nasty when you pass std::no_throw into a constructor. It
> seems to me that this should be good enough even if it's not ideal.
>
> Because the topic generated some controversy, I'm hoping to get a few
> people who complained about the two stage construction to comment on
> the proposed solution before the review ends.

First I agree with Dave Abrahams most recent comments.

 IMO The only way that the choice would be acceptable is by having firstly RAII
behaviour and then optionally having no-throw behaviour but no exception
throwing behaviour (which seems logical as you would only use this if you dont
have exceptions anyway) enabled by a macro. This does seem to cater for the
emulator case. You just emulate the nothrow behaviour by defining said macro for
testing.

regards
Andy Little


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk