From mboxrd@z Thu Jan 1 00:00:00 1970 From: "P.J. Plauger" To: c++-embedded@cygnus.com Subject: EC++ Date: Mon, 31 Aug 1998 02:56:00 -0000 Message-id: X-SW-Source: 1998/msg00045.html From: "Michael Bruck" 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