Featured Title Effective C++: 55 Specific Ways to Improve Your Programs and Designs



| The first five questions were submitted by Brad from Gilbert, AZ:

1. What do you see as the future of C++, and where will it fit in the future of computer science? I view C++ as the language of choice for what I call "demanding systems applications." Such applications face one or more constraints that are difficult to meet. Often, the constraint is on performance (e.g., the software must be as fast as possible), sometimes it's on space (e.g., it must fit within limited memory), sometimes it's on control (e.g., the application must communicate directly with hardware). Such applications have traditionally been the domain of C, but I think that C++ will continue to gain ground here.



Industries where such applications are common include embedded systems, games, financial analysis, and simulations. For many applications in such industries, reducing program runtime is more important than reducing programmer development time (though that is important, too), so C++ has an edge over "productivity languages" like Java and C#.



As for C++'s role in computer science, I think that C++ will continue to be an important testbed for ideas in multiparadigm programming and in template metaprogramming and related technologies (e.g., expression templates).



2. What language would you recommend be used to teach programming to new CS students? My language expertise is limited to C++, and I don't really know enough about the pros and cons of competing languages to make an informed evaluation. Having said that, my feeling is that a first language should foster a feeling of power and accomplishment out of the box — it should get people excited about the limitless things that can be accomplished in software. Among other things, such a language would offer an extensive and powerful library, so that complex tasks such as navigating the internet or putting up GUIs would be easily accomplished.



Candidate languages that come to mind would be Java, C#, and Python. Neither C nor C++ offers sufficiently powerful libraries to be good candidates for a first language, in my opinion. When it comes to systems programming, they're great (C++ is greater :-}), but I don't think that introducing programming through systems applications is the best approach for the majority of new students.



Books on Related Subjects C++

Object-Oriented

Software Development

Visual C++

Best Sellers

New Releases

3. Every language has its flaws. What are the three things you dislike most strongly in C++? I'd like to answer this question with "complexity, complexity, complexity!", but naming the same thing three times is cheating. Still, I think that C++'s greatest weakness is complexity. For almost every rule in C++, there are exceptions, and often there are exceptions to the exceptions. For example, const objects can't be modified, unless you cast away their constness, in which case they can, unless they were originally defined to be const, in which case the attempted modifications yield undefined behavior.



As another example, names in base classes are visible in derived classes, unless the base class is instantiated from a template, in which case they're not, unless the derived class has employed a using declaration for them, in which case they are.



Such complexity affects more than just people who write programs in C++. It also affects people who want to write tools that analyze C++ programs. One of the reasons why there is a relative dearth of tools such as refactoring browsers for C++ is that C++ is just so darned complicated.



A related aspect of C++ I dislike has to do with what I perceive to be an attitude on the part of the standardization committee that such complexity is not a problem. I suspect that many members of the committee would object to my characterizing their attitude that way, but I'm talking only about my perception of their attitude. I know that the people on the committee work hard to make C++ as good as it can be. I also know that there are proposals before the committee whose goal is to simplify C++. Still, my impression is that the committee as a whole is unsympathetic to arguments that C++ has become too complex, and I find that frustrating.



The third weakness of C++ I'd list is one I mentioned above: its standard library is comparatively limited. I often say that the "hello world" program for authors approaching a new language is one that goes to Amazon, looks up the sales rank of one or more books they wrote, then graphs the sales ranks over time. This is easy to do with C# and Java, because they have libraries that make grabbing URLs and producing graphs easy. In C++, it's a lot harder, because such library functionality is missing.



4. A lot of CS work is being done on the web now; how does C++ fit into web development? Because I believe that C++ is the language of choice for demanding systems applications, I'd expect that in the web realm, C++ would be a good fit for web servers, database query optimizers, even runtime program optimizers. I can't help but take some satisfaction in knowing that the hotspot JVM is largely written in C++ :-)



5. What's your dream? My dream is not having to work for a living, but that's a pretty common dream, so I'll pick one that is probably less familiar.



As a user, my experience with commercial software and commercial software companies is not very satisfactory. I find that many programs have what I consider to be serious problems in usability, functionality, or robustness, and that the companies that make the programs demonstrate little interest in addressing these shortcomings.



My dream is for a revolution in the quality of end-user software to rival the revolution in the quality of automobiles that took place in the 1970s when Japanese automobiles began to make serious inroads into the American market. I think that there has already been something of a revolution of this nature in the server environment, thanks to the challenge mounted by Linux, and I hope that an analogous revolution takes root on the desktop.



However, the revolution has to take place in more than just the software itself. The companies behind the software have to change, too. As long as we have to make long-distance phone calls for technical support to software companies that put us on hold and play recordings telling us how important our calls are while simultaneously doing everything they can to avoid having a human being talk to us, my dream remains unfulfilled.







The following five questions were submitted by Vainstein from California:

