Re: mobile/embedded boost

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

Hi,
John Maddock (John_Maddock_at_[hidden]) wrote:
> Up until now, I have had the impression that boost wasn't interested
in 
> supporting platforms/compilers with no exception handling support,
however 
> 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
support). 

At the Sophia-Antipolis meeting, coincidentally the meeting where the
idea of Boost.org 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
inefficiencies:

- namespaces
- templates
- exceptions
- RTTI
- 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 <http://www.ghs.com/ec++article.htmla> (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
performance...).

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
normally 
> throw an exception, but exceptions aren't available?  In some cases
an 
> 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:

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

... or something similar.
--
<mailto:dietmar_kuehl_at_[hidden]> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>
=====
<mailto:dietmar_kuehl_at_[hidden]>
<http://www.dietmar-kuehl.de/>
__________________________________________________________________
Do You Yahoo!?
Gesendet von Yahoo! Mail - http://mail.yahoo.de