public inbox for c++-embedded@sourceware.org
 help / color / mirror / Atom feed
* Re: EC++
@ 1998-09-01  9:00 P.J. Plauger
  0 siblings, 0 replies; 3+ messages in thread
From: P.J. Plauger @ 1998-09-01  9:00 UTC (permalink / raw)
  To: c++-embedded

From: "Michael Bruck" <mbruck@rft.de>
Subject: Re: EC++
Date: Mon, 31 Aug 1998 21:35:46 +0200

With standard was EC++ meant not C++. You were speaking about
the ways how Dinkumware makes it possible to get around EC++.

[pjp]  There's nothing to ``get around,'' as I keep repeating. EC++
provides a specification for a library and a minimum language subset.
It does not *forbid* anybody extending either, any more than the C++
Standard forbids extensions. But the library was carefully specified
so as to keep a small footprint -- dramatically smaller than for full
C++ by many measurements. And the minimum language subset
was carefully specified to maximize portability among existing
implementations of C++. You can extend either, with the obvious
potential risk of making a larger footprint or having reduced portability
if you're injudicious.

The problem is that the EC++ standard defines what is unacceptable
and what isn't. It should be the users decision what overhead he can
accept (means what is acceptable for his application).

[pjp]  Well, yes, modulo the available implementations. What we're
discussing is the available implementations and the tradeoffs among
them.

                                                                      The fact that
the committee spent a year disscussing this issue indicates to me
that there were different opinions what is the proper subset. At
some point the committee decided that from it's point of view
f.e. there are more contras then pros for templates. But how can
you expect that when all these experts had different opinions which
feature one may need and which not the compromise that has been
archieved would match the needs of the end-user if you don't know
his exact requirements. Maybe in his eyes and probably in the eyes
of some committee members there were more pros for templates.

[pjp]  FWIW, I don't recall *any* support for including templates, in
any of the technical discussions to which I was privy. But I think
you're missing an important point. Designing a usable programming
language is very hard, and even designing a coherent subset of a
language of proven utility is hard enough in its own right. As I keep
emphasizing, this is not a bushel basket of unrelated binary decisions.
They play together and interact in surprising ways. I'm surprised that
the committee hammered out a design that hangs together in *only*
a year.

It would be enough if the standard defines that there should be a
possibility to disable these features. This would include a
specification how the compiler behaves in this situation. (E.g. what
he does when exceptions are disabled and he finds a try block).
This would also include special requirements for the
Standard Embedded C++ library how it has to be written to
handle the absence of these features.

[pjp]  Fine, but nobody did that.

The question whether the data is ROMmable or not is in my eyes a very
important point for an embedded C++ standard. Of course this is
more a language issue than a library issue. I just couldn't understand
why the decision was to remove that keyword, when the goal that
they wanted to archieve by removing it(ROMable objects) was not
met. Maybe I am wrong about whether the goal has been met or
not. Thats why my question: Is it possible with EC++ to put objects
of inherited classes or classes with constructors into ROM?

[pjp]  AFAIK, yes. ROMability is a predicate that can be determined
with or without the presence of the mutable keyword. As I recall, the
matter was discussed at some length during development of the EC++
spec.

"essential to embedded programming" is not a very clear definition. This
always depends on the requirements of the user. For some people
C or C++ is not essential to embedded programming (infact I know
people who are even writing ColdFire code in assembler -- this
would be a typical target for EC++). Noting in C++ makes it essential
for embedded programming. It's only for convienience. I can only
repeat what I said earlier: People are (or at least I am) using
C++ to make programs easier to write/understand and faster
to write. This is the only reason to use C++. Removing a feature
because (in your opinion) it's not essential for embedded
programming doesn't make it more likely that someone decides
to use EC++ instead of C or C++ because you only decrease the
advantages of C++. The user will notice that it's not essential to
fast/portable/bug-free programming to use EC++ because these
qualities/features were in your eyes not essential enough to
embedded programming.

[pjp]  Some people will choose not to program in EC++ for this or other
reasons, to be sure. The question is, does EC++ meet the needs of a
significant number of programmers, particularly embedded programmers?
The answer appears to be yes, however much you and others second
guess the decisions that went into its specification.

