Bjarne Stroustrup on C++0x

[Andy Nguyen]

What do you think of C++0x?

That's a (to me) amazingly frequent question. It may be the most frequently asked question. Surprisingly, C++0x feels like a new language: The pieces just fit together better than they used to and I find a higher-level style of programming more natural than before and as efficient as ever. If you timidly approach C++ as just a better C or as an object-oriented language, you are going to miss the point. The abstractions are simply more flexible and affordable than before. Rely on the old mantra: If you think of it as a separate idea or object, represent it directly in the program; model real-world objects, and abstractions directly in code. It's easier now: Your ideas will map to enumerations, objects, classes (e.g. control of defaults), class hierarchies (e.g. inherited constructors), templates, aliases, exceptions, loops, threads, etc., rather than to a single ``one size fits all'' abstraction mechanism.
My ideal is to use programming language facilities to help programmers think differently about system design and implementation. I think C++0x can do that - and do it not just for C++ programmers but for programmers used to a variety of modern programming languages in the general and very broad area of systems programming.

In other words, I'm still an optimist.

When will C++0x be a formal standard?

The first draft for formal comments was produced in September 2008. This is the one that's currently available for comments. After about another year's work -- probably September 2009 -- the committee will vote out another CD and (after receiving comments) hopefully a final draft for the national standards bodies to vote on. That final draft (FDIS) is likely to become the new standard with only typographical changes a few months later.
By October 2009, we should know exactly what the new standard will look like and then we can discuss whether that language should be referred to as C++10 or C++0B or C++oxC or whatever. Personally, I prefer plain C++ and to use a year marker only when I need to distinguish it from previous versions of C++, such as ARM C++, C++98 and C++03. For now, I bow to convention and still use C++0x for the next version. Think of 'x' as hexadecimal.

When will compilers implement C++0x?

Currently shipping compilers (e.g. GCC C++, IBM C++, and Microsoft C++) already implement some C++0x features. For example, it seems obvious and popular to ship all or most of the new standard libraries.
I expect more and more features to become available with each new release. Most likely, relatively isolated features, such as auto, lambda, and strongly typed enums, to be among the first available. I do not care to guess when every compiler will provide all of C++0x -- undoubtedly, that will take years -- but I note that every C++0x feature has been implemented by someone somewhere so there is implementation experience available for implementers to rely on.

C++0x FAQ

 

[wildcolor]

New language to study ...

 

[alain]

from "Coders at Work" (http://www.amazon.com/Coders-at-Wor...=sr_1_1?ie=UTF8&s=books&qid=1260852006&sr=8-1)

...
Ken Thompson, who still mostly uses C despite working at Google which is largely a C++ shop, has had as long an exposure to C++ as just about anyone, having worked with with Bjarne Stroustrup, C++s inventor, at Bell Labs:

I would try out the language as it was being developed and make comments on it. It was part of the work atmosphere there. And youd write something and then the next day it wouldnt work because the language changed. It was very unstable for a very long period of time. At some point I said, no, no more.
In an interview I said exactly that, that I didnt use it just because it wouldnt stay still for two days in a row. When Stroustrup read the interview he came screaming into my room about how I was undermining him and what I said mattered and I said it was a bad language. I never said it was a bad language. On and on and on. Since then I kind of avoid that kind of stuff.
​

At that point in the interview I almost changed the topic. Luckily I took one more try at asking for his actual opinion of C++. His reply:

It certainly has its good points. But by and large I think its a bad language. It does a lot of things half well and its just a garbage heap of ideas that are mutually exclusive. Everybody I know, whether its personal or corporate, selects a subset and these subsets are different. So its not a good language to transport an algorithmto say, I wrote it; here, take it. Its way too big, way too complex. And its obviously built by a committee.
Stroustrup campaigned for years and years and years, way beyond any sort of technical contributions he made to the language, to get it adopted and used. And he sort of ran all the standards committees with a whip and a chair. And he said no to no one. He put every feature in that language that ever existed. It wasnt cleanly designedit was just the union of everything that came along. And I think it suffered drastically from that.
​

...

Read more from this link http://www.gigamonkeys.com/blog/2009/10/16/coders-c++.html

 

[cgorac]

Ken Thompson's opinion is actually typical (well, sure it is: Ken is father of all of it, after all) opinion about C++ in the world of Unix programmers community (note that I don't mean on kernel programmers only here, but on all of us old-school guys that learned programming on Unix systems, and adopted approach to programming manifested by Unix system and tools implementations). You could find it nicely summarized also in this excerpt from The Art of Unix Programming. Eric also at one point announced he's working on an "C++ Considered Harmfull" essay, that would extend on this short chapter from the book; unfortunately, nothing followed up yet...

 

[Daniel Duffy]

If you think of it as a separate idea or object, represent it directly in the program

Sort of off-topic,

Unfortunately, this approach does not always work in practice. Classes are context-sensitive and need to be modified when used in new situation.

The original statement was popular in the 90's when OOP was in his youth. It is (only) one of a number of paradigms that are needed, especially in multi-threaded design.

In fact, producing flexible classes is very difficult.

 

[Eugene Krel]

Some juicy stuff in that FAQ in terms of new functionality, seems like they are making c++ more prototype friendly.

 

