Boost logo

Boost :

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-02-16 12:10:35


Andy Little(e)k dio:
> "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.

I can only talk about my experience in railway embedded systems, where
we use QNX multi-process operating system. Exceptions are disabled to
save space and increase error-reporting speed to prevent as quickly as
possible important failures in control systems. The systems has multiple
processes, (one alarm detector, one log server, one communication proxy,
one monitorization process...) that share a common shared memory
data-base. The most important thing is that multi-processing allows
memory-protection, so that if the monitorization process crashes, it
can't make crash other processes with some memory overflow issue and it
can be restarted and it will start working again. It could be possible
to make all processes threads of just one big process but this way, you
can't protect important processes from crashes of other less critical
processes. Separate processes also allow easier development, in my opinion.

> 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?

See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcstdlib/html/vclrf_new_Nothrow.asp

> 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.

The problem is not emulation but reusing that code in another
environment that uses exceptions, since the reused code won't work anymore.

Anyway, I will repeat it here again: I accept RAII only for Shmem.

Regards,

Ion


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