From mboxrd@z Thu Jan 1 00:00:00 1970 From: "P.J. Plauger" To: c++-embedded@cygnus.com Subject: FW: Undeliverable Internet Mail, no local user(s) defined Date: Sat, 29 Aug 1998 07:17:00 -0000 Message-id: X-SW-Source: 1998/msg00043.html From: "Michael Bruck" 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 , 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