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