From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael Bruck" To: "c++-embedded" Subject: Re: Undeliverable Internet Mail, no local user(s) defined Date: Sat, 29 Aug 1998 15:45:00 -0000 Message-id: <001401bdd39e$d984e260$3f0581c0@avh.ins-coin.de> X-SW-Source: 1998/msg00044.html > >>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 , 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