[GoIllini]

COBOL0x, anyone?

C++ in Finance=Latin=Mortua Lingua.

Ok, that's a bit too strong of a statement, but every indication I've seen is that C++ is on its way out in finance. Our firm is moving to replace C++ systems with JNI stuff. You get easier and better architecture, cross-platform execution/implementation certainty, and fewer things can go wrong. (Decent programmers get memory leaks in large C++ systems all the time. The same isn't true in Java.) Do you really want to run C++ as part of a distributed system?

The general rule of thumb- assuming everyone on your team knows the same languages and you have a choice between a higher-level and a lower-level one- is to use the highest-level language you can for the performance you need. And new development has allowed Java and C# to perform almost as efficiently as C++ and C.

 

[Andy Nguyen]

On the 25th, in Madrid, Spain, the ISO C++ committee approved a Final Draft International Standard (FDIS) for the C++ programming language. This means that the proposed changes to the new standard so far known as C++0x are now final. The finalization of the standard itself, i.e. updating the working draft and transmitting the final draft to ITTF, is due to be completed during the summer, after which the standard is going to be published, to be known as C++ 2011. With the previous ISO C++ standard dating back to 2003 and C++0x having been for over eight years in development, the implementation of the standard is already well underway in the GCC and Visual C++ compilers. Bjarne Stroustrup, the creator of C++, maintains a handy FAQ of the new standard.

http://herbsutter.com/2011/03/25/we-have-fdis-trip-report-march-2011-c-standards-meeting/

 

[Daniel Duffy]

On the 25th, in Madrid, Spain, the ISO C++ committee approved a Final Draft International Standard (FDIS) for the C++ programming language. This means that the proposed changes to the new standard so far known as C++0x are now final. The finalization of the standard itself, i.e. updating the working draft and transmitting the final draft to ITTF, is due to be completed during the summer, after which the standard is going to be published, to be known as C++ 2011. With the previous ISO C++ standard dating back to 2003 and C++0x having been for over eight years in development, the implementation of the standard is already well underway in the GCC and Visual C++ compilers. Bjarne Stroustrup, the creator of C++, maintains a handy FAQ of the new standard.

http://herbsutter.com/2011/03/25/we-have-fdis-trip-report-march-2011-c-standards-meeting/

One useful feature is Lambda expressions which simplify STL http://www.datasimfinancial.com/forum/viewtopic.php?t=380

The new syntax won't make you more productive as such; that is done by using Boost libraries.

 

[cgorac]

The new syntax won't make you more productive as such...

But in turn it will instantly make your code obfuscated...

 

[Yike Lu]

Functional constructs make your code more terse.

You type less to do the same amount of work. The tradeoff is of course that your code is harder to read. But code maintenance is still easier because what you lose in trying to understand your own code is made up for by reducing dependencies.

 

[Tsotne]

Apart from topic, which is easier to interact with SQL - C++ or C#?

 

[alain]

Apart from topic, which is easier to interact with SQL - C++ or C#?

C# by a LOT

 

[Tsotne]

C# by a LOT

Can it be considered as an advantage??? Or it is less powerful because of easy interaction? Thanks

 

[alain]

Functional constructs make your code more terse.

You type less to do the same amount of work. The tradeoff is of course that your code is harder to read. But code maintenance is still easier because what you lose in trying to understand your own code is made up for by reducing dependencies.

That sounds really nice but, IMHO, adding functional constructs to C++ felt like a square peg in a round hole. It's done already but I'm afraid, it's a disaster in the making. Hopefully I'm totally wrong.

 

[Yike Lu]

IMO it will depend on the person using it. Because of Q, my coding style now revolves a lot around functional concepts so you will see a lot of implicit loops, anonymous functions, and elided function variables. But this is a rather simple application. I'm sure there are wilder applications one can dream up of that WILL make functional constructs in C++ a disaster.

 

[Tsotne]

And new development has allowed Java and C# to perform almost as efficiently as C++ and C.

I agree. (In terms of speed...)Well written code in C# can be 90% as fast as a well written code in C++. But the thing is that, "well writing" a code in C++ is not an easy deal.

 

[Daniel Duffy]

But in turn it will instantly make your code obfuscated...

Not necessarily. As developer, you determine which features to use.

To be honest, C++ is a language for grown-ups who decide what they want. Other languages disallow such flexibility.

 

[alain]

IMO it will depend on the person using it. Because of Q, my coding style now revolves a lot around functional concepts so you will see a lot of implicit loops, anonymous functions, and elided function variables. But this is a rather simple application. I'm sure there are wilder applications one can dream up of that WILL make functional constructs in C++ a disaster.

Q is a brainfart of a language. APL, J, K, Q are all related. They are small, short languages that are very efficient and let you accomplish something really fast... as long as you are the original programmer. If a piece of Q code lands in you lap and you have to maintain it, it's hell * 10^3

 

[Yike Lu]

If a piece of Q code lands in you lap and you have to maintain it, it's hell * 10^3

That's because all those languages were made intentionally to be terse. It's true the functional style may contribute because you don't see those nice int/float/double etc declarations to tell you what i/o you have, but that's only a small component as you could always just comment your code to say what types you expect/return.