BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Learning Modern C++: An Interview with Barbara Moo

Learning Modern C++: An Interview with Barbara Moo

This item in japanese

Bookmarks

The popularity of C++ has varied throughout the years since its introduction in the 1980s.  The rise of managed languages like Java and C# along with the emergence of scripting languages like JavaScript, Python, and Ruby has affected C++'s adoption.  Yet many supporters like C++ for the control, raw power, and speed that it offers.  C++11 promises to bring that power to programmers in a more efficient manner, and the changes it introduces illustrate how much the language has grown in the past 30 years.  Programmers looking to learn about C++11 or perhaps sample C++ for the first time would do well to try C++ Primer, 5th Edition by Stanley B. Lippman, Josée Lajoie, and Barbara E. Moo.  InfoQ had the opportunity to speak with Ms. Moo about her new book and the C++ language as a whole.

InfoQ: Lets start with the approach of your new book.  You previously coauthored "Accelerated C++" which takes the approach of teaching C++ around its standard library.  C++ Primer 5th Edition continues this style.  By comparison,  the author of 3rd Edition used a completely different method (C plus C++).  I bring this up because I think it would be beneficial to discuss this philosophical shift in how the language as a whole is taught as well as the changes required to introduce C++11.  How did you and the new team become part of this project?

Barbara: Thanks. Indeed it was the success of Accelerated C++ that led AW to ask me to work on the 4th Edition of the Primer. The C++ Primer really has an important role in the C++ community. Since 1989, when the Primer was initially published, it has been more or less the gateway book for serious programmers that want a tutorial introduction to C++.

The first three editions of the C++ Primer were motivated by changes in the language. The 3rd Edition, which was published in 1998, focused on the 1998 standardization of C++. That edition was published before the new standard library was widely available. It was also published before Accelerated C++ demonstrated the advantages of teaching the library along with the language rather than as an advanced topic. Unlike previous editions of the C++ Primer, the primary motivation for the 4th Edition was to revise its teaching strategy. We decided to use the same teaching approach as Accelerated C++ and in particular to incorporate the library right from the start of the book.

Unfortunately, too many C++ books still teach low-level facilities based on arrays and pointers and teach the library as an advanced topic. But, using arrays and pointers is much more error-prone and harder to understand. Even worse, to simplify using arrays, many books end up teaching bad habits, such as using fixed-size arrays.

It is so much easier to write programs using the string and vector types. So, we present these types early in the Primer. When the new C++ 11 standard was nearing completion we decided to use the same strategy for presenting the new features. We completely revised the book to present the language as an integrated whole rather than teaching the new features as advanced topics grafted onto the existing language. Some of the new C++ 11 features in particular auto and decltype, range-based for statement, and smart pointers make writing programs much easier, so we teach these facilities along with other basics of the language.

InfoQ: What features of the new C++11 standard do you like the most?

Barbara: Well, I guess I sort of started to answer this question in the last one! The new auto and decltype type specifiers let programmers obtain the benefits of static typing (catching errors at compile time) without burdening programmers with writing long complicated type declarations or having to search through the program to know which type is needed.

Smart pointers make it easier and safer to use dynamic memory, but I think the biggest boon from smart pointers is that using them makes it easier to write classes that manage resources. Classes that use smart pointers (in place of ordinary pointers) don’t need to define the assignment operator, copy constructor, and destructor. That means we can write fairly complex classes without having to teach about copy control.
Some other features that I like are the new library facilities for programming with functions e.g., bind and function. These new facilities are much cleaner and uniform to use. Also, lambdas, which can be thought of as lightweight functions, make it easier to use and customize the behavior of the standard algorithms.
One really important change is one that many programmers may ignore but will benefit from anyway, which is rvalue references and move semantics. The ability to move rather than copy an object is something that is needed only for some kinds of classes. In practice I suspect that only fairly sophisticated programmers will directly write move operations. However, avoiding copies when an object can be moved does provide a BIG boost to the performance of the standard library containers and string class.

InfoQ: Anything crucial that was overlooked?

Barbara: No, not really. The committee had a draft for concepts, which was an attempt to add constraints checking to the language that got omitted. I think that was a good choice because the design really wasn’t ready.

