Boost logo

Boost :

From: Dietmar Kuehl (dietmar_kuehl_at_[hidden])
Date: 2001-08-29 08:25:29

John Maddock (John_Maddock_at_[hidden]) wrote:
> Up until now, I have had the impression that boost wasn't interested
> supporting platforms/compilers with no exception handling support,
> I've had a couple of queries from regex users about building on WinCE

> (where I am led to understand that the compiler has no exception

At the Sophia-Antipolis meeting, coincidentally the meeting where the
idea of took its form and enough momentum to be started,
something called "Embedded C++" (EC++) created by a mostly Japanese
group was presented. The goal of this presentation to was provide
something similar to C++ tailored for the need of embedded systems and
give it the blessing of the C++ standardization committee.

Basically EC++ is C++ with a bunch of features omitted. Notably, the
following parts of C++ were removed because they supposedly create

- namespaces
- templates
- exceptions
- I think that a bunch of less gross features was also removed like eg.
  multiple inheritance

Since these features are present basically everywhere in the standard,
lots of parts of the C++ standard were adapted to make up for the use
of these features. In particular, the whole standard C++ library was
change such that these features are not used anymore. Of course, the
EC++ standard library does not have something like STL and other
templates were turned into non-templates (eg. the streams). For more
information on EC++ see <> (and
the links mentioned there).

The proposal was kindly but decidedly turned down: C++ with the
restrictions of EC++ is no C++ anymore. It was generally agreed that a
subset of C++ obtained by removing features is a bad idea (of course,
the usual suspects did not agree with this view...). However, since the
efficiency considerations of the people who defined EC++ are reasonable
a group dealing with efficiency considerations and embedded systems
concerns was founded in the C++ standardization committee, the so
called Performance Group (BTW, ideas how to efficiently implement the
standard C++ library are topic of this work, too: people here might
have experience and/or ideas how to improve the standard C++ library

In general, my feeling is that restricted C++ is not C++ and I'm
reluctant to do work to support inferior systems. Of course, serveral
C++ compiler support even the EC++ stuff by having a switch which
restricts them to EC++ (the EDG front-end based stuff and gcc fall into
this category) but I still think that supporting broken platforms gives
them some form of blessing which actually might find its way back into
the standard by means of the following argument: It is common practise
not to use feature X (see eg. platform <something severely broken>) and
this should correspondingly considered by the standard! That is,
mandatory features might become optional.

> The main problem of course, is what does one do if the lib would
> throw an exception, but exceptions aren't available? In some cases
> assert might be appropriate, but that's not universally true.

It would be possible to make the handling of exceptions configurable at
compile time. For example:

  template <typename Ex> void throw_ex(Ex const& ex) {
    std::cerr << ex.what() << "\n";
    assert("an exeption was thrown" == 0);
  template <typename Ex> void throw_ex(Ex const& ex) {
    throw ex;

... or something similar.

<mailto:dietmar_kuehl_at_[hidden]> <>
Phaidros eaSE - Easy Software Engineering: <>
Do You Yahoo!?
Gesendet von Yahoo! Mail -

Boost list run by bdawes at, gregod at, cpdaniel at, john at