0. Do you see C++ ever getting simpler? Dropping features, prohibiting co-use of certain features, etc.? I don't think there is any practical way that C++ can get meaningfully simpler. Any change to the rules of C++ that is not backwards-compatible will face tremendous resistance in the standardization committee, and I think this is proper: it's bad policy to make changes that break programs that are currently legal, and it's even worse for the semantics of legal programs to be modified, i.e., for "silent" changes to be foisted on developers.



Even if the committee decided to deprecate some language features, the process would take years, and there would be significant pressure on vendors to continue to support the deprecated features, anyway. After all, a vendor who removes a feature can only irritate existing customers, whereas leaving the feature intact and possibly issuing an optional warning allows them to follow the letter of the law without enforcing its spirit.



As I mentioned above, there are some proposals before the committee to simplify what I call "little things," (e.g., automatically declaring a destructor virtual in a base class if the class already has virtual functions), but such changes are window dressing. There's no practical way to simplify the more fundamental issues I mentioned above (e.g., when const means const and when base class names are inherited in derived classes). C++ wasn't designed to be simple, and I don't see any practical way to retrofit simplicity onto it now.



1. Do you think C++ compilers could evolve to give errors if a programmer does stuff like return a reference from a function? They clearly could, the question is whether they will. I've spent a number of years studying static analysis, and I've concluded that compiler writers view their job as generating good object code from valid source code. Along the way, they may issue warnings, but issuing warnings isn't really their purpose, and they do it with some reluctance. After all, they know that some clients require warning-free compilations, and they also know that in real programs, it's sometimes necessary to bend or break the rules of good programming in order to get the job done. This means that every additional warning they offer may make somebody's job harder, so they tend to be conservative with what they warn about. People who want more extensive static analysis can often turn on compiler warnings that are disabled by default, but if you want really good static analysis, you want an independent lint-like tool that does nothing but look for suspicious coding constructs. Several vendors offer such tools for C++.



2. What do you think of Java? For me, one of the best things in Java is separate mechanisms for subclassing and for subtyping — do you think this would be helpful in C++? I don't have any general comments about Java, because I don't really know it. (For the most part, my knowledge of Java and C# is as deltas from C++.)



As for subclassing vs. subtyping, I assume you're referring to inheritance vs. interfaces, and I haven't seen any groundswell of support for adding interfaces to C++. Essentially the same behavior can be achieved with the disciplined use of abstract base classes, and I expect it'd be a hard sell to convince the C++ community that they need another inheritance-like mechanism. I have seen some people arguing for such a feature, but, as far as I know, it's not on the list of features likely to be seriously considered for the next version of C++. However, it's my understanding that Microsoft's .NET version of C++ (C++/CLI) supports interfaces, though, again, I have no reason to believe that this feature will be added to standard C++.



3. What would you have to say to battle-worn industry managers who forbid use of any C++ features except the single-line comment? I guess I'd point out that that means they're programming C, then I'd ask them if they're sure that's really the best language for their applications in 2005. If they said yes, I'd leave it at that, but if they hesitated, I'd ask them how long ago their C++ battles took place. Many people think that C++ and C++ compilers haven't changed in a decade, but they've actually changed quite a bit. Many battle-worn managers owe it to themselves to take a fresh look at C++.



4. Do you plan to get into anything beside C++, yourself? In terms of software, I've been into other things for quite some time. A few years ago, I started work on what I call "The Keyhole Problem," which is an examination of the problems that arise in software from the inappropriate use of constraints. Work on that project has been on the back burner during preparation of the third edition of Effective C++, but I encourage people to take a look at the web site for the keyhole problem, http://www.aristeia.com/TKP/index.htm.



My overarching interest is in ways to improve software quality, regardless of the domain of the application, the language in which it's written, the platform on which it runs, or the users it is intended to serve. The keyhole problem is one reflection of this interest, but so is my work in C++, because it's all about how to improve the quality of the software you write. Recently, I've been trying to identify methods and practices that yield better software across the board. The primary result so far is a one-day seminar I give on the topic (cf. http://www.aristeia.com/betterSoftware_frames.html), but there's also a short article on part of that material (http://www.aristeia.com/Papers/IEEE_Software_JulAug_2004.pdf).



Last year Andrei Alexandrescu and I co-authored an article in Dr. Dobbs Journal on how the possibility of compiler and hardware optimizations can affect the correctness of multithreaded C++ programs (cf. http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004.pdf). Next-generation hardware architectures will place a much greater emphasis on multithreading to achieve high performance, so I've become interested in threading issues. It would not be hard to imagine writing a book on this topic, but that's one of the problems with being an author: after a while, everything looks like a book opportunity :-)



I've also been threatening for nearly a decade to write a book that my parents can understand — something nontechnical. I'd really like to do that, and in fact I hope to start this year. However, I always have much more to do than time in which to do it, so there's no telling what I'll get done in the next few months. However, it's fair to say that it will encompass more than just C++ stuff.

