Re: iostreams (was template bloat)

["Michael Bruck" <mbruck@rft.de>]

>
>How hard is it to factor iostreams so that one doesn't get more than
>one needs?
>
>[pjp]  It's much easier to factor Embedded C++, which is one of the main
>reasons for defining that subset. For the size of embedded systems
>contemplated by the EC++ Technical Committee, EC++ makes eminent
>sense:
>
>NEC Semiconductor Application Engineering Division reports
>the following typical embedded code sizes:
>
>Application      Current KB        Future KB
>
>camera           48-64                96-256
>rice cooker      16-48                64
>celluar phone   384+                768+
>printer             32-64               64-128
>television         16-48              32-96
>VCR               192-256           320+
>HDD               32-64               64-128
>


From what I've read at http://www.caravan.net/ec2plus EC++ simply removes
some features from C++.
This may be cool for people who don't know exactly what code the compiler
generates (or who don't care.) The EC++ subset guarantees that you won't
waste memory. But this is no solution to the real problem. F.e. removing
templates may save some memory but it also prevents people who know
how to use templates properly from saving memory by using them. BTW the
argumentation why the mutable keyword should be removed is senseless. As
long as a constructor may modify every member of the class you simply
can't guarantee that the contents of a "const" class are known at
compiletime.

And then this:

> 3.3 wchar_t, long double
>
> The libraries for type of wchar_t or long double are little used for the
> embedded application and have little necessity in the present
circumstances.
>
> Therefore, the technical committee decided not to include libraries for
type
> of wchar_t or long double in the Embedded C++ specification.
>
> For example, 'wstream', 'long_double_complex' are not supported.
>
> REASON:(2)

If I have no use for wchar_t then I just don't use it. But that's no reason
to remove
the feature as long as it costs no extra memory. This decision also
conflicts
with the definition of the intended targets for this standard (from the
Objectives powerpoint slides):
> Electronic equipment for home-use with network capability will be main
target.

For targeting international markets it's important to have some basic
multilingual
support. (the same applies to the locale library that is removed in this
specification)


The point is that there is no reason to prevent a programmer from using
exceptions as long as he thinks he can afford the extra memory overhead.
But he should be able to disable them. One simple measure would be to
offer some compiler-switches that disable these features (exceptions, rtti,
maybe templates ...). More important would be to implement the
Standard C++ Library in a way that allows for easy enabling or disabling
of (un)used features (f.e. #define _NO_IOSTREAM
#define _NO_EXCEPT ). The user should also be able to approximate
the (memory) costs of a particular feature.

Again from the rationale text:
> We mainly target 32-bit RISC MCU applications as embedded systems.

But the standard sounds as if it wants to address stone age 8051 technology.
The authors didn't know that there is a difference between bloat and
overhead.
C++ is about efficient programming (this may cause overhead). Unfortunately
it may easily cause bloat too. If you remove everything that causes
overhead you also prevent the bloat but you have nothing left that couldn't
been done with simple C. This is like inventing ReducedATM: Simply
don't use cells -- you save about 10% bandwith but you don't have
QoS, realtime audio/video streams ...  :).


Micha