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

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

Yes
>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++.
>


From what I remember most parts of the Standard C++ library are
templates. This makes it possible for the compiler to apply extensive
optimizations. The bloat is added when you use some kind of
precompiled library. This is not necessary as long as you have
all the code in the headers.

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

Template specializations will do the same.


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


Many compilers still don't implement the whole C++ standard. But
nobody decided to remove these elements from the standard. Your
argumentation ("today's technology") sounds as if there are some
fantastic algorithms necessary that mankind will not discover before
2030 to prevent compilers from producing template bloat. I must
admit that I don't write compilers in my spare time but I think there
are solutions available (today) to reduce that bloat.

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

This is cool, but we are speaking about the standard, not how to get
around it.

>you don't get unavoidable, secret bloat that you probably will never
>need in an embedded application to begin with.

I already made a suggestion about this. We probably agree
on the point that the user should decide what he wants. But it
should be the subject of the standard how the user can do this in
a portable manner not only on Dinkumware's products. That's what
standards are for.

>[pjp]  Again, it is not ``removed,'' it is simply not required. The EC++
spec

Then this should be stated in the rationale text. I was speaking about
the argumentation from that text and I insist on what I said.

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

This goal can be archived by not using *some* features that are not yet
available on all compilers. This has nothing to do with reducing the
language in the way that EC++ does.

>
>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's the *user* who want's the features. You are probably right that he
may write the same program without using these features. He can even
use assembly language for this. But one uses C++ because it speeds
up programming (by using expensive features).

>is not banned from embedded programming in C++.


Yes but it's banned from embedded programming in EC++.

>
>                                                                   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.
>
Unfortunately I've not yet seen very much software with proper
internationalization except from MS. I also have never seen a japanese
TV set that could be easily switched from japanese to russian or
arabic OSD. Just because Japanese always causes problems on
computers that does not mean that Japanese programmers are
more aware to i18n problems than Americans. They use their own
specialized and non-portable solutions to address the problem.


But probably the people who have put Unicode into Java are wrong too.



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


From the rationale:
: ...
: For these reasons, the technical committee decided not to include
: exception handling in the Embedded C++ subset specifications.

You are again telling me not to use EC++?

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

Defining a standard that assures this coherence and correctness would
help the embedded C++ user not only the Dinkumware customer.

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


Defining a standard way to select these features would be to the benefit
of every embedded C++ programmer not only of Dinkumwares customers.

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


Not that I even considered that anybody would try to use C++ for 8051's, but
the 8051'c C implementations (f.e. Keil C) are much closer to ANSI C than
EC++ is to C++.

Maybe the sentence should read:
But the standard sounds as if it has been designed with the limitations
of stone age 8051 technology in mind.


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


My apologies.
English is not my native language, sometimes it may sound in a way that it
was not intended. Please note that I never make personal remarks about
people that I don't know personally. It is your problem if you take single
sentences and remove them from their context just start this kind of
conversation.

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


Please read http://www.caravan.net/ec2plus/amendment2.html . There is
hardly any sentence that doesn't contain the word "delete".


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


Micha




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

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

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-08-29 15:45 Undeliverable Internet Mail, no local user(s) defined Michael Bruck

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