You are saying yourself that people want a range of libraries from
fully conforming to fully EC++ compliant. This is what should be the
subject of an embedded C++ standard.

[pjp]  Fine, but nobody did that.

                                                     You will find many people
who don't want the full C++ library for embedded programming and
who can't live with the pieces that are left in the EC++ library. They need
something in between. But the "something in between" is not portable
anymore because nobody cared to write a standard about this.

[pjp]  Portability is not a boolean attribute. Rather, it is a statement about
the relative cost of moving a program vs. rewriting it. If you choose a set
of ``extensions'' to the minimum EC++ language specification that are not
widely available, you reduce portability, to be sure. But you don't destroy
the reason for sticking largely with the EC++ spec in writing the code. As
an analogy, consider the great mass of C code that's ostensibly written
in Standard C but which contains implicit presumptions that bytes are
eight bits and ints are four bytes. That mass is theoretically not portable,
but in practice it finds itself at home on most modern computers.

>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.
>
>[pjp]  Well I have seen television sets that speak Japanese plus
>several western languages. (Didn't look for Arabic.) And I have ample

This is why I wrote russian and arabic. Latin characters are for
beginners.

[pjp]  That comes across as condescending to me. I'm pretty impressed
that the typical Tokyo hotel TV set is prepared to display characters as
diverse as Kanji and Romanji in several flavors.

>evidence that Americans are *least* aware of I18N issues, because
>we can code for our huge local market and let the rest of the world
>meet us more than halfway -- at least until fairly recently. The

I know this. I removed the sentence about the American attitude
to this problem that I wanted to write, because I didn't want
to have to apologize again.

[pjp]  Well, you might consider apologizing for your slight to the Japanese
above. (It's easier for me to slight my fellow Americans, because self
deprecation takes the edge off.) You might be interested to know that the
paragraph above was quoted in its entiredy on the EC++ Technical
Committee reflector yesterday. I don't know Japanese, so I don't know
what they said about it. I leave it to you to guess, since that's *all* they
quoted from this ongoing exchange (at least in English).

>Japanese are, in fact, major contributors to I18N programming
>standards. My point was that they have learned the limitations of
>putting I18N support in programming languages, which is why they
>are willing to leave it out of EC++ (and rely on specialized and
>non-portable solutions, as needed).

And that's why you won't get this arabic OSD in a Japanase TV.

[pjp]  Because EC++ doesn't support Arabic? Wow. You credit locale
support in C++ with *much* more power than I do.

I would add non-extensible to non-portable in your sentence above
although this is only a guess because I haven't seen their code,
but I also haven't seen this TV too.

[pjp]  It sounds to me like you're being condescending again.

>You are again telling me not to use EC++?
>
>[pjp]  Not if you insist on using exceptions, that's right. We can still
>offer you a library that extends the EC++ library specifications by
>supporting exceptions, however.

But then my program won't be portable.

[pjp]  As before. Portability ain't a boolean.

>Defining a standard that assures this coherence and correctness would
>help the embedded C++ user not only the Dinkumware customer.
>
>[pjp]  Fine. But nobody did that.

That's the problem. This means everybody who can't live with the EC++
subset (and they seem to exist, or you couldn't sell your libraries)
has to use proprietary technology. This is equal to having no standard at
all.

[pjp]  More boolean statements. The issues are *not* black and white.

       This also limits competition. Once written with XY's library a program
can't be easily compiled with AB's library. For some companies this
reason alone would forbid the usage of such a library.

[pjp]  So a company for whom portability is important will stick with the
de facto industry standard called EC++, because it's more cost effective
for them to do so than to profit from anyone's proprietary extensions.

>[pjp]  Another cheap shot. It's an arm-waving comparison that's next to
>impossible to quantify, but it certainly does not agree qualitatively with
>my experience. How does it agree with *your* experience in using EC++?

Except from recursive functions and varargs I don't miss any features
from C51. BTW: you can optionally use them, but it wastes too much
memory. And the absence of these features is a result of the system
limitations, not like in EC++ where it's a design decision ("essential
or not").

[pjp]  Matter of opinion. You can implement a (bounded) Turing machine on
an 8051, so you can implement all of C++. You just might not always like
the performance. It's a *design* decision to leave out the inefficient bits.

          You must admit that in any case the list of omissions in C51
is slightly shorter than that document that I pointed at  at the end
of my last mail.

[pjp]  Well, that's one way to quantify the comparison of apples and oranges.
I can write a short list for EC++ too. Have done so. Proves nothing either way.

>                                                  It is your problem if you
take single
>sentences and remove them from their context just start this kind of
>conversation.
>
>[pjp]  Apology compromised. I got that you didn't intend to be personal,
>but in fact you did and I called you on it. (Nothing personal toward you --
>I try to call *everybody* on such behavior, particularly on reflectors where
>such abuses abound.) Just own it.

I was in the impression that the habit to take everything personal instead
of concentrating on the topic of a text is the main reason why people
start flame-wars.

[pjp]  I agree that some people treat criticism of their ideas as criticism of
their worth as human beings, and they should not. But that's not what I
called you on. Quite the contrary, you made a statement about the people
involved themselves:

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

You did it in the *context* of describing the inadequacies you perceived in
the document they produced. In that *context*, it looks very much like you're
ascribing the inadequacies in the document to inadequacies in the authors.
That's a no-no in polite discourse, if only because people rightly and properly
take such remarks as personal attacks.

I believe you when you say you didn't intend a personal attack. I appreciate
your apology for any unintended hurt. That's where the matter should have
stopped. Instead, you tried to make it my ``problem'' by suggesting that I
took the remark out of context just to start this kind of conversation. (I took
the remark *in* context just to *stop* this kind of conversation.)

Now you're suggesting, or so it seems to me, that I am in the habit of taking
``everything personal instead of concentrating on the topic of a text'' in order
to start a flame war. I'm not. Please notice that I have confined my remarks,
as best I am able, to noting the effect of your words on me. I have *not*
attributed any pejorative motives to you. I have *not* questioned your
intelligence or your sincerity. I have *not* said anything bad about your
mother.

You say you didn't mean to be personal. Okay. Just notice that you
structured your words so that you were. Learn to be careful about such
things. It's important.

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





^ permalink raw reply	[flat|nested] 3+ messages in thread
* Re: EC++
@ 1998-08-31 12:36 Michael Bruck
  0 siblings, 0 replies; 3+ messages in thread
From: Michael Bruck @ 1998-08-31 12:36 UTC (permalink / raw)
  To: C++ Embedded

>From: "Michael Bruck" <mbruck@rft.de>
>Date: Sun, 30 Aug 1998 00:46:23 +0200
>
>>[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.
>
>[pjp]  Yes, for an equally small savings. But this is not the main problem,
>as I indicated.


I noticed that. I just wanted to point out that templates are not as evil
as the decision to ban them from EC++ may indicate. You can even
reduce the size of the resulting binaries using them.

>
>>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.
>
>[pjp]  Sorry, but I thought we were speaking about both. It is widely
>accepted by pragmatic people that the C++ Standard presents intrinsic
>problems to compiler and library implementors. If you conform exactly
>to the C++ Standard, you produce programs that many embedded
>programmers consider unacceptably large. The Embedded C++ Technical
>Committee spent a year determining a set of compromises (a subset of
>Standard C++) that has much more acceptable properties.
>

With standard was EC++ meant not C++. You were speaking about
the ways how Dinkumware makes it possible to get around EC++.

>Some people argue, as you apparently do, that implementors should
>pour all their energies into making this new invention called Standard
>C++ efficient enough to meet the needs of embedded programmers.
>Others don't want to wait, however. So we *are* talking about how to get
>around specifications that have proven to be unacceptable when put
>into practice.

The problem is that the EC++ standard defines what is unacceptable
and what isn't. It should be the users decision what overhead he can
accept (means what is acceptable for his application). The fact that
the committee spent a year disscussing this issue indicates to me
that there were different opinions what is the proper subset. At
some point the committee decided that from it's point of view
f.e. there are more contras then pros for templates. But how can
you expect that when all these experts had different opinions which
feature one may need and which not the compromise that has been
archieved would match the needs of the end-user if you don't know
his exact requirements. Maybe in his eyes and probably in the eyes
of some committee members there were more pros for templates.

>
>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]  That's what standards with *subsets* are for, but the C++
>committee chose not to define any subsets. Every C++ compiler I
>know has switches for turning off various features required by the
>C++ Standard. Each combination of switches constitutes a different
>dialect of C++. All but a very few of those dialects ``get around'' the
>C++ Standard by being nonconforming in some way. I assure you
>that the industry will not discontinue this practice merely because
>WG21 chose not to standardize the switches. In this sense, EC++
>is just another switch setting.

It would be enough if the standard defines that there should be a
possibility to disable these features. This would include a
specification how the compiler behaves in this situation. (E.g. what
he does when exceptions are disabled and he finds a try block).
This would also include special requirements for the
Standard Embedded C++ library how it has to be written to
handle the absence of these features.

>
>>[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.
>
>[pjp]  Fine. I tend to forget to make clear what has been obvious to me
>since I attended the first organizational meeting of the Embedded C++
>Technical Committee in November 1995: Opinions may vary considerably
>about what constitutes a proper *language* subset. But it is the efficiency
>of the *library* subset that makes or breaks EC++ as a practical
>compromise, particularly for embedded programmers. So I focus on
>library issues and gloss over disputes about language dialects.
>
The question whether the data is ROMmable or not is in my eyes a very
important point for an embedded C++ standard. Of course this is
more a language issue than a library issue. I just couldn't understand
why the decision was to remove that keyword, when the goal that
they wanted to archieve by removing it(ROMable objects) was not
met. Maybe I am wrong about whether the goal has been met or
not. Thats why my question: Is it possible with EC++ to put objects
of inherited classes or classes with constructors into ROM?

>The Embedded C++ Technical Committee strove for a dialect that
>recognized the current state of compiler technology in Japan. It was
>reason enough to omit a feature if a) it was not widely available in
>embedded compilers in 1996 and b) you could make a case that it
>was not essential to embedded programming. Only the (b) parts made

"essential to embedded programming" is not a very clear definition. This
always depends on the requirements of the user. For some people
C or C++ is not essential to embedded programming (infact I know
people who are even writing ColdFire code in assembler -- this
would be a typical target for EC++). Noting in C++ makes it essential
for embedded programming. It's only for convienience. I can only
repeat what I said earlier: People are (or at least I am) using
C++ to make programs easier to write/understand and faster
to write. This is the only reason to use C++. Removing a feature
because (in your opinion) it's not essential for embedded
programming doesn't make it more likely that someone decides
to use EC++ instead of C or C++ because you only decrease the
advantages of C++. The user will notice that it's not essential to
fast/portable/bug-free programming to use EC++ because these
qualities/features were in your eyes not essential enough to
embedded programming.

>That's why Dinkumware focuses on providing a range of libraries, from
>fully conforming to fully EC++ compliant. But we forget that people
>object to the EC++ specification because of the restrictions it imposes
>on the language.
>

You are saying yourself that people want a range of libraries from
fully conforming to fully EC++ compliant. This is what should be the
subject of an embedded C++ standard. You will find many people
who don't want the full C++ library for embedded programming and
who can't live with the pieces that are left in the EC++ library. They need
something in between. But the "something in between" is not portable
anymore because nobody cared to write a standard about this.

>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.
>
>[pjp]  True, so long as you can all agree on *which* features to leave out.
>And so long as somebody can supply a library that is prepared to not
>use those features.
>
>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).
>
>[pjp]  C was built religiously on the principles that if you don't use a
>feature you don't pay for it, and the actual cost of a feature is close
>to its apparent cost. C++ pays lip service to these principles, but
>violates them much more often. Standard C++ violates these principles
>even more than traditional C++. I have been talking about violations
>of these two principles, not the known, small overheads of coding in
>a higher-level language.

