What's in Store for C++?Q: It wouldn't be an exaggeration to say that very little has been done to bring Visual C++ to full ANSI/ISO compliance since the release of Visual C++ 5.0 in 1997. However, Microsoft has recently announced its commitment to bring Visual C++ .NET into compliance with the C++98 standard. What is the cause of this change of heart? When will we have a fully standard-compliant version of Visual C++?
A: Microsoft definitely does intend to ship a fully standard-compliant version of Visual C++. It won't all be in this next incremental release that we have in early beta right now, but the majority of the conformance improvements will be in there, including partial specialization. It's certainly conformant enough that the most modern C++ community libraries, particularly Loki, Lamba and Boost, compile in-house without workarounds today. Few shipping compilers on any platform can do thatthose libraries are well known as "compiler busters." Only the strongest compilers can handle them correctly.
Q: Four years have passed since the ratification of the ANSI/ISO C++ standard. In retrospect, it seems that the standardization committee was sometimes hasty to accept dubious features. Namespaces, for instance, seem to be causing more trouble than benefit both to programmers and compiler writers. The new typecast notation, function try blocks, and exception specifications are other examples of such questionable features. Do you agree with this criticism? Are there other features in the C++ standard that you consider superfluous or ill-chosen?
A: I think that's overstated. Besides, I doubt that a single programming language or software productor electric toothbrush, for that matterever shipped that didn't have superfluous or ill-chosen features in somebody's opinion.
As I've written recently, it appears that today's standard exception specifications aren't very useful in practice (except possibly for the throws-nothing specification). Our experience with export, brief as it is, likewise seems to indicate that it's a half-baked feature. At the very least, it's a misunderstood feature. Export doesn't deliver what most people who are anxiously awaiting it are expecting (to wit, export does not mean that you can ship template libraries without full template source code).
But why invent FUD about other features, like new-style casts? They're genuinely useful, and I am not aware that anyone has ever questioned their utility. With regards to namespaces, I address this in the closing items of my most recent book, "More Exceptional C++." Basically, I debunk the camp that urges programmers to always explicitly namespace-qualify all names because it's bad advice offering little or no real advantage. It just creates useless typing overhead. After all, there's nothing wrong with the liberal use of using-directives when there aren't any name ambiguities, and why tell people to always manually resolve names even when there is no name collision to resolve? That doesn't mean namespaces are broken. How else are you going to distinguish name collisions when two different libraries declare the same name, unless you're willing to use namespaces or an equivalent disambiguation method? Clearly namespaces, new-style casts, and other such features offer important functionalities and solve real problems, both large and small.
Q: Standard C++ doesn't support modern programming concepts such as multithreading, distributed computing, components, and persistence. The result is a plethora of proprietary libraries and platform-dependent frameworks that make cross-platform development in C++ nearly impossible. Is Standard C++ still relevant? Which features would you like to see added to the language in the future?
A: Again, these questions arise from an overstated premise. Thousands of companies are routinely writing and shipping cross-platform software written in C++. Claiming that it's "nearly impossible" doesn't change the fact that we've been doing it for years. The one big area I can think of where portability is genuinely difficult is one the question didn't mentionGUIs. GUI portability is a problem in all languages, unless you give up writing rich GUIs and write only simple and limited ones. Interestingly, despite some languages' attempts to "standardize" cross-platform GUI libraries, the best and most successful solution for cross-platform GUIs is not a code library at all, but HTML.
|Thousands of companies are routinely writing and shipping cross-platform software written in C++. Claiming that it's "nearly impossible" doesn't change the fact that we've been doing it for years. |
The services that these questions address are, of course, important. You can do all of these things whether there is a standardized syntax for them or not. I agree that a standard syntax would be nice and that's why such things are on the hit list to be added for the next version of the C++ standard.
Q: What is your advice to new C++ programmers? In your opinion, are there other programming languages that C++ programmers should learn?
A: Always learn. Learn from the existing literature, C++ books and magazines and Web articles. They help you avoid reinventing well-known wheels. Learn different languages. They embody different ways of thinking. Learn different tools. They teach different ways of approaching problems. Most language zealots I've encountered think that their favorite language is the be-all and end-all, simply because they know few or no other languages. Know the various tools you have available to you, and you can do a much better job of selecting the right toolsplural, not singularthat will help you get your job done today.