Re: [boost] [modularization] Dependency to Boost.Exceptionunavoidable?

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

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

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

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.

Niall

-- 
Currently unemployed and looking for work.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/