Me too. I was speaking about RTTI and exception handling.
About a user who doesn't care about 100K RTTI tables in it's flash.

>
>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.
>
>[pjp]  Well I have seen television sets that speak Japanese plus
>several western languages. (Didn't look for Arabic.) And I have ample

This is why I wrote russian and arabic. Latin characters are for
beginners.

>evidence that Americans are *least* aware of I18N issues, because
>we can code for our huge local market and let the rest of the world
>meet us more than halfway -- at least until fairly recently. The

I know this. I removed the sentence about the American attitude
to this problem that I wanted to write, because I didn't want
to have to apologize again.

>Japanese are, in fact, major contributors to I18N programming
>standards. My point was that they have learned the limitations of
>putting I18N support in programming languages, which is why they
>are willing to leave it out of EC++ (and rely on specialized and
>non-portable solutions, as needed).

And that's why you won't get this arabic OSD in a Japanase TV.
I would add non-extensible to non-portable in your sentence above
although this is only a guess because I haven't seen their code,
but I also haven't seen this TV too.

>
>But probably the people who have put Unicode into Java are wrong too.
>
>[pjp]  Not wrong, just limited in their vision, like all of us.
>


:)

>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++?
>
>[pjp]  Not if you insist on using exceptions, that's right. We can still
>offer you a library that extends the EC++ library specifications by
>supporting exceptions, however.


