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/