Whatever happened to -fembedded-cxx?

[Mike Stump]

> Date: Wed, 22 Mar 2000 14:20:28 -0800
> From: Stan Shebs <shebs@apple.com>

> At one point, it seems that Cygnus GCC or egcs or both had a flag
> -fembedded-cxx that complained about C++ constructs that are not
> part of the Embedded C++ subset.  However, it doesn't seem to be
> available in current sources.  What's the story?

> (In case anybody is wondering why EC++ has reared its ugly head
> again, Apple is specifying EC++ for its I/O driver kit for OS X.
> And no, I wasn't around to influence that decision, but I will be
> happy to take any relevant data/opinions and pass them along, hint
> hint.)

I have never seen much of a need for Embedded C++.  It was always more
of a politic thing that a few people in the world (a group of isolated
programmers from an small isolated country on a small chain of
islands) thought was necessary for some reason, and they had some
bucks to spend to get a few vendors to cater to them.  They tried to
drum up support for it.  Luckily (or not), they picked a reall good
name, and got some press.

Sorry to hear Apple bought into it.  Some of the concepts that had are
right, but we don't need a marketing name for it.  -fno-excetions is
fine, and works for peolpe that want to use it.  -fno-rtti, ditto.
g++ has always had those options, and will have them for a long time
to come.  So in essence, g++ has supported and not needed Embedded C++
since before the term was born.

Hint g++ mostly supports Embedded C++ already in it's current form,
with a few extra features thrown in.  For example, they didn't spec
templates, because when they started specing, templates were new and
the compilers they had didn't necessarily all support them well and to
the same extent.  The 1990s are over.  We can add templates as a
feature to Embedded C++ just because it makes sense to.  It is like
adding long long support.  It just makes sense.  Same with namespaces.
Some of the other portions are just optimizations that we could do, if
people found that the optimization was important enough to them (no
MI).  But just maybe, newer ABIs and newer codegen strategies will
render these minor optimizations not worth it.  I feel we don't need
to carve these in hard stone, rather let us (the compiler developers)
respond to real needs or real people by offering whatever people want
(-fsljl-exceptions v -fnew-abi v -fno-excetions -v
-fnosjlj-exceptions for example).

Anyway, this is just my view of the world, and other people will
definitely have other views.  A well rounded view will also take into
consideration other views, and decide for themselves.

For an I/O driver kit for an operating system, far more important, is
the ABI people can write to, file formats, data layout, runtime
environment and so on.  I mean, if a person can code it in Pascal, and
meet the ABI requirement, why not let them code in Pascal.  Or real
C++ for that matter.