InfoQ: How do you see C++ fitting in with today's software development world given today's popular areas (mobile/web/cloud)? There have been a numerous languages with various levels of popularity (Python / C# & Java / Go /etc) How do you feel C++ compares when starting a new project? (Or is it a matter of using C++11 for legacy C++ code bases?)

Barbara: Well, these languages differ from each other and from C++ in a number of important ways including both technical and nontechnical issues. With the exception of Go, with which I am not really familiar, these languages differ from C++ significantly and target different kinds of applications. If I’m writing a large-scale application that has rigorous performance, portability, hardware interface, or scale requirements these languages aren’t appropriate. On the other hand, if I’m building an application that is dominated by interaction with the user, then I’m probably looking at one of these kinds of languages.

As to the specific question of mobile/web/cloud computing, C++ is used for these kinds of applications as well. C++ is used to manage the server (in the cloud) computing. And of course, it’s also used for the operating systems that control the mobile devices themselves. So, even in this newest part of the computing industry there’s widespread use of C++.

There’s another important difference between C++, Python, and to a lesser extent Java, and languages like C#, Go, and Objective-C. The first group of languages have an open (or in the case of Java at least partially open) evolution process. As a result they are available on a wide variety of platforms. The same is not true for the second group. These languages are captive to particular corporate sponsors. Microsoft wants C# to be cross-platform but realistically it’s used only for projects that run on MS operating systems. So far Go is a Google language and Objective-C has little use outside Apple’s iOS applications. If you’re writing an application that can be tied to a single platform, then these languages are suitable. If not, then you really need to think about what happens when you need to support other hardware or operating systems.

 InfoQ: C++ has been described as 3 separate languages: the C pre-processor which has no knowledge of scope, the C++ runtime language, and the C++ compile time language-templates. Do you consider the C++ language that segmented? And if so, how much of an issue is it?

Barbara: No, I think that’s an overstatement. Yes, there is a preprocessor and yes it is disconnected from the C++ language itself. But, aside from #include and conditional compilation there’s been little reason to use the preprocessor in C++ since the mid-80s once C++ had inlines and const. As a result, most C++ programmers don’t even think about the preprocessor and needn’t be familiar with its additional facilities.

As to the distinction between the “run time” and “compile time” language, I think that’s a distinction that matters more to language designers and implementers than to programmers. Aside from those few C++ programmers who do template metaprogramming, many, probably most, C++ programmers, never think about the distinction between runtime and compile time when they use templates versus the other parts of the language. At most the distinction they see regarding templates is that they may not hear about errors until later in the compilation cycle. That may be a surprise at first, but it’s not a huge issue. A far bigger issue for programs that use templates is the state of the art regarding compiler error messages!

InfoQ: Some arguments against using C++ are its lengthy compile times and/or cryptic compilation errors. Do you see that as a real obstacle to be overcome or is it somewhat exaggerated? (In this case, there are some challenges but the power is worth the price?)

Barbara: As to compilation times, I think this used to be a much bigger deal than it is today. Like many other software systems, compilation times have gotten faster as machines have gotten faster. If you think about it, since the mid 1980s, when we started working on C++, machines have gotten about 1000 times faster. Systems haven’t gotten a thousand times bigger, so compilation times today are relatively much, much faster than they were when C++ got its reputation for slow compile times. Of course, teams that work on very large systems still have to give attention to how they organize their code in order to reduce compilation times. Unfortunately I think that’s a fact of life for large projects regardless.

As to cryptic error messages I think that’s a problem primarily regarding code that involves templates. I do wish compiler writers would put more effort into reporting template-related errors in terms used in the code itself rather than reporting errors using internal generated names. I primarily used the gcc compiler to test the code in the Primer and I must admit that the error messages relating to template-based code were useful to find the right line of code but too often didn’t help to much in figuring out what was wrong.

InfoQ: Since our last conversation Microsoft and others announced the Standard C++ Foundation. How do you feel this will affect C++ usage? What is your opinion on their goals to provide a central C++ location and a quicker release cycle of new standards?

Barbara:  As to the Standard C++ Foundation I am not real familiar with it yet and, of course, they’ve just started. I applaud the effort and so far it looks like it will be an interesting site to track.

About the Interviewee

Barbara E. Moo is an independent consultant with 20 years' experience in the software field. During her nearly 15 years at AT&T, she worked on one of the first commercial products ever written in C++, managed the company's first C++ compiler project, and directed the development of AT&T's award-winning WorldNet Internet service business.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • What about native code generation toolchains for Java and C#?

    by Paulo Pinto,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    In these type of interviews where a language with native code generation toolchain gets compared with JVM and .NET environments, I always miss the reference to existing native code generation toolchains for the said environments.

    As if it was convenient to forget such tools exist.

  • Not so fast ..

    by Cameron Purdy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    .. these languages [e.g. Java] differ from C++ significantly and target different kinds of applications. If I’m writing a large-scale application that has rigorous performance, portability, hardware interface, or scale requirements these languages aren’t appropriate.


    I don't feel that this matches reality at all:

    * Performance: For multi-threaded programs on modern multi-core processors, the static compilation approach that C++ uses is far inferior to the dynamic optimizations that JIT compiler technology has at its disposal. Java's seventeen-year-old "java.util.Hashtable" benchmarks at 3x the performance of a similar C++ data structure built using smart pointers, and newer "atomics" (i.e. CAS-based) concurrent data structures are even better than that!

    * Portability: While C++ code may be more portable today than it was in 1990 (when it was roughly as portable as C -- i.e. portable in theory only), it is very low on the list of language choices for portability. The continued standardization of the library will help a lot in this area, though.

    * Hardware Interface: Hardware interface libraries almost always expose C interfaces (not C++).

    * Scale Requirements: I suppose this depends on how one defines "scale requirements". Are we talking about scale at run-time, in which case C++ has no intrinsic advantages and some disadvantages (e.g. paucity of distributed systems capabilities)? Or are we talking about "scale" at development time, in which case C++ may be better than assembly, Javascript and Perl, but arguably worse than most other modern languages? Or perhaps by "scale", what was actually meant was "small footprint at run-time"?

    C++ is used to manage the server (in the cloud) computing.


    That's an odd example to cite; I haven't seen C++ used much for this type of work at all! Consider the most commonly used examples:

    * Puppet (Ruby)

    * Chef (Ruby & Erlang)

    * OpenStack (Python)

    * CloudStack (Java)

    Instead of cloud server management, I'd have suggested something like "web browsers built using C++":

    * Chrome

    * Firefox (partial)

    * Webkit

    But while I disagree with a number of the statements made, and I'm no fan of C++, C++11 appears to be a definite improvement on C++ in a number of areas. There really aren't a lot of choices in the low-level language arena, so if you consider C++ as the "Siamese twin" of C, then C/C++ is pretty close to the only choice for low-level work, and it's still one of the most widely used languages overall.

    Peace,

    Cameron Purdy

    The opinions and views expressed in this post are my own, and do not necessarily reflect the opinions or views of my employer (Oracle).

  • Re: Not so fast ..

    by Carlos Quijano,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    You may not know that although Cameron is right with her performance disquisitions, the sadly true is not so benevolent with Java... I have experience building big multi-process systems and for the same performance obtained with 10 servers and a LAMP architecture we needed 100 servers with Java... And stability was horrible... As you probably know, this kind of open source architecture relies on Linux (mostly programmed in C / C++) and is mostly coded in Perl or PHP with the performance dependant tasks (mostly about calculus / statistics) in .so libraries coded in C / C++. So when you execute a command in Perl / PHP script you are executing native C/C++ power-horse algorithms that are far away from Java's performance's reach...

    Regarding this "C++ is used to manage the server (in the cloud) computing". I think you are somewhat confused in terms of systems and applications. I bet Barbara is talking about the server (system) itself from a structural point of view (not a user friendly POV). Then Barbara is right: The servers are C++ as we human beings are carbon and water. Of course there is anecdotal % of code in Java, Python or Ruby in typical servers. In the case of Linux I have to remind that none of this three languages even compares Perl in %code MANAGING the server: It is, helping loading kernel modules, basic operative system libraries, hardware interfaces and drivers and the utilities to truly manage them.

    That’s what I think that Barara is meaning when saying "to manage the server"...

    Take care & peace 4 U 2.

    I worked for Sun looooong ago. I am also PhD in Bioinformatics and Systems Architect.
    ;-) My opinions are also mine and only mine and are probably wrong too.

  • some questions of the interview

    by 李 彬,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    “By comparison, the author of 4th Edition used a completely different method (C plus C++). ”

    Should it be "3rd edition" here? Since Moo was one of the aurthers of the 4th editon.

    And the paragrah "As to cryptic error messages...... seems to be the answer of the previous question?

    Thanks.

  • Re: Not so fast ..

    by N M,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Cameron,

    Well, let's go one-by-one.

    * Performance

    Right, we've all heard about the mythical SufficientlyFastJITCompiler with "dynamic optimization" that's going to catch up "any time now" -- since (at least) the very early 1990s ;-)
    Other than simple mini-benchmarks with trivial for-loops, this simply hasn't arrived.
    What this hope (because it's more of a hope than actually an delivering-what's-promised in-practice tech right now[*]) ignores is that the state-of-the-art as far as compiled languages are concerned isn't exactly frozen and waiting for the managed world to catch up -- PGO (available for C++ and able to use run-time execution path to fine-tune performance) differs from the JIT-optimization-hype in that it actually exists today and works in practice:
    en.wikipedia.org/wiki/Profile-guided_optimization
    msdn.microsoft.com/en-us/library/e7k32f4k%28v=v...

    [*] the currently existing JIT-optimization implementations don't meet the delivering-what's-promised in-practice constraint;

    Herb Sutter is still asking "When will better JITs save managed code?"
    herbsutter.com/2012/04/02/reader-qa-when-will-b...

    Frankly, I wouldn't hold my breath ;-)

    Other than that, static optimization techniques (that have been with native languages like Fortran, C, or C++ since the optimizing compilers were invented) can be performed more extensively (and thus at a significantly more advance lavel) than in the time-frames dealt with by the JITters.

    What this means in practice right now is that empirical results show it's not even close:
    benchmarksgame.alioth.debian.org/u64q/which-pro...

    In addition, with the growing importance of many-core and GPGPU and the already rich and growing ecosystem of modern C++ solutions (Thrust as part of CUDA 5 from NVIDIA, or C++ AMP from Microsoft), I can't see how Java can even compete here.

    * Portability

    As far as PC is concerned, it's pretty much comparable.
    As far as mobile is concerned, C++ will run on:
    - BlackBerry 10+ and PlayBook
    - Apple iOS
    - Android NDK (Android SDK 1.5+)
    - Windows Mobile 8+
    I don't think there's even a JVM for many of these...
    Embedded: most platforms would choke on the JVM's memory requirements.

    Java is too limiting here.

    * Hardware Interface

    Intel delivers a whole suite of C++ solutions supporting features of its newest CPUs
    threadingbuildingblocks.org/
    software.intel.com/en-us/articles/intel-array-b...
    software.intel.com/en-us/intel-cilk-plus

    NVIDIA includes Thrust with its CUDA tooling since CUDA 4.0:
    thrust.github.com/

    AMD delivers Bolt C++ Template Library as an integral part of its Accelerated Parallel Processing (APP) SDK:
    developer.amd.com/tools/heterogeneous-computing...

    So, it's not the 1990s anymore.

    At the same time, C is not a problem and you can call C APIs seamlessly from C++ (which has been designed with this in mind).

    As opposed to using C through, say, Java Native Interface, which is so slow so as to (more than) cancel many potential performance improvements:
    stackoverflow.com/questions/1562111/jni-perform...

    * Scale Requirements

    *The* map-reduce solution, Google MapReduce, has been implemented in C++:
    static.googleusercontent.com/external_content/u...

    You might want to inform Google, Amazon, and Facebook, perhaps they'll all switch from C++ to Java ;-)

    Of note, the Oracle Database also uses C++ for its implementation:
    www.lextrait.com/Vincent/implementations.html
    blogs.embarcadero.com/davidi/2013/02/26/42586

    Oracle's JVM, HotSpot, is also written in C++.

    So, are you perchance suggesting that the Oracle Database or Oracle's JVM do not scale?

    * Applications *

    From a tiniest micro-controller, through every mainstream cellphone, any PC, web infrastructure (incl. Amazon and Facebook), financial infrastructure (buy-side, sell-side, and exchanges themselves), to jet fighters in the sky and the International Space Station (ISS), SpaceX's Dragon spacecraft, and Mars Rovers in space:

    www.lextrait.com/Vincent/implementations.html
    blogs.embarcadero.com/davidi/2013/02/26/42586
    archive.org/stream/nasa_techdoc_20060009036/200...
    www.extremetech.com/extreme/127765-how-spacex-d...
    www.stroustrup.com/applications.html

    I'd say this is pretty scalable :-)

    * Productivity

    Again, this sounds like a snippet from some 1990s marketing materials.

    Right now, a more appropriate language to compare C++11 with, as far as the syntax is concerned, would be Python:
    cpp-next.com/archive/2011/11/having-it-all-pyth...

    Java, with its baroque 1990s big-class-hierarchy frameworks fits better in the COBOL league. I admit, it has alleviated some of the problems with the "C with Classes", but this language doesn't exist anymore. So, yeah, Java, released in 1996, solved the 1996 problems. This is all a blast from the past... Frankly, I'm surprised you'd even attempt a comparison here :-)
    It's good that you're suggesting a focus on the more modern languages though; C++ has been first standardized in 1998 and as such is a more modern language, perhaps it's worth getting familiarized with its 2011 version :-)

    If you're looking for a neater language on a JVM platform, you might want to consider Scala.

    What the comparisons often ignore is just like Java has frameworks, C++ has pretty good modern libraries (with a pretty lightweight user code):
    pocoproject.org/
    www.boost.org/

    For instance, compare:
    java.net.HttpURLConnection
    digiassn.blogspot.com/2008/10/java-simple-httpu...

    Poco::Net::HTTPClientSession
    www.codeproject.com/Articles/252566/Learning-Po...

    Hope that helps :-)

  • Re: Not so fast ..

    by Cameron Purdy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Well, let's go one-by-one.


    Agreed ;-)

    * Performance
    Right, we've all heard about the mythical SufficientlyFastJITCompiler with "dynamic optimization" that's going to catch up "any time now" -- since (at least) the very early 1990s ;-)
    Other than simple mini-benchmarks with trivial for-loops, this simply hasn't arrived.
    What this hope (because it's more of a hope than actually an delivering-what's-promised in-practice tech right now[*]) ignores is that the state-of-the-art as far as compiled languages are concerned isn't exactly frozen and waiting for the managed world to catch up -- PGO (available for C++ and able to use run-time execution path to fine-tune performance) differs from the JIT-optimization-hype in that it actually exists today and works in practice:


    I can show C/C++ being faster than Java, or vice versa. That's not very hard. There's still a lot of code that is being written in C/C++ for good reason; there is no one single language that "does it all well".

    However, what is hard is finding ways to get highly concurrent C/C++ code (i.e. multi-threaded, running on more than one core or CPU) that shares data structures that may be mutable to perform well.

    The benchmarks that most people point to are benchmarks of startup time, or benchmarks of single-threaded code. If I were writing a simple single-threaded piece of code that had stringent startup-time requirements, I might use C. Unfortunately, I live in the real world.

    Just to be clear, the optimizations that Java (and other runtime optimized languages) can do at runtime cannot be done by a statically compiled language. Let me know when you grok that. This is particularly impressive for concurrency control mechanisms.

    Other than that, static optimization techniques (that have been with native languages like Fortran, C, or C++ since the optimizing compilers were invented) can be performed more extensively (and thus at a significantly more advance lavel) than in the time-frames dealt with by the JITters.


    Again, you're referring to the state-of-the-art from 15 years ago. The JIT compilers today spit out pretty good code almost instantly, and then -- while the application is running -- they spend minutes (or even hours or days) collecting runtime information and optimizing (and as necessary, de-optimizing) code to produce much better optimized code.

    * Portability

    As far as PC is concerned, it's pretty much comparable.
    As far as mobile is concerned, C++ will run on:
    - BlackBerry 10+ and PlayBook
    - Apple iOS
    - Android NDK (Android SDK 1.5+)
    - Windows Mobile 8+
    I don't think there's even a JVM for many of these...
    Embedded: most platforms would choke on the JVM's memory requirements.

    Java is too limiting here.


    "As far as PC is concerned"??? First, that's not portability. Second, it isn't true. Even supporting three different OSs (Linux, Windows, OSX) on the same hardware is fairly challenging with C++.

    Second, for mobile, even though the OS is typically written in C (not C++), the providers will often disallow you from putting your own native code on their hardware!

    Third, Android is Java.

    Fourth, I've seen the JVM run fine on most if not all of those mobile platforms. Again, this isn't the 1990s ;-)

    And regarding embedded, it's now the area of the fastest growth for Java!

    * Hardware Interface


    I'm not talking about companies putting together syntactic sugar frameworks around their native C APIs ;-)

    * Scale Requirements

    You might want to inform Google, Amazon, and Facebook, perhaps they'll all switch from C++ to Java ;-)


    All three of those use Java extensively for their web sites and applications. While they may build some plumbing and system code with C/C++, they use C/C++ very little for building applications.

    C++ is not efficiently scalable in development.

    At runtime, I would argue that scalability is in the architecture and design of a system, and not in the language choice. You could build an Amazon-scale web site with VB if you had to (but yes, it would be ugly).

    Java, with its baroque 1990s big-class-hierarchy frameworks fits better in the COBOL league. I admit, it has alleviated some of the problems with the "C with Classes", but this language doesn't exist anymore. So, yeah, Java, released in 1996, solved the 1996 problems. This is all a blast from the past... Frankly, I'm surprised you'd even attempt a comparison here :-)


    Sorry, it's still C with Classes. You can't put lipstick on this one .. just look at the errors the compiler spits out, and you know what's underneath. (OMG!!!)

    If you're looking for a neater language on a JVM platform, you might want to consider Scala.


    I like Scala, but calling it "neater" is interesting. While it can be less verbose, it is (like C++) quite difficult to know what will actually happen at runtime from looking at the source code. In some was, C++ to C is like Scala to Java.

    What the comparisons often ignore is just like Java has frameworks, C++ has pretty good modern libraries (with a pretty lightweight user code):
    pocoproject.org/
    www.boost.org/


    Yes, I've used boost. It's pretty good for a C++ library. However, one or two glue-on libraries do not a platform make. Also, because it's not built into the platform, it means that every app has to ship it.

    Again, as I said before:

    But while I disagree with a number of the statements made, and I'm no fan of C++, C++11 appears to be a definite improvement on C++ in a number of areas. There really aren't a lot of choices in the low-level language arena, so if you consider C++ as the "Siamese twin" of C, then C/C++ is pretty close to the only choice for low-level work, and it's still one of the most widely used languages overall.


    Regarding Java, while I do like it much more than C++ (for most projects), it's not a panacea either. Every time I have to work in C++ though, I desperately miss the advances that are present in Java.

    Peace,

    Cameron Purdy

    The opinions and views expressed in this post are my own, and do not necessarily reflect the opinions or views of my employer (Oracle).

    p.s. Do you have a name?

  • deterministic performance, templates and evolution

    by Gerald Loeffler,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    One of the important advantages of C++ over e.g. Java is the availability of a style of memory management (no GC, allocation on the stack) that results in deterministic performance characteristics. I'm not saying that i personally miss this, but it's interesting that amidst all the hatred directed at Java in the posts above (in a manner which i haven't seen for at least a decade) this fails to get mentioned.

    For this reason, and the ones listed by Cameron, i'd say Ms. Moo doesn't do a good job comparing C++11 to other languages. But clearly this is only a marginal topic in this interview, and shouldn't distract from here real expertise, i.e. C++ itself.

    As concerns the rather incoherent attack on the design of the Java standard library (which, for all its signs of age in some spots, is in fact remarkably expressive, comprehensive and reliable) i'd find it much more important to mention the enormous influence that C++'s rather unique template system has on the design of the C++ standard library. I'd say this template-centric style represents an approach to library design that is (in the mainstream) unique to C++ and can't be replicated in e.g. Java. That's not a value judgement, just an observation.

    Of course, the design of a standard library is not everything: essential in practice (as Cameron says) is also its breadth, and here the C++ standard library is unfortunately a bit under-developed.

    Personally i find the new develoments in C++11 very exciting, a worthy evolution along the unique path that C++ has chosen decades ago. I'll have to buy yet another edition of the C++ Primer, it seems ;-)

    cheers
    gerald

    www.gerald-loeffler.net

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT