Subject: Re: [boost] [modularization] Dependency to Boost.Exceptionunavoidable?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-11-04 14:25:12
On 3 Nov 2013 at 9:08, Robert Ramey wrote:
> I don't think it's a great idea for a library author to make the
> requirements for using his library more stringent than is absolutely
I generally agree. With the exception of features specified to be
part of the C++ language standard. Those any C++ codebase has the
right to assume are always available.
> The way BOOST_EXCEPTION used to be was correct - Implemented as a throw if
> the platform supported it, and calling some defined function if the
> platform doesn't support them. This actually works well when exceptions
> are not used as part of the code logic but only to handle "error
> conditions". This practice is generally recommended and many follow it.
> In this context, there's not reason not couple one's library to the
> existence of RTTI or an related compiler feature.
I think my personal difficulty here is that lack of RTTI can be
worked around (e.g. Boost.TypeIndex), whereas presence or lack of
exceptions means completely different design of a C++ codebase, with
a non-exception safe design being utterly and more importantly
permanently defective when used in the presence of exceptions - a
rather important distinction.
I can certainly see that by ruling out exception safety during design
that one can get code to market quicker - assuming that one does not
save significant implementation time by making use of libraries which
assume exceptions work (e.g. the C++11 STL), because as soon as you
mix in exception assuming code with non-exception capable code you
have interop problems.
> "it was/is an interesting choice by a large, modern, non-embedded C++
> use case."
> I think that boost should provide more support for embedded systems - not
I agree in the sense that hard realtime use cases for Boost where
there is guaranteed worst case execution times is incredibly
important, and indeed for those cases where Boost.TypeIndex can
replace RTTI it will eliminate RTTI's unbounded execution times. That
makes exception throwing the only unbounded worst case execution time
There is nothing about an embedded system that implies exceptions
ought to be disabled though, especially with any semi-recent compiler
and that your codebase isn't regularly throwing exceptions while it
runs. You do tend to lose a register and use more stack space in code
generation, but a reasonably modern bottom end embedded CPU is fairly
tolerant of that nowadays thanks to having at least a L1 cache which
hides a lot of the consequences of extra but unused stack usage. It's
not like on 6502 with its three registers incapable of even burst
read/writes to RAM for sure, or even an ARM v2 where stack writes
across RAM page line boundaries stalled the CPU.
-- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/