But then my program won't be portable.

>>[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.
>
>[pjp]  Fine. But nobody did that.
>

That's the problem. This means everybody who can't live with the EC++
subset (and they seem to exist, or you couldn't sell your libraries)
has to use proprietary technology. This is equal to having no standard at
all. This also limits competition. Once written with XY's library a program
can't be easily compiled with AB's library. For some companies this
reason alone would forbid the usage of such a library.

>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++.
>
>[pjp]  Another cheap shot. It's an arm-waving comparison that's next to
>impossible to quantify, but it certainly does not agree qualitatively with
>my experience. How does it agree with *your* experience in using EC++?

Except from recursive functions and varargs I don't miss any features
from C51. BTW: you can optionally use them, but it wastes too much
memory. And the absence of these features is a result of the system
limitations, not like in EC++ where it's a design decision ("essential
or not"). You must admit that in any case the list of omissions in C51
is slightly shorter than that document that I pointed at  at the end
of my last mail. I must admit that apart from the insight that EC++ is
not useable in my projects I have no experiences with it. I don't say
that somebody who want's to live with EC++'s limitations will
have bad experiences, but he can also use C or assembler
without having bad experiences. As long as he doesn't care about
the limitations.

>
>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.
>
>[pjp]  That's at least more honest. You're talking about how it sounds to
>you, not what it ``is.''

I wanted to express that I understand that supporting 8051 was not the
primary goal of the committee, but it seemed that some of it's limitations
unconsciously slipped into the standard :)

>                                                  It is your problem if you
take single
>sentences and remove them from their context just start this kind of
>conversation.
>
>[pjp]  Apology compromised. I got that you didn't intend to be personal,
>but in fact you did and I called you on it. (Nothing personal toward you --

>I try to call *everybody* on such behavior, particularly on reflectors
where
>such abuses abound.) Just own it.

I was in the impression that the habit to take everything personal instead
of concentrating on the topic of a text is the main reason why people
start flame-wars.

Micha



^ permalink raw reply	[flat|nested] 3+ messages in thread
* EC++
@ 1998-08-31  2:56 P.J. Plauger
  0 siblings, 0 replies; 3+ messages in thread
From: P.J. Plauger @ 1998-08-31  2:56 UTC (permalink / raw)
  To: c++-embedded

From: "Michael Bruck" <mbruck@rft.de>
Date: Sun, 30 Aug 1998 00:46:23 +0200

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.

[pjp]  An oversimplification. The bloat occurs because of the way components
of the library are tied together. The locale machinery, in particular, is *very*
large and often largely unused but very hard to optimize away by conventional
techniques. Much of the discussion that took place over the summer on
comp.std.c++ concerned ways to revise existing compilers and linkers to
deal with such problems.

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

[pjp]  Yes, for an equally small savings. But this is not the main problem,
as I indicated.

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.

[pjp]  Of course there are. Dinkumware has managed, for example, to
reduce the size of ``hello world'' (inserted into cout) about a factor of
four over our competition. It's still rather larger than using a traditional
iostreams library (or EC++). But quite a number of experts were unable
to solve the general problem after months of discussion without resorting
to ``fantastic algorithms'' unavailable in today's compilers and linkers.

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

[pjp]  Sorry, but I thought we were speaking about both. It is widely
accepted by pragmatic people that the C++ Standard presents intrinsic
problems to compiler and library implementors. If you conform exactly
to the C++ Standard, you produce programs that many embedded
programmers consider unacceptably large. The Embedded C++ Technical
Committee spent a year determining a set of compromises (a subset of
Standard C++) that has much more acceptable properties.

Some people argue, as you apparently do, that implementors should
pour all their energies into making this new invention called Standard
C++ efficient enough to meet the needs of embedded programmers.
Others don't want to wait, however. So we *are* talking about how to get
around specifications that have proven to be unacceptable when put
into practice.

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]  That's what standards with *subsets* are for, but the C++
committee chose not to define any subsets. Every C++ compiler I
know has switches for turning off various features required by the
C++ Standard. Each combination of switches constitutes a different
dialect of C++. All but a very few of those dialects ``get around'' the
C++ Standard by being nonconforming in some way. I assure you
that the industry will not discontinue this practice merely because
WG21 chose not to standardize the switches. In this sense, EC++
is just another switch setting.

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

