public inbox for
 help / color / mirror / Atom feed
From: "Michael Bruck" <>
To: <>
Subject: Re: iostreams (was template bloat)
Date: Fri, 28 Aug 1998 19:08:00 -0000	[thread overview]
Message-ID: <000d01bdd2f1$fe0da3e0$> (raw)

>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
>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 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

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
> Therefore, the technical committee decided not to include libraries for
> 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
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

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

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
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 ...  :).


             reply	other threads:[~1998-08-28 19:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-08-28 19:08 Michael Bruck [this message]
  -- strict thread matches above, loose matches on Subject: below --
1998-08-28  5:55 P.J. Plauger
1998-08-27 20:59 Kenneth Porter
1998-08-27 16:40 Kenneth Porter
1998-08-27 17:36 ` Chris Johns

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000d01bdd2f1$fe0da3e0$' \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).