Looking at Effective C++ - page 3
LinuxPlanet: The new edition of your book makes a point of discussing TR1 in many places. What is TR1 and why is it important to C++ programmers?
Meyers: Technically, TR1 is just the first technical report (hence the name) from the library subcommittee of the C++ standardization committee. Practically speaking, however, it describes a collection of 14 new pieces of functionality almost certain to be part of the next standard for C++. Included in this functionality is support for containers based on hash tables, use of regular expressions, extensive support for random numbers and mathematical special functions, reference-counting smart pointers, and much more. This means that many common tasks faced by C++ programmers can now be solved in ways that will eventually be as portable as any other standard-conformant code. This will make both programming and porting faster and easier than ever before. TR1 is just beginning to get exposure now, but I expect that within a year, several parts of it will see widespread use. It really does extend the standard C++ library in important ways, even if it's not officially part of the standard.
LP: You argue that C++ will play an increasing important role in embedded systems programming. Why?
Meyers: There are several reasons. First, many embedded systems projects now are at the level of complexity that used to be reserved for hosted applications 5 or 10 years ago. Embedded developers are thus faced with managing more software complexity than they used to, and C++ has better ways to manage complexity than the usual choice for embedded development, C. Second, many modern libraries and tools are now designed for C++ instead of C, so some embedded developers find that they get better tool or library support for their projects if they develop in C++ instead of C. Third, C++ compilers for embedded systems have matured to the point where they provide a viable alternative to C for many platforms. Fourth, knowledge about C++ in the embedded community has advanced to the point where people are no longer scared of it or skeptical of its abilities. I believe that for many--perhaps most--embedded systems, C++ is a more suitable development tool than C, and the mainstream embedded community has begun to believe that also and to start migrating to C++. I expect that migration to continue.
LP: In your book you list 55 specific ways to improve C++ program design. Are there any specific improvements that stand out in your mind as the most effective or of most benefit?
Meyers: I take satisfaction in knowing that much of the design advice I made in earlier editions continues to apply, e.g., the proper use of public inheritance; the proper use of pure virtual, impure virtual, and nonvirtual functions; the aggressive use of const, etc. But the third edition contains new advice that I think is critical, too. Three ideas that particularly stand out in my mind are the importance of using objects to manage resources, the importance of writing exception-safe code, and the many design alternatives--including their advantages and disadvantages--to virtual functions. Effective C++ has always had lots of nuts-and-bolts advice about using C++ well, but I've also always put in lots of design advice, often in the form of motivations or rationales for the specific C++ programming guidelines. I think the third edition upholds this tradition of building good programming practices on a foundation of solid design.
LP: What do you see as C++'s greatest weakness?
Meyers: The flip side to C++'s support for multiple programming paradigms; to its ability to offer both low-level constructs and high-level abstractions; to its provision for detailed programmer control; to its ability to communicate efficiently with other languages and systems--is its size and complexity. C++ is a big language, it's a complicated one, and, in general, it's difficult to hide the complexity even from users who just want to do something simple and straightforward. To me, that's C++'s greatest weakness, and I don't think it's one that can really be eliminated. However, the C++ standardization committee is considering some fairly simple changes to the language and library that are designed to smooth over some of these bumps, and the use of common programming idioms can help eliminate the need to understand all the nooks and crannies of the language. So there are ways to cope with the language complexity, and C++'s millions of users worldwide demonstrate that it need not be a serious impediment to getting important work done.