[pjp]  Fine. I tend to forget to make clear what has been obvious to me
since I attended the first organizational meeting of the Embedded C++
Technical Committee in November 1995: Opinions may vary considerably
about what constitutes a proper *language* subset. But it is the efficiency
of the *library* subset that makes or breaks EC++ as a practical
compromise, particularly for embedded programmers. So I focus on
library issues and gloss over disputes about language dialects.

The Embedded C++ Technical Committee strove for a dialect that
recognized the current state of compiler technology in Japan. It was
reason enough to omit a feature if a) it was not widely available in
embedded compilers in 1996 and b) you could make a case that it
was not essential to embedded programming. Only the (b) parts made
it into their rationale. If you have access to a full implementation of C++,
however, such reasons don't hold much water. All language features are
apparently ``free'' -- except to the extent that they have hidden costs in
library bloat. So why leave any out?

That's why Dinkumware focuses on providing a range of libraries, from
fully conforming to fully EC++ compliant. But we forget that people
object to the EC++ specification because of the restrictions it imposes
on the language.

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

[pjp]  True, so long as you can all agree on *which* features to leave out.
And so long as somebody can supply a library that is prepared to not
use those features.

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

[pjp]  C was built religiously on the principles that if you don't use a
feature you don't pay for it, and the actual cost of a feature is close
to its apparent cost. C++ pays lip service to these principles, but
violates them much more often. Standard C++ violates these principles
even more than traditional C++. I have been talking about violations
of these two principles, not the known, small overheads of coding in
a higher-level language.

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.

