public inbox for c++-embedded@sourceware.org
 help / color / mirror / Atom feed
* FW: Undeliverable Internet Mail, no local user(s) defined
@ 1998-08-29  7:17 P.J. Plauger
  0 siblings, 0 replies; only message in thread
From: P.J. Plauger @ 1998-08-29  7:17 UTC (permalink / raw)
  To: c++-embedded

From: "Michael Bruck" <mbruck@rft.de>
Subject: Re: iostreams (was template bloat)
Date: Sat, 29 Aug 1998 04:09:01 +0200

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

[pjp]  Well, it's a damned good start if your reason for not using C++ is that
the libraries add too much bloat. From your comments, you apparently
missed out on the extensive discussion of the whys and wherefores of EC++
that took place over the summer on comp.std.c++. It educated a lot of people
who had heard, or settled on, over simplifications about EC++.


                                                                                        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.

[pjp]  The EC++ library avoids the use of templates, to be sure. This can
result in small savings here and there, where the library writer can use
char-specific functions (for example) instead of more generic templatized
solutions. The real savings, however, comes from not having to load lots
of wide-character and I18N machinery dragged in by even the simplest
uses of iostreams. Some people argued on comp.std.c++ that compilers
and linkers can one day be made smart enough to eliminate many, or
perhaps all, of these overheads. But there was a tacit admission that
with today's technology, they are indeed often unavoidable -- at least
without formally subsetting the requirements, as in EC++.

The choice not to require templates in EC++ is not the Prussian Rule
(if it's not mandatory, it's forbidden). We at Dinkumware offer both an EC++
library and what we call the Dinkum Abridged Library -- EC++ with STL
floated atop it. With the latter library, you get templates in your code
only if you explicitly call for them. Whether that leads to bloat or code
efficiency is up to you. The basic promise of EC++ remains, however --
you don't get unavoidable, secret bloat that you probably will never
need in an embedded application to begin with.

                                                                                            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.

[pjp]  Again, it is not ``removed,'' it is simply not required. The EC++ spec
is designed to serve a variety of pragmatic and very immediate needs. One
of them is to define a common dialect that can be implemented by many
vendors with today's C++ compiler technology. Shops that *choose* to
code to this subset are assured of a wider choice of compilers today, and
hence greater code portability, *if that is important to a given project.*

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.

[pjp]  Bet you didn't know that a fully conforming Standard C++ Library defines
*four* wide-stream objects in <iostream>, along with the four better-known
char-based stream objects. And given the bizarre initialization requirements
for these eight objects, it's rather difficult to eliminate all code for these objects
*even if they're not used in the program.* That's one way in which the mere
presence of a feature in a specification can quietly cost you even when you
make no specific use of the feature.

More to the point, this is another case of EC++ not *requiring* a feature. It
is not banned from embedded programming in C++.

                                                                   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)

[pjp]  The Japanese were supporting large character sets for many years
before wide characters were added to the C Standard. Europeans were
writing culture-aware code for many years before locales were added. I was
an active participant in helping add both these features to C89. I was also
one of the first people to fully implement them in a commercial library.
When Amendment 1 added even more wide-character support, I was equally
helpful in writing the standardese and a working commercial implementation.
So I am well qualified to say that all this machinery is neither necessary nor
sufficient for writing network-aware or international code.

It is significant that many of the Japanese experts who pushed for wchar_t
in C89, and for even more such machinery in Amendment 1, are on the
Embedded C++ Technical Committee. They recognize that support at
the language level for locales and large character sets is rather less useful
than many people think. And the costs are higher than many people
think.

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.

[pjp]  Go ahead. I wouldn't stop you if I could. Who do you think is trying
to do so?

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

[pjp]  Yes, we have *all* these options in our libraries. Some we preconfigure
before we ship, some we leave in for the customer to play with. What you
may not realize is that each combination of options constitutes a different
implementation. It must be tested for coherence and correctness, and
adequately documented. We supply only those combinations that we know
to be safe to use. One such combination is called the Dinkum EC++
Library. And even with that library, we let the customer choose whether or
not to use exception handling in the library.

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

[pjp]  We have optional exception handling in our full Standard C++ Library.
Same caveats as above. If you don't use iostreams at all, they cost you
nothing at runtime. The version with efficient iostreams we call the EC++
Library.

                                     The user should also be able to approximate
the (memory) costs of a particular feature.

[pjp]  Indeed. But most users must depend on the speculations of the
experts, because there are next to no meaningful benchmarks in this
important area. Dinkumware has a very active benchmarking project to
address this need. We will be making more and more information
available to our customers in the coming months.

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.

[pjp]  A cheap shot. It is not possible to implement C properly for the 8051,
so this remark is hyperbole at best.

The authors didn't know that there is a difference between bloat and
overhead.

[pjp]  How the hell do you know what the authors know and don't know?
Please confine your remarks to provable facts and lay off making unfounded
personal remarks about people whom you haven't even met.

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

[pjp]  Another cheap shot. I see no attempt on the part of the Embedded
C++ Technical Committee to ``remove everything that causes overhead.''

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com/hot_news.html





^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~1998-08-29  7:17 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-08-29  7:17 FW: Undeliverable Internet Mail, no local user(s) defined P.J. Plauger

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