From mboxrd@z Thu Jan 1 00:00:00 1970 From: "P.J. Plauger" To: c++-embedded@cygnus.com Subject: Re: EC++ Date: Tue, 01 Sep 1998 09:00:00 -0000 Message-id: X-SW-Source: 1998/msg00047.html From: "Michael Bruck" 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