[pjp]  Well I have seen television sets that speak Japanese plus
several western languages. (Didn't look for Arabic.) And I have ample
evidence that Americans are *least* aware of I18N issues, because
we can code for our huge local market and let the rest of the world
meet us more than halfway -- at least until fairly recently. The
Japanese are, in fact, major contributors to I18N programming
standards. My point was that they have learned the limitations of
putting I18N support in programming languages, which is why they
are willing to leave it out of EC++ (and rely on specialized and
non-portable solutions, as needed).

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

[pjp]  Not wrong, just limited in their vision, like all of us.

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

[pjp]  Not if you insist on using exceptions, that's right. We can still
offer you a library that extends the EC++ library specifications by
supporting exceptions, however.

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

[pjp]  Fine. But nobody did that.

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

[pjp]  Fine. But nobody did that.

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

[pjp]  Another cheap shot. It's an arm-waving comparison that's next to
impossible to quantify, but it certainly does not agree qualitatively with
my experience. How does it agree with *your* experience in using EC++?

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.

[pjp]  That's at least more honest. You're talking about how it sounds to
you, not what it ``is.''

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

[pjp]  Apology accepted.

                                                  It is your problem if you take single
sentences and remove them from their context just start this kind of
conversation.

[pjp]  Apology compromised. I got that you didn't intend to be personal,
but in fact you did and I called you on it. (Nothing personal toward you --
I try to call *everybody* on such behavior, particularly on reflectors where
such abuses abound.) Just own it.

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





^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~1998-09-01  9:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-09-01  9:00 EC++ P.J. Plauger
  -- strict thread matches above, loose matches on Subject: below --
1998-08-31 12:36 EC++ Michael Bruck
1998-08-31  2:56 EC++ 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).