Stroustrup Reveals What's New In C++ 11

snydeq writes "Bjarne Stroustrup discusses the latest version of C++, which, although not a major overhaul, offers many small upgrades to appeal to different areas of development. From the interview: 'I like the way move semantics will simplify the way we return large data structures from functions and improve the performance of standard-library types, such as string and vector. People in high-performance areas will appreciate the massive increase in the power of constant expressions (constexpr). Users of the standard library (and some GUI libraries) will probably find lambda expressions the most prominent feature. Everybody will use smaller new features, such as auto (deduce a variable's type from its initializer) and the range-for loop, to simplify code.'"

Comments

"Not a major overhaul"?

[Godai]

I mean, it's not, but it makes it sound like C++11 is a minor update. Lambdas, auto, concurrency, are these minor updates? There's a lot of interesting stuff in C++11!

Re:"Not a major overhaul"?

[interval1066]

The biggest addition for me is a fix finally for the smart pointer class. Seems like unique_ptr was a long time in coming.

Re:"Not a major overhaul"?

[genjix]

I've been using the C++11 for 6 months now in my own project (libbitcoin) and the new features and syntax really make your code sharper, clearer and better. C++ is no longer that unsafe language if you know how to code in it properly - you never really have to do any manual memory management if you use shared pointers.

constexpr allowed me to create compile time constants that are the function of a bunch of complicated expressions. Sure, I could just put the result in the code, but by using constexpr (a far more expressive metaprogramming utility than templates) I can document where those constants came from by using code. Neat huh!

Using variadic templates, I was able to write decorators that can be applied to any function. I simply wrap my functions with this class and then its operator() will be called before calling the passed in function object (which I can define using lambdas or std::bind now :)

auto means I no longer have to type std::vector>::iterator in every for loop. Likewise for (const transaction& tx: block.transactions) is much more terse and clearer.

The new features to the standard library are brilliant. Threading has never been easier: std::thread t(foo, x, y); will call foo(x, y) in a new thread. When I decide to finish the threads and then join them I call: t.join(); ... Simple.

As libbitcoin is highly asynchronous, I don't like to use exceptions (which thread does it originate in? where does it get caught? .etc). C++11 now provides the header which defines std::error_code(). An error_code object can be tested as a boolean (to see whether the error is set or not) or compared against an enum value (which you define). They also have an error message (which if you defined the enum value it is set to, you can also set the message), and also you can group different error code values into broader categories! Really useful for asynchronous programming.

std::atomic for a thread-safe counter (useful when you have multiple thread paths executing and want to see when they all finished - increment your counter by one after each path completes) and std::atomic for a thread-safe flag. ... That's off the top of my head. There are dozens of many small things like this. C++ was always my 'native' language, but now it's truly my home.

Re:"Not a major overhaul"?

[19thNervousBreakdown]

Don't forget initializer lists, variadic templates, non-static data member initializers, finally fixing that Template> (note the >>) thing, rvalues, nullptr, strongly-typed enums, constructor improvements (holy god we don't have to rewrite every fucking thing every fucking time or split off into an ::init()), user-defined literals which is crazy cool combined with templates and initializer lists, and lots of stuff I'm sure I'm forgetting about.

Since starting on C#, I've kind of felt like I'm back in the dark ages in C++, even as it remains my favorite language. I've already started using a lot of these improvements, and while C++ still has it's rough edges, the improvement in "fun" while coding is massive. No more for (some_container_type<vector<map<int, string> > >::reverse_iterator aargh = instance.begin(); aargh != instance.end(); ++aargh) for me!

Re:"Not a major overhaul"?

[genjix]

damn my angle brackets got blanked out.

[system_error] for std::error_code

std::atomic[size_t] for thread-safe counter
std::atomic[bool] for thread-safe flag

Re:"Not a major overhaul"?

[Bill_the_Engineer]

What C++ compiler are you using?

Re:"Not a major overhaul"?

[swillden]

auto means I no longer have to type std vector iterator in every for loop

You didn't anyway. You type in "int" to loop over a vector.

Only if you want to tie yourself to using a vector. Using a proper iterator costs you nothing in code space or execution time (because for a vector it optimizes down to just pointer arithmetic anyway), but means that at some future time you can replace that vector with a different data structure without having to modify the code that operates on it.

Re:"Not a major overhaul"?

[ThatsMyNick]

For a vector both are equivalent, but for structures like "list", iterator is faster.

Re:"Not a major overhaul"?

[Anonymous Coward]

for (auto i : v) {

}

Even in terms of typing time it's a nice addition, ignoring the structure-independence benefits of this sort of thing.

Re:"Not a major overhaul"?

[Anonymous Coward]

It pretty simple why you would use iterators.
While the data you store might not change much over time, the amount of data stored for successful apps tends to grow alarmingly over time. Allowing the vector to change to some other more elegant solution when the need arises without having to rewrite large swaths of code.

Re:"Not a major overhaul"?

[Tyler Durden]

The new features to the standard library are brilliant. Threading has never been easier: std::thread t(foo, x, y); will call foo(x, y) in a new thread. When I decide to finish the threads and then join them I call: t.join(); ... Simple.

Sure. But it should be noted that this feature (along with many others brought to the new stand, I'm sure) were introduced in the Boost set of libraries first.

Re:"Not a major overhaul"?

[genjix]

> What C++ compiler are you using?

g++ 4.6 - standard in Ubuntu

Two of the features I'm waiting on are class level non-static initialisers and templated typedefs. I've heard Microsof's C++ compiler has better C++11 support but I've never tried it.

Beware that MingW has a bug so std::thread is disabled. I've heard mingw-w64 works better. You might want to also try boost::thread (same library essentially, except std::thread has move semantics).

Re:"Not a major overhaul"?

[Godai]

Heh, thanks for filling in the rest. I knew there were more, but I was just throwing down what I could remember off the top of my head. I was watching Bjarne talk about C++11 at Going Native and now I'm anxiously awaiting our (long overdue) transition to VS2010 (from 2005). I know it doesn't cover all the good stuff, but it has a lot of the goodness in there. Though, I'm writing cross platform code with a Mac team that refuses to use Clang, so God knows when I'll be allowed to use anything from C++11 :(

Re:"Not a major overhaul"?

[Anonymous Coward]

Bullshit.

Re:"Not a major overhaul"?

[DeathFromSomewhere]

Sometimes I get the feeling that my company is the only one left using VC++ 6. Our attempts at migrating get 10% completed and then abandoned when the next ultra critical super important demo/contract shows up.

Re:"Not a major overhaul"?

[loufoque]

constexpr (a far more expressive metaprogramming utility than templates)

That is incorrect.

Re:"Not a major overhaul"?

[bipbop]

std::to_string() is also disabled on MinGW. Minor, but something to be aware of.

Re:"Not a major overhaul"?

[shutdown -p now]

VC++ 2010 used to have better C++11 support than g++ for some time, but the latter has overtaken it now, and it looks like it'll keep ahead for the next release also - VC still doesn't do variadic templates, for example. It doesn't have instance field initializers, either, nor templated typedefs.

That said, C++11 support is being implemented pretty rapidly in general - I mean, we've only just got the final spec out, what, a couple months ago? and more than half of it is already supported in all major compilers.

Re:"Not a major overhaul"?

[gbjbaanb]

firstly, I wish I was using VC6 still - the IDE was the best there ever was, fast, simple, didn't flicker or use up all your RAM.

However, you can use a different IDE if you must keep the old compiler for backwards compatibility.

Alternatively, you can replace the compiler in the IDE.

Re:"Not a major overhaul"?

[afaik_ianal]

Microsoft's C++11 support in VS2010 was pretty good at the time: lambdas, auto, new function decl syntax, and that's about it.
They've really dropped the ball in VS11 though: They've basically added strongly types enums, and that's about it.

Still no word on variadic templates, template aliases or initializer lists.

Re:"Not a major overhaul"?

[91degrees]

It pretty simple why you would use iterators.

Well, we're using iterators all over the place in the rest of the code. If you're in an iterator mindset, It's nice to keep using the same idiom.

Re:"Not a major overhaul"?

[martin-boundary]

C++ has always been about performance and low level control. However, having higher level constructs in addition is a good thing.

Take goto, which is all that's really needed for modern programming. Using goto, you can implement subroutines (gosub like functions), while and for loops, etc. But each time you implement one of the higher constructs, your implementation will be slightly different. And if you force yourself to use the optimal implementation all the time, you'll just be writing a lot of boiler plate code. So having functions and while loops implemented as language constructs is a good thing. Similarly, std::thread + lambdas is a great addition.

Re:"Not a major overhaul"?

[shutdown -p now]

Atomic is in VC11 dev preview (changelog).

Sadly, still no variadic templates.

Re:"Not a major overhaul"?

[martin-boundary]

One thing I think I don't like is return types after the function definition. It seems too artificial, when they could have just changed the scoping rules slightly and kept the return type before the function prototype.

Re:"Not a major overhaul"?

[cheekyboy]

So, just the same as

foreach(i in v)

in other 4GL langs for how many years ?.

Re:"Not a major overhaul"?

[superwiz]

No more for (some_container_type > >::reverse_iterator aargh = instance.begin(); aargh != instance.end(); ++aargh) for me!

What's worse is one of the intermediate containing types changes. You then have to go and hunt through the rest of the code to see where it changed. Yeah, until containers knew their contained type (and could declare an iterator over their contained type), they really should have been called pseudo-containers. The problems, however, is that the language has been so slow to get fully implemented, that it's driving people away from the adaption. I think half of the C++ projects out there are delayed in starting up just because there is no full C++11 compiler to use.

Re:"Not a major overhaul"?

[QuasiEvil]

Holy shit - we finally get strongly-typed enums? Finally. No, I'm not the type to RTFA. :)

Re:"Not a major overhaul"?

[RCL]

Bullshit is what we have now: when "managed code" ends up being run as JIT-compiled chunks that lie scattered throughout the whole memory and make CPU instruction cache the bottleneck, when memory is accessed through chain of pointers, when people don't even know the memory layout of data they are using... let alone care about temporal and spatial locality when accessing it...

But "the free lunch is over" and single-threaded CPU performance hit a glass ceiling in like 2004, so we are slowly going "back to the roots" for single-threaded code - not every algorithm has, or will ever have, a nice/easy parallel version, so new processors won't help much.

Re:"Not a major overhaul"?

[jgrahn]

For a vector both are equivalent, but for structures like "list", iterator is faster.

Faster than what? There is no indexing of std::list. (You could write one, I suppose, but that would make iterating a list O(N^2).

Re:"Not a major overhaul"?

[jgrahn]

auto means I no longer have to type std vector iterator in every for loop

You didn't anyway. You type in "int" to loop over a vector.

Only if you want to tie yourself to using a vector. Using a proper iterator costs you nothing in code space or execution time (because for a vector it optimizes down to just pointer arithmetic anyway), but means that at some future time you can replace that vector with a different data structure without having to modify the code that operates on it.

That is *one* reason, I suppose. A more important one is that you use iterators everywhere else in C++. When you're used to that, throwing in a loop for(int i=0; iN; i++) looks odd.

Re:"Not a major overhaul"?

[jgrahn]

I've been using the C++11 for 6 months now in my own project (libbitcoin) and the new features and syntax really make your code sharper, clearer and better. C++ is no longer that unsafe language if you know how to code in it properly - you never really have to do any manual memory management if you use shared pointers.

Fine, but (a) you don't need C++11 to have shared pointers -- it just standardizes them; (b) shared pointers are *not* the primary way to avoid manual memory management -- that would be the standard containers.

Re:"Not a major overhaul"?

[jgrahn]

I think half of the C++ projects out there are delayed in starting up just because there is no full C++11 compiler to use.

That would be stupid if it was true, because C++11 is not really a world-changing thing (unless you're deep into template meta-programming, which most people shouldn't be).

The compiler situation is much better today than when C++ was first standardized in the late 1990s: the GCC crowd has their shit together, and Microsoft are on the bus again.

Re:"Not a major overhaul"?

[CapOblivious2010]

Sometimes I get the feeling that my company is the only one left using VC++ 6.

Is your company hiring? I'd love to use VC6 again - it was faster, more stable, and much easier to use than the recent crap MS has been extruding. VC2008 and 2010 have so many god-awful misfeatures that make simple things needlessly complicated, it's amazing anything useful can ever get done with them.

Re:"Not a major overhaul"?

[VertigoAce]

Slide 5 of the deck here says that initializer lists, template aliases, variadic templates, and other features are coming in a series of out of band releases after VC11 RTM (but sooner than the next major release of VC). That slide also lists the stdlib and language features that are included in VC11 Beta/RTM.

Re:"Not a major overhaul"?

[swillden]

Except in the real world you'll need to modify some of the code that operates on the data structure when you change it anyway

Sometimes yes, sometimes no. You can't know that up front. Maybe you later find that some other piece of code that operates on the structure needs to insert elements near the beginning, and it's big enough and happens enough that the cost matters. So you swap it out for a list, or a deque. Or maybe it becomes more convenient to manage the data on disk, and you replace the vector with a custom disk-based vector class, or maybe an mmap'd flat array with a trivial wrapper (about all you have to implement is begin() and end() and have them return raw pointers).

it's better to just hammer out a quick "for int i = 0; i thing.size(); i++" than dick around with iterator and const_iterator vs. const iterator and so forth

Being able to use const iterators is another advantage, not a cost. It helps you -- and more importantly whoever comes after you -- to know at a glance that the loop doesn't modify the contents. It's compiler-enforced documentation. Even when I'm using raw arrays (rare, but it happens), I still use constant pointers and iterator notation just for that purpose. E.g.: for (const int* iter = array; iter

I mean who says you'll even be changing the structure anyway? Why are you spending time now on something that probably won't even happen?

Why would you think it takes any more time to do it right than to hack it with an int index? As another poster commented, with the new loop syntax and auto, it's actually less typing to use the iterator, but even if it's not, clarity of expression, future-proofing and defense against inadvertent errors are far more important than the time it takes to type a few extra characters. If your typing speed is limiting your coding output, it's not because you type too slowly, it's because your code is poorly written.

Re:"Not a major overhaul"?

[swillden]

Doh!

The code snippet should have been:

for (const int* iter = array; iter < array + array_size; ++iter) { /* ... */ }

Re:"Not a major overhaul"?

[ThatsMyNick]

My bad, I was expecting some of equivalent of get() in Java's LinkedList. I suppose C++ does not have one.

Re:"Not a major overhaul"?

[superwiz]

It's not stupid. Most estimates show that the average code size of a C++11 coded program is half the size of a C++ program. And they are much more readable. It is patently silly to commit resources to long-term projects which can be written in half the time if they are started 2-3 years down the line.

Re:"Not a major overhaul"?

[martin-boundary]

That's not a new problem, is it? For example, the template qualifier is already necessary in template code when an expression like T.x(3) occurs. Does that refer to a template method x of class T invoked with the value 3, or is it a member variable T.x compared with the value of variable y, which is then compared with the integer 3?

Although come to think of it, that's pretty damn ugly too :(

Re:"Not a major overhaul"?

[Tyler Durden]

Umm. Why the fuck was I modded "Overrated"? Just giving credit where credit is due for a feature that has been available from before it became part of the standard.

Re:"Not a major overhaul"?

[Chrisq]

C++ is no longer that unsafe language if you know how to code in it properly

That was also true. I haven't used c++ 11 in anger, but I think what you mean is that the rules about how to write a safe c++ program are greatly simplified. Have I got it right?

Re:"Not a major overhaul"?

[sonamchauhan]

And that is ironic

Re:"Not a major overhaul"?

[loufoque]

That's not what irony is.

Re:"Not a major overhaul"?

[msclrhd]

Except you are starting on container C and ending on container c -- boom!

    for (auto value : c) { /* ... */ }

is a lot cleaner and more reliable (auto& if you want to modify the value).

Also, you can now do:

      int a[] = {6, 4, 9, 2, 5, 8, 3};
      sort(begin(a), end(a));

Even things like:

      std::string lookup_value(const std::map<std::string, std::string> &items, std::string value) {
            auto match = items.find(value);
            return (match != items.end()) ? match->first : std::string();
      }

No ugly template expressions to be found.

Re:"Not a major overhaul"?

[TheRaven64]

Most estimates show that the average code size of a C++11 coded program is half the size of a C++ program

Who is making these estimates? I've been playing with C++11 for a bit (and implemented some parts) and I'd be very surprised to see more than a 10% reduction in size. Unless we're talking about very small projects and counting Boost towards their total code count...

Re:"Not a major overhaul"?

[TarMil]

If your point is that C++11 arrives late, well, I think everyone knows that. But it's still much better than the previous standard.

Re:"Not a major overhaul"?

[superwiz]

There is no compiler which implements all the new syntax just yet -- not even all the syntactic sugar. So I'd be curious to know how you've been playing with C++11.

Re:"Not a major overhaul"?

[swamp boy]

Like operator[]?

std::vector<int> myNumbers;
myNumbers.push_back(1);
myNumbers.push_back(2);
myNumbers.push_back(3);

int theValueTwo = myNumbers[1];

Re:"Not a major overhaul"?

[TheRaven64]

I work on a C++ compiler, and I've been playing with the features as they're implemented. Which doesn't answer my question: who is making these '50% code reduction' claims. Nothing I've seen in C++11 makes me think them at all credible.

Re:"Not a major overhaul"?

[anonymov]

You don't need "all the new syntax" to start using C++11, many of most useful additions are already in all major compilers and have been there since the times when C++11 was known as C++0x and C++ TR1. Current GCC is missing only a few features.

Re:"Not a major overhaul"?

[Imagix]

Hmm.. replacing all of those extra functor objects that you had to pass to algorithms with lambdas will drastically reduce those pieces of code. Not sure about 50% overall...

Re:"Not a major overhaul"?

[superwiz]

TR1 was removed from C++11.

Re:"Not a major overhaul"?

[superwiz]

That's only part of the "prepare to jump to hyperspeed" before jumping to hyperspeed. Without the new use of the 'auto' keyword, every for loop requires either multiple lines loop header or a typedef right before the loop. The auto keyword reduces it to 1 short line. The copy semantics actually reduce the code necessary to return containers. Oh, and the new tuples make all the gymnastics surrounding returning of lists of heterogeneous values from functions a syntactic no-brainer. But I don't think any compiler implements the initializer lists yet. That would be another step in reducing the code foot print.

Re:"Not a major overhaul"?

[19thNervousBreakdown]

*facepalm* .rbegin()/.rend()

And yeah, strange as it might be, not having to write redundant stuff actually makes it easier to read/write code. It's less that you have to keep in working memory.

Re:"Not a major overhaul"?

[SerpentMage]

So I am following this thread and can't stop but think, "this is why I think C++ is a POS!"

I used to be a C++ programmer. However, with Java, C#, Python, Ruby, or Javascript I don't get into long winded debates on how to allocated a fucken string! It is a fucken string for god's sake! Not the Taj Mahal.

And talking about performance? With very well tuned C# I have gotten to about 90% of C++ as coded with std, etc. Granted C++ without all of the extras like std smokes C#, but then again you are back to the bad old problems of memory dumps.

Re:"Not a major overhaul"?

[aiht]

They meant no operator[] in std::list<>

Re:"Not a major overhaul"?

[benhattman]

I sure hope you meant size_t.

Re:"Not a major overhaul"?

[afaik_ianal]

Thanks for the links! I was really concerned MS were going to drop the ball.

I want auto!

[boaworm]

Unfortunately I code in java these days.. chances that oracle will see the light? :-)

Re:I want auto!

[Anonymous Coward]

Unfortunately I code in java these days.. chances that oracle will see the light? :-)

Really? When I implemented our code guidelines, one of the rules is prohibiting the use of 'var', c#'s version of auto.

I don't ever want to look at code and wonder, "what type is this variable?" You're trading off the convenience of coding it without having to look up the data type name for making it more difficult to maintain. Anytime I have a choice between maintainability and ease of coding it the first time, maintainability wins.

Re:I want auto!

[DeathFromSomewhere]

Don't wonder, hover your mouse cursor over the variable and behold the glory of tooltips.

Now what happens when you change the name of a return type from a commonly used function? Have fun with your maintenance nightmare. If you are lucky the compiler will complain, if you are unlucky you break existing code without knowing it.

Re:I want auto!

[SpryGuy]

Prohibiting use of "var" is gross over-kill.

There are times where it's use is not recommended, certainly. But even in those cases, it can lead you to the point that there's a "bad code smell" where methods aren't named well, variables aren't named well, classes aren't named well.

var x = foo(); is definitely less readable.

But var x = new ComplexObject(); is every bit as readable, if not more so, because you don't have a redundant "ComplexObject" in the declaration. You always know exactly what type "x" is. It's also very useful in cases where the return type is a complicated generic. it saves a lot of typing, and is definitely more readable.

Here is a very good discussion on the benefits and uses of "var":

http://resharper.blogspot.com/2008/03/varification-using-implicitly-typed.html

Re:I want auto!

[Anonymous Coward]

Try that in the Entity Framework without writing inefficient code (i.e. selecting all columns). Sometimes you need anonymous types and those require var if you need an object reference. Language features are implemented for a reason.

Re:I want auto!

[Anonymous Coward]

I agree, and always trend towards making code as explicit as possible. If you know the type, declare the type. I still prefer hungarian notation, while we're at it, especially in math-heavy routines. It makes casting and truncation errors just pop out at you.

var is necessary for anonymous types and LINQ, which IMHO, are a godsend in the viewmodel/presentation/controller layer. It's often a waste of effort to construct concrete classes to hold a bunch of display strings, just to wrap then in JSON and shove them off to a world of javascript that doesn't appreciate all those hand-written getters and setters.

Re:I want auto!

[Anonymous Coward]

Don't wonder, hover your mouse cursor over the variable and behold the glory of tooltips.

I also don't ever want to use my mouse.

Re:I want auto!

[smelch]

Uh, you put the cursor on the type name, press ctrl+r+r and type the new name. Or you click the tickle and choose the rename option after you change the name. Are you just assuming that everybody uses var everywhere?

Re:I want auto!

[Anrego]

In general I agree.. but for some stuff (iterating through a collection for instance) I think it is acceptable. When you start dealing with collections of collections, iterator types become a nightmare!

in Java of course you can just use the foreach syntax (Kitten kitten : kittens).

Re:I want auto!

[godrik]

chances that oracle will see the light? :-)

Last time they saw the Sun, it did not end well...

Re:I want auto!

[WARM3CH]

I don't agree. auto (or var) very rarely hide any information which is not immediately visible. For example there are trivial cases where auto (or var) just save extra typing:

var my_object = new my_class();
v.s.
my_class my_object = new my_class();

Here using var just saves a few key struck (or a lot, in case my_class happens to be a type with a particularly long name). In any case the type of my_object is perfectly known and quite visible so I think using auto is just fine.
There are however cases that a complex type is used while we actually DO NOT care for the type per se. For example in C++ consider the case for a lambda function:

auto my_fun = [](int i) { return i * i; };

Here I actually don't care about the exact type of my_fun. All I care is that it take an int and returns an int which I can see clearly. Finally, another case could be situations in template programming where insanely complex types are used/generated and we don't want to (or even cannot) type them again and again. Also I guess in Java or C# you might get away by cheating and using an object (I hate it when people do that!) but we don't have that luxury in C++.

Re:I want auto!

[DeathFromSomewhere]

This is a C++ thread. We don't have the fancy refactoring tools that C# has.

Re:I want auto!

[TheSkepticalOptimist]

Seriously get a better IDE if you think using var is confusing.

var saves me from having to do this:

Dictionary, AnotherClass myCollection = new Dictionary, AnotherClass();

instead I can go:

var myCollection = new Dictionary, AnotherClass();

which is significantly more readable and removes redundant overhead of typing a type twice. And if you can't figure out what type it is, you should change your profession.

or even better:

var collection = someclass.ACollection;

without having to explicitly know what type ACollection is (i.e. having to hunt through code to copy and paste the type ACollection is defined as).

this is particularly helpful using Linq such as:

var results =
results.ForEach( r => do something );

Which in the Linq world is good because often the generated results is some complex generics collection that would be very difficult to know what exact explicit type the results generate.

Lastly, what if the type changes and you don't have a decent IDE that refactors for you, now suddenly ALL your explicit types with throw compile errors and there is a measurable amount of time required for a developer to "maintain" the code.

Sorry, but var is not difficult to understand how to use properly and if I worked for you I would shove your "guidelines" somewhere unpleasant because generally guidelines are written by people who do not know better.

BTW, generally these days language features are not added if there is a question of poor code maintainability. Generally speaking, people more knowledgeable then you have figure out that "var" saves time, improves efficiency, and results in more maintainable code the those that do not understand how to use var realize.

Re:I want auto!

[91degrees]

Do I take it then, that you don't use stl that much?

Here's a construct that I used today:

map<string, vector<string> >

If I want to iterate through this, I need to create a variable of type

map<string, vector<string> >::const_iterator

. Since I'm not totally sure of the exact type of my map, I need to find out where it's declared and copy that. If I then change that vector to a list, I need to change every iterator that uses that. Okay, I should probably use a typedef, but since I'm going to be using it in a statement along the lines of

for(auto it = my_map.begin(); it != my_map.end(); ++it)
{
print(it->key());
}

It should be pretty obvious from context what the type is. We know begin() returns an iterator.

Can see this being useful inside templates as well, and for splitting up complex calculations.

Re:I want auto!

[Daniel Phillips]

chances that oracle will see the light?

Roughly the same as the chance that Larry Ellison will fly his MiG 25 straight into the side of a mountain.

Re:I want auto!

[19thNervousBreakdown]

Because var still works within the type system and gives you compile-time errors, and casting to object is a massive sledgehammer that delays errors until runtime (with all of runtime error checking's glory, like only failing some of the time, which you can basically read as "never on a developer's machine, sometimes on TQA's machine, and always on a customer's machine (unless support is on the phone with them)"), and a stupid idea in general (I'm looking at you, Objective-C!).

Re:I want auto!

[19thNervousBreakdown]

(object) ~= (void*)

I mean that in spirit, not in actual details. Yes, I know there's about a billion, trillion ways they're different.

Re:I want auto!

[smelch]

Well, in my defense the GP to my comment was referring to var in C#, so I responded with how I would handle a situation of renaming the type in C#.

Re:I want auto!

[busyqth]

Masterful comment!
I can't tell if it's serious or just trolling.

Re:I want auto!

[Xrikcus]

Auto in K&R was a storage class, not a request for compiler type inference.

Re:I want auto!

[aztracker1]

Let's just hope he doesn't have to deal with simple LINQ expressions using an anonymous object... oh yeah, no anonymous object types... too unpredictable, even when closer to the UI layer.

Re:I want auto!

[gbjbaanb]

Then simply prepend the type identifier to the variable name, simples!

Or, if you don't do this, you can use the IDE's ability to tell you the type by hovering over the variable. In which case, it really doesn't matter if you declare it using var or not.,

Re:I want auto!

[19thNervousBreakdown]

It gives you some of the benefits of duck typing with very few of its drawbacks, and the reduced noise makes your code clearer. I know that seems counter-intuitive to you right now, but if you try it, you'll see the benefits, and realize that the type names appearing next to the declarations is, in most cases, redundant or irrelevant when it comes to actually understanding what the code does.

It's more of a fuzzy thing, but I started using it at my job, everybody hated it for two weeks, I gave no fucks and kept using it, now everybody uses it.

Re:I want auto!

[c 0xFF]

However, take a look at clang. One day, this and much more will be possible.

Re:I want auto!

[c 0xFF]

in Java of course you can just use the foreach syntax (Kitten kitten : kittens).

Which is also a C++11 feature, now. Except they call it a "range-based for loop."

for ( Kitten& kitten : kittens )

Using a reference is optional, I think, but is probably the better way to go in the general case (so you can modify the object instead of a copy).

Re:I want auto!

[shutdown -p now]

if its just the same function, build the properties for the anonymous type before initializing the anonymous type.

Can you explain what you mean by this?

You can't pass an anonymous type to another function as its type

Actually, you can, if that function is generic. It's why you can pass an IEnumerable of anon type objects to something like .Where(), and access properties on that object without any casting within the lambda that you also pass.

Re:I want auto!

[c 0xFF]

And also completely redundant (every local variable is an auto variable unless declared differently), and thus completely useless and never used.

I think it's wonderful they managed to re-purpose a dead keyword into something wonderfully useful, and the name even fits so well.

Re:I want auto!

[shutdown -p now]

"auto" was always implemented, since the very first version of C, it just had a different meaning - it means that variable has an "automatic storage class" (as opposed to "static storage class" etc). Because automatic was the default, it was almost always redundant, but it did have a meaning.

It actually goes way back to B, which only had a single data type - machine word. Variable declarations looked somewhat like C, but, for the lack of type, they started with the storage class instead, i.e.:

main() {
  extern x;
  static y = 1;
  auto z = 2;
...
}

In C, we've got types, so you'd normally write "static int y" for a static local, and just "int z" for an automatic one - "auto" being implied. However, C inherited some of B's semantics as "default int" - i.e. if the declaration is clearly a variable, but it omits the type, assume that type to be "int" (i.e. machine word). So in C the above code snippet from B is actually valid, and declares x, y and z to all be ints.

Then "auto" got inherited by C++, which dropped the "default int", making auto completely redundant - you couldn't write "auto x" in C++ anymore, and in all other cases where you could use "auto", like "auto int x = 123", it was always redundant. So when they appropriated it for type inference in C++11, it was technically a breaking change - it just wasn't ever used by anyone in production code in the old way, so nobody noticed.

Re:I want auto!

[RightSaidFred99]

Exactly. I even use it in the var x = foo() case, but that's because much like the honey badger I just don't give a shit. ctrl-space and hover over tells me everything I need to know.

Re:I want auto!

[JonySuede]

Have a look at that :Netbeans, the platform that is the base for the renamed Sun Studio, now know as Oracle Solaris Studio, is a such a tool.

Re:I want auto!

[Anonymous Coward]

There are some things using linq where the only option is to use a var.

List list = new List();
var q = from n in list where n.Length > 0 && n.StartsWith("bob") select new { Content = n, Length = n.Length };

foreach (var n in q)
        Console.WriteLine("Content: " + n.Content + ", Length:" + n.Length);

So the Q type above is of type: System.Linq.Enumerable.WhereSelectListIteratorf__AnonymousType0>.

Also like others pointed out var is completely type safe just like it is in c++

I personally find the first example below to just as readable as the other two and less to type. If I end up changing out for a reverse iterator or something like that I don't have to change type type.

for(auto it = col.begin(); col.end(); ++it){};
for(StringCollection::iterator it = col.begin(); col.end(); ++it){};
for(std::vector::iterator it = col.begin(); col.end(); ++it){};

Re:I want auto!

[superwiz]

For anything but the highest performance computing, Java gives the same performance. In fact, for service code, Java gives better performance. I've benchmarked a prime sieve with the same algorithm in Java, and C++ (with and without the -g flag). It's a good test of integer arithmetic+basic language performance because the compiler cannot optimize away loops. Java is only 5% slower than stripped C++. Java is significantly faster than C++ with the -g flag. But Java actually retains all the symbol and frame information. So, in case of a crash, you often have even more to go on than you would in C++ with -g.

Re:I want auto!

[petermgreen]

Afaict you can write fast efficient code in java but to do so you have to fight the language due to it's lack of parameter pass by reference and the implicit pointer in all it's compound types.

Suppose you have a function that returns a complex number, in a sane language you'd just have a complex type which could live on the stack and return it or pass it by reference/pointer. In java to avoid a heap allocation with every call you have to make arrangements to have a relatively long lived object that stores the complex number maintained by code in the parent.

Suppose you want an array of complex numbers, in a sane language you'd just declare an array of the aforementioned complex number type which could live in a single block of memory. In Java you would have to either use two paralell arrays or have a pointer to an object for every entry in the array.

Re:I want auto!

[Imagix]

That should be spelled: for (auto & kitten : kittens)

Re:I want auto!

[DuckDodgers]

Java is painfully verbose, and I think a lot of the use of auto would save typing without losing readability.
auto x = new Customer(); // versus Customer x = new Customer();
List<Customer> customers = // initialize it somehow
for (auto x : customers) { ... } // versus (for Customer x : customers) { ... }

Reading the declaration should be child's play.

Re:I want auto!

[cerberusss]

in Java of course you can just use the foreach syntax (Kitten kitten : kittens).

Also, Java has Garbage Collection, which gets rid of those kittens everywhere.

Re:I want auto!

[msclrhd]

Kitten& is fine if you have non-virtual kittens :D. The use of auto (or auto&) is independent of using the range-based for.

Re:I want auto!

[The Askylist]

So you only have to use auto for Schrodinger's kittens?

Re:I want auto!

[TheRaven64]

The poor craftsman blames the tools.

The good craftsman picked decent tools before he started.

Re:I want auto!

[TheRaven64]

Java is only 5% slower than stripped C++. Java is significantly faster than C++ with the -g flag.

Umm, what? -g / stripping just determines whether the DWARF metadata is in the binary. If you are not running the code in a debugger, then this data just sits on disk and is never touched. If you're on OS X, it's not even in the same file as the executable code by default. If you're finding that it's making a noticeable difference to performance, then you should consider that your benchmarks are being done poorly.

If, on the other hand, you are talking about -O0 (which is usually added with -g), then this can make a huge difference to C++ performance. C++ optimisations are usually pretty destructive towards debugging info, and the difference between unoptimised and optimised C++ is usually at least 50%. Again, if you're not seeing a big difference between a debug and an optimised build, then you're doing it wrong.

Re:I want auto!

[smellotron]

You are mistaking debugging information with optimization levels. It's unlikely that you had a legitimate comparison. For starters, what compiler/version did you use? What other options besides -g were used? What hardware was used?

Re:I want auto!

[spongman]

huh? how do you access the derived members of object?

        object foo = new { x = 1 };
        use(foo.x); // error
        var bar = new { x = 1 };
        use(bar.x);

Re:I want auto!

[superwiz]

It doesn't matter. You can't unroll the loops on this one. So even the basic optimization cannot be done. The whole thing was done in 1 function, so no inlining would help either. I was using gcc 4.5.1. The hardware should be irrelevant. I ran both the java version and the g++ version on the same box under the same operating system. The Java version was 6_26. Both gcc and Java were 64-bit versions.

Re:I want auto!

[smellotron]

It doesn't matter.

Speaking as someone who regularly looks at the assembler output of gcc, it sure as heck does.

You can't unroll the loops on this one. So even the basic optimization cannot be done.

Loop unrolling doesn't happen until -O3, and even then it's not a clear-cut optimization because it bloats the instruction stream and potentially confuses the hardware branch predictors (which are—as one might expect—optimized for loops). There are plenty of other optimization passes that the compiler can go through. To name a few:

• tail recursion to eliminate stack growth
• better register allocation to reduce (or eliminate) stack usage
• static branch prediction to reduce the likelihood stalls from conditionals
• instruction reordering to reduce the impact of stalls from conditionals or execution-unit bandwidth

The hardware should be irrelevant. I ran both the java version and the g++ version on the same box under the same operating system.

GCC by default targets the generic architecture (there's a way to tell if the version you're using targets something else, but sorry, I forget at the moment). This means it won't use any of the newer x86 or x86_64 instructions. It also limits the compiler's knowledge about instruction latencies, and branch penalties, and the cache hierarchy. It is likely that you penalized the C++ version simply because Java is designed to abstract these details into the jvm itself.

If you're kind (and organized) enough to be able to provide me with the original code and command-line arguments, I can take a crack at some basic compiler-flag tweaking and get back to you about experimental difference.

Re:I want auto!

[superwiz]

// findPrimes6 gets called N number of times with some large parameter (say 20 million)

#define CONSIDER_NUMBER(last,ringSize,position) \
        isPrime = true; \
        for (int i=0;i<=position;++i) \
        { \
            divisers_considered++;\
            if (primesSquaredArr[i] > last) \
                break; \
            if (last % primesArr[i] == 0) \
            { \
                isPrime = false; \
                break; \
            } \
        } \
        if (isPrime){ \
            primesSquaredArr[position]=last*last;\
            primesArr[position++]=last;\
        } \
        last += ringSize; \
        numbers_considered++;

template<typename prime_type>
void findPrimes6(const int count)
{
    std::cout<<"findPrimes6"<<std::endl;
    std::vector<prime_type> primesVec(count+1);
    prime_type * primesArr = primesVec.data();
    primesArr[0]=prime_type(2);
    primesArr[1]=prime_type(3);
    std::vector<prime_type> primesSquaredVec(count+1);
    prime_type * primesSquaredArr = primesSquaredVec.data();
    primesSquaredArr[0]=prime_type(4);
    primesSquaredArr[1]=prime_type(9);
    register prime_type last1=7;
    register prime_type last5=5;

    register int numbers_considered=0;
    register int divisers_considered=0;
    register int pos=2;
    while(pos <count)
    {
        bool isPrime;
        CONSIDER_NUMBER(last5,6,pos)
        CONSIDER_NUMBER(last1,6,pos)
    }
    /*for (int i=0;i<primesArr.size();++i)
    {
        std::cout<<"prime # "<<i<<" is "<<primesArr[i]<<std::endl;
    }*/
    std::cout<<"last prime is "<<primesArr[count-1]<<std::endl;
    std::cout<<"numbers considered: "<<numbers_considered<<std::endl;
    std::cout<<"divisers considered: "<<divisers_considered<<std::endl;
}

Re:I want auto!

[smellotron]

I compiled two versions using gcc-4.4 on an Intel i7 chipset (this version actually targets core2 instruction latencies, but it's close enough for my purpose). Compile/link lines:

g++ findprimes.cxx -o findprimes0 -m64 -march=native -mtune=generic -O0
g++ findprimes.cxx -o findprimes3 -m64 -march=native -mtune=native -O3

There are only a few salient differences in the optimized build: the first is a smaller stack size (0x8 bytes instead of 0x88). This probably doesn't have much impact on caching (there aren't many function calls, and none in the critical path), but it does mean that more variables are going through unnecessary load/store cycles. The second is that the optimized build issued roughly half of the function calls. Any functions in the computation kernel count as trimmable fat. The final difference is that the native-tuned build frequently used conditional-move operations. This reduces pressure on branch prediction hardware.

I benchmarked both using a single series of calls in the sequence 1, 2, 5, 10, 20, 50, 100, 200, 500, ..., 5000000. Due to impatience I did not go all the way out to 20M as you suggest, but the results to 5M already show a smooth geometric scale that I expect would continue until I run out of main memory. I used getrusage() to track various runtime statistics and saw the following:

common: physical memory (maxrss) 77K, page faults (minflt) 35K

findprimes0: cpu time (utime) ~72 seconds, involuntary context switches (nivcsw) ~80.

findprimes3: utime ~50 seconds, nivcsv ~60.

Overall, I hope that this convinces you that compiler optimization flags matter across the board for C++. I believe this is one of the downsides of C and C++ as a mainstream application language: optimization for the target runtime environment is required by application developers. That being said, this problem is very light on the CPU and very heavy on memory bandwidth, so I suspect that any implementation could be optimized substantially by parallelizing the sieve checks. Consider that for any given value N above some small absolute value, it should be guaranteed that N-1, N-2, ..., N-K are all relatively prime. Thus, the algorithm should be able to batch-process chunks of N values against the list of existing primes in parallel. This is essentially a manual loop-unrolling, but it relies on information that we only know from mathematical proof (i.e. no modern compiler or runtime could be expected to perform this optimization automatically).

Re:I want auto!

[benhattman]

Prohibiting use of "var" is gross over-kill.

Gross overkill is, of course, the main point of most coding standards.

Re:News?

[busyqth]

That said, as a professional C++ developer working in HPC, this is exciting.

Stop pretending and get back to your FORTRAN!

Nothing to see

[Jorl17]

Small interview, not anything new is added. Trolls will enjoy the old Java versus C++ thing again.

Seriously, a big disappointment.

and in the next revision...

[busyqth]

S-expressions, continuations, hygenic macros...

In practice it's like a different language.

[Anonymous Coward]

Many developers are still using C++ as "C with classes".

Re:In practice it's like a different language.

[Roachie]

Wait, there is an object oriented version of C?

Theses are days of miracle and wonder.

Re:In practice it's like a different language.

[DeathFromSomewhere]

C with classes is a derogatory term used to describe programmers and code which wraps C-style code and various bad practices with classes. You end up with things like custom string and array classes, using memcpy instead of std::copy, printf instead of std::cout, FILE* instead of std::fstream, copy paste instead of inheritance and void* everywhere.

Re:In practice it's like a different language.

[tibit]

Now be careful, because inheritance was not really intended for code reuse. If it does help with code reuse, that's a positive consequence, but it's not what inheritance is for, first and foremost. See Liskov substitution principle and all that jazz.

Re:In practice it's like a different language.

[Alex Belits]

The practices you have listed are actually good C++ programming (except "custom string and array classes", whatever that means). Just because there is a bad library bundled with the language, it does not mean that everyone must prefer it over the native libc, it is useful only when it fits the purpose of the program.

Re:In practice it's like a different language.

[tibman]

I still prefer printf to cout. Though php's echo is better than both, which is sad.

Re:In practice it's like a different language.

[DeathFromSomewhere]

Let me be a bit more descriptive. The code that I was referring to is a switch statement that branches on a hacky enum in order to cast a pointer down an inheritance hierarchy and perform the same calculation on a series of different types. The difference between the branches is literally what pointer type the base pointer gets casted to.

class A
{
public:
enum Type
{
TYPE_A, TYPE_B, TYPE_C
} mType;
void Foo ();
};

class B : public A
{
void Foo ();
};

class C : public A
{
void Foo ();
};

A * pA = GetA ();
switch (pA->mType)
{
case A::TYPE_A:
pA->Foo ();
break;

case A::TYPE_B:
((B*)pA)->Foo ();
break;

case A::TYPE_C:
((C*)pA)->Foo ();
break;
}


Maybe I'm projecting my frustration and this type of horrible hack is nowhere near as common as I think it is.

Re:In practice it's like a different language.

[jythie]

I would go further and say it has become a derogatory term of using C++ in anyway way other then the most current stylistic fad... not just doing things the OPP way but doing it the current C++ OOP way.

Re:In practice it's like a different language.

[jythie]

You just listed one of memcpy's best features ^_^

Many still feel that operator overloading should never have been included in the language in the first place.

Re:In practice it's like a different language.

[cheekyboy]

Maybe because pure C++ with all its advances looks worse than random perl code or assembly.

Im not asking for cobol like scheme, but come on, enough of the !@#$%^&*(){}|} magic

Re:In practice it's like a different language.

[RCL]

So what? STL isn't suited for all possible uses, sometimes you need your own string and container classes.

Don't be a zealot, pragmatic programmer should find the right trade-off between reusing code and writing an optimal one for a specific problem/area. Nothing can be optimal in all cases - sometimes you need to be as close to hardware as possible at the expense of unreadable/inflexible code (for me, those are the most interesting and challenging areas), and sometimes you only care about maintainability of your code by a disposable programming drone.

Re:In practice it's like a different language.

[RCL]

As if those were the worst problems. And allocating memory dynamically fragments it. Ever tried writing custom allocators for STL to avoid dynamic memory allocations (or do them thru your own memory manager)? Good luck and hope you are tolerant to rectal pain.

Re:In practice it's like a different language.

[QuasiEvil]

>Time to join the 21st century grandpa. FILE* leaks.

Hell no. And get off my lawn.

printf() isn't typesafe, but it's a fuckton more readable than all that cout formatting stuff. Also, the fact that it's not typesafe isn't really an issue if you don't suck - trivial unit testing will pretty much show any problems immediately. Besides, gcc/g++ is nice enough to warn you about egregious ones now.

FILE* leaks? I assume by this you mean when sloppy programmers fail to close their files and you start burning through file descriptors. Sounds like a bug to me, and again, stop sucking. Or do what we do - throw an object with a destructor containing fclose() around it. Then you get all the awesomeness of of FILE* (including those awesome formatting commands like fprintf and fscanf) without the danger of your file staying open when something goes nuts.

Why on earth would you want memcpy() to call anything? It's a low level byte move. Anybody with five minutes of familiarity with it should know that. If you wanted something different, use the assignment operator.

void* have all sorts of applications, most recently to me in writing architecture neutral VMs where really all the native machine knows is that it's moving around some sort of pointer.

Now the custom string and array classes? That I'll agree on. Troll on.

Re:In practice it's like a different language.

[jgrahn]

So what?

I think he simply claimed that you have to deal with C++ written by C programmers all too often. That's my experience, too.

STL isn't suited for all possible uses, sometimes you need your own string and container classes.

I don't see what that has to do with the above. I suppose there are some rare cases where the standard library isn't appropriate, but are you arguing this is an excuse *never* to use it?

By the way, your reference seems severely dated. Some of its complaints are still valid, but seem based on the state of STL support ten years ago.

Re:In practice it's like a different language.

[RCL]

I think he simply claimed that you have to deal with C++ written by C programmers all too often. That's my experience, too.

I'm probably one of those C programmers. I use C++ features when I feel they are appropriate, but my definition of "the right thing" changed over years. I started to value custom-tailored solutions, often hardware- and problem-specific. No longer I'm trying to find (or create) code that would fit all (or even the most) cases, and micro-managed security is of lesser concern to me.

I don't see what that has to do with the above. I suppose there are some rare cases where the standard library isn't appropriate, but are you arguing this is an excuse *never* to use it?

There are always multiple tradeoffs involved, that's why I am very wary of saying "never". STL is no silver bullet, this is what I'm saying.

E.g. STL is bad at managing memory, it's hard to make it NOT allocate it dynamically - yes, you can write a custom allocator for it, but STL allocators are inflexible and also - for some poorly thought reason - manage object construction, not just memory allocation, making this unnecessarily hard. STL is a template library, and templates produce separate implementation for every type used - whereas you can have a single void *-based container for all your POD types, with templates providing just minimal wrapper. Also, STL makes it hard for you to control how often memory (object instances) is copied - there's no way to influence its behavior if memory copying tops your profiler results.

If you are developing primarily for desktop computers which are quite beefy (and also vague in terms of hardware), this may matter less (although it will never cease to matter - just think of all that slow code running on our desktops which eats the performance improvements we still (marginally) get, making desktop performance appear flat since 2004), but if your target is well-defined hardware-wise and if you know/set "upper bounds" for all the practical problem sizes your program is designed to handle, you can think of more optimal solutions for your case. This is one of reasons why you can still play the newest games on 2005 hardware (XBox 360) which hasn't even got an out-of-order CPU, while running the newest desktop software (not games!) on PC of the same era is problematic.

To sum up, I'm not saying "never use STL", but I would not say "always use STL" either. People claim that using "standard" code helps you create more secure, robust, performant programs - but in my experience, you will end up running a lot of custom tools (all kinds of profilers and validators) anyway before shipping your binary, that makes the point of "performant/secure code by design" moot. When profiler tells you that some code in an STL container underperforms, reimplementing it - or even understanding why that happens - is harder than fixing/improving your own implementation, yet you'll probably have to do that anyway. And no one starts "from scratch" these days, each "low-level" programmer I know has their own set of STL-alike classes.

By the way, your reference seems severely dated. Some of its complaints are still valid, but seem based on the state of STL support ten years ago.

Well, it is perhaps improving with new "move" constructors and whatnot, but that's actually a problem: it's better to have cross-platform code with predictable behavior than code that is supposedly optimal everywhere, but which depends on highly varied implementations. What good is it for me to know that some compilers (e.g. gcc), on some platforms (e.g. x86), handle new, C++11-ready STL well - gcc isn't particularly good at optimizing code even for x86, and another compiler that is a good optimizer may not support the newest features and make my STL-heavy code suck.

P.S. Also, STL (in implementations I saw) is written in quite unreadable, convoluted style - I always wondered why. This is of course less rele

Re:In practice it's like a different language.

[Anonymous Coward]

Or put the FILE* in a std::unique_ptr and watch the head of those guys explode. You know, the guys who insist that whenever you get a new feature that is in some contexts in some sense an improvement over an old feature, the old feature has suddenly become an abomination and must be got rid of at once.

Re:In practice it's like a different language.

[jelle]

#warning rant coming

"printf instead of std::cout"

I love c++, but it definitely has some dark spots, even still the long overdue c++0x update (c++11 whatever). Thank deity we finally have standard smart pointers, better templates in various ways, move semantics, etc. It was really necessary to finally have that, even if it was a decade late (I'm sure we lost quite a bunch of good c++ programmers and projects to more newfangled languages in the delay). Even though we often won't be able to use it until all compilers (and developers) in use for a certain codebase are updated, it is a start.

c++ streams... After exceptions the second worst mistake in c++... c++ needs something good for that functionality, but streams and exceptions don't help.

Beware of std::cout, it is not thread-safe and is a gigantic pain in the expletive for outputting formatted text. The utility of overloading the shift operator for interfacing with streams is overrated. std::endl is a curse word. streambuf is an ugly hack.

while std::string is usually an improvement over the plain 'char *', it also is as often overkill as it often is underpowered. Why else would so many people have their own string class? Why would Qt have QString? It's because std::string and fstreams are severely lacking... standard c++ needs more syntactic strength in tokenizing, parsing, formatting, transforming, combining, and type-converting of string content. What is there, in the standard, is, well, imho kludgy. I'm not saying that I have the answer to what exactly it needs, it just needs something better.

c++ still has a lot of catching up to do. Libraries like boost should really only have their sandbox and legacy code left, and libraries like qt shouldn't need to redo/replace basic functionality. It should be possible to get a proof of concept implementation (aka badly optimized but mostly functional and not too many bugs for a demo or trial) working quickly as easy in c++ as it does in certain other languages. Until then, it should work hard to catch up before we lose most programmers to other languages.

Re:In practice it's like a different language.

[TheRaven64]

printf() isn't typesafe, but it's a fuckton more readable than all that cout formatting stuff

Readable? Meh. Localisable? Now that is an important attribute. Consider this trivial bit of code:

printf("The %s %s\n", colour, object);

You want to localise this, so you wrap each string in a function that returns the localised version (by the way, gcc and clang have an attribute that you can put on functions that says if the output is safe to use as a format string in any case where the input is). So now you have something that looks like this:

printf(localise("The %s %s\n"), localise(colour), localise(object));

Okay, no problem. Now let's consider the C++ equivalent:

cout << "The " << colour << ' ' << object << '\n';

Harder to read? Maybe, but the tokens are all in the order that they'll appear in the output, so I'll give C++ that one. Now let's localise it. How about something like:

cout << "The ".localise() << colour.localise() << ' ' << object.localise() << '\n';

That's fine, right? No more complex than the C version. Well, almost. Let's make French the target language. We want to turn 'the black cat' into French. Now we have a problem. In French, the word order is different. The result we want has the colour after the noun. No problem in the C version, the format string is just translated as "Le %2$s %1$s". The arguments are reversed (well, it's a little more complex because you also need agreement between the noun and the article, but I'll skip over that for now - it can be solved in the same way). What about the C++ version? Well, because the word order is in the code, not the data, you need different code paths for English and French. And that's just with a three-word sentence. Now consider the kind of sentence that actually appears in a typical UI. Consider German word-order rules. Your simple C / Objective-C strings file has to be replaced by a huge tangle of C++ code.

Re:In practice it's like a different language.

[TheRaven64]

My example is a trivial example. Go and look at some real code. In big applications, we use this pattern in Objective-C all the time. It's a trivial way of constructing localised strings. Now go and look at the mess of template metaprogramming that people use to do the same thing in C++...

Re:In practice it's like a different language.

[obsess5]

In real code, you localize based on entire messages, not individual words. How do you localize an English word that, with one spelling, may be a noun or verb and, in the latter case, may be of different tenses? You would need the context of the entire message and a natural language processor to translate the word. (Localizing the common word "The" in isolation as you do is fraught with errors.) Consequently, it's better (and quicker and easier) to translate entire messages rather than individual words.

Re:In practice it's like a different language.

[sco08y]

That's fine, right? No more complex than the C version. Well, almost. Let's make French the target language. We want to turn 'the black cat' into French. Now we have a problem. In French, the word order is different. The result we want has the colour after the noun.

It seems like it would be a lot easier to just change the word order of the offending languages than to screw up perfectly good C++.

Re:In practice it's like a different language.

[jadrian]

Could you expand on this? I don't work that much with OO languages. So I looked for 'Liskov substitution principle' and I understand it concerns semantic requirements of types in a hierarchy. But aren't these semantic requirements valuable precisely so that your code behaves uniformly across types, and is therefore reusable?

Re:In practice it's like a different language.

[Paul Dubuc]

C with classes is a derogatory term used to describe programmers and code which wraps C-style code and various bad practices with classes. ...

"C with classes" was the name given to the language before it was named C++.

Re:In practice it's like a different language.

[tibit]

It's not about reusability, it's not quite about uniformity, it's about expectations. If you have an instance of Foo (or a derived class), things go horribly wrong if you cannot consistently assume anymore that it acts like Foo. By horribly wrong I mean you have bugs galore. There's no problem deriving Bar from Foo and documenting that it acts weird -- you can still "reuse" Bar -- but it will, almost always, lead to bugs. Reusability is a nice side effect.

Re:In practice it's like a different language.

[MadKeithV]

Now be careful, because inheritance was not really intended for code reuse. If it does help with code reuse, that's a positive consequence, but it's not what inheritance is for, first and foremost. See Liskov substitution principle and all that jazz.

Be even more careful, because public inheritance is definitely not intended for code reuse, but protect and private inheritance are!

Comment removed

[account_deleted]

Comment removed based on user account deletion

Fascinating Software Engineering Challenge

[Bookwyrm]

In some ways, a lot of what is being added to C++ makes me think of Scala, just less readable.

While the additions and extensions certainly make things more interesting and potentially more powerful/easier for the *individual* programmer, I look forward to seeing what sort of interesting train wrecks happen when larger teams try to make use of these features. I certainly hope the debuggers are being updated to be useful when someone's written a template that uses a #define'd macro to specify a closure that is passed through an anonymous function, etc.

This strikes me as the next generation's 'multi-threading' -- where almost every programmer claims they can handle multi-threaded programming, but very few actually do it well. Particularly in teams when interactions require coordination. Going to take a whole new round of winnowing the wheat from the chaff when it comes to finding developers who can actually use these features well without driving their coworkers insane.

Re:Fascinating Software Engineering Challenge

[MurukeshM]

Time to overhaul the academics. Nearly every engineering course here (I'm in India) has a couple of programming courses. A lot of students do coding some time or the other. Yet not even a sentence is uttered about threads or parallelism, even though practically every computer they code in has multiple cores. They should probably introduce a course on parallel processing as an elective for freshmen.

Re:Fascinating Software Engineering Challenge

[khipu]

Both C++ and Scala are attempts to modernize limited, poorly designed languages (C, Java) by adding things like type parameters and functional features. There are a bunch more of those attempts and I think they have mostly been failures. It's roughly like: "Never try to teach a pig to sing. It wastes time and annoys the pig"

Re:Fascinating Software Engineering Challenge

[jgrahn]

Time to overhaul the academics. Nearly every engineering course here (I'm in India) has a couple of programming courses. A lot of students do coding some time or the other. Yet not even a sentence is uttered about threads or parallelism, even though practically every computer they code in has multiple cores. They should probably introduce a course on parallel processing as an elective for freshmen.

I took such a course back in the early 1990s. Can't say it did me any good, except to teach me that parallelism is damned hard, and that you can stare on a piece of threaded code for a while and convince yourself it's correct ... and yet it isn't.

20 years later, I have seen little production code with threads that didn't suck, and little code without concurrency bugs.

Re:For my next trick

[Anonymous Coward]

I shall now make two predictions:

1) Hordes of comments are about to appear that denigrate C++.

2) 95% of these commenters have never written any C++ code more sophisticated than

cout << "Hello, World!" << endl;

Welll, now.

You see, being a C++ GOD, I have actually overloaded 'Hello World!' and made it into an operator! And with my overload, you just implemented an operating system!

Re:Optional GC = Bad

[DeathFromSomewhere]

which is in the new standard

No it's not. Vendors have always been allowed to tack on GC. None of the big ones do.

Re:For my next trick

[Anonymous Coward]

That's way to verbose. I overloaded the ;

Not seeing (1)

[SuperKendall]

I don't think you'll see a lot of people flaming C++, there just aren't that many people that care one way or the other anymore.

I think some of the new features look nice but mainstream use has been shifting away from C++ for a while and I'm not sure I see these new features drawing many back...

Re:Not seeing (1)

[gbjbaanb]

Mainstream use is shifting back to C++ since Microsoft decided that C++ was batter than C# (or at least Sinofsky and the Windows team decided that was the case). Herb Sutter has done a lot of presentations on the new paradigm at Microsoft - do a quick google.

Of particular note is the reason they're giving for this: in the datacentre native code reduces the amount of energy required to run your apps, and that adds up significantly if you're using dynamic or even JIT language.

Re:Not seeing (1)

[shutdown -p now]

mainstream use has been shifting away from C++ for a while

What do you think most Windows desktop apps are written in these days?

Re:Not seeing (1)

[SuperKendall]

Thanks, that was interesting, (I liked his "Welcome to the Jungle" entry on multi-core), but I have to take what he says with a grain of salt...

He has a C++ book out and also obviously is very involved in the community. While I will say that makes him way more knowledgeable about C++ than most people, I also think he is understating what .Net can do - it's been basically compiled on the fly for a while.

But more importantly I really feel like modern languages offer better and easier to use constructs for dealing with multi-threading, and just programming in general. C++ is a very powerful language (I spent a number of years working with in in Windows) but I think it's much harder to get people to point where they are writing decent code in C++ than in just about any other modern language.

Re:Not seeing (1)

[SuperKendall]

What do you think most Windows desktop apps are written in these days? .Net or Visual Basic.

Although desktop apps are a declining field all by themselves.

Re:Not seeing (1)

[shutdown -p now]

.Net or Visual Basic.

For one, those two are the same thing, as VB today runs on .NET - and has been doing that for 10 years now.

For another, it's plainly not true. Looking at the set of apps running on my desktop, or those around me, I can see maybe 2-3 managed apps, and the rest is native.

Re:Not seeing (1)

[RzUpAnmsCwrds]

Whether the performance of a managed language (most commonly Java or .NET) is inferior to C++ is almost entirely dependent on your workload.

Java running on the Oracle VM (HotSpot) is actually faster than C++ in many ways (object allocation, virtual function/method calls, the built-in data structures). "Modern" C++ code that uses STL and smart pointers tends to waste a lot of time copying memory around and/or tracking reference counts. Of course, the GC in Java also spends a lot of time copying memory around, but it can be done concurrently and for most programs it is quite efficient.

C++ wins big in two main ways: latency and with loopy scientific code. The fact that you have GC in Java makes latency hard to predict, and if you need to meet latency targets a high percentage of the time C++ is probably the right choice. As for scientific code, Java VMs typically make very poor use of vector instructions and do not have anywhere near the sort of loop/memory ordering optimizations you find in something like ICC.

Re:Not seeing (1)

[gbjbaanb]

He does work for Microsoft, I think his expertise in the community was the reason they hired him. Given that, I'd say he is more knowledgeable about the real OS-level limitations of .NET than the rest of us.

(although I did enjoy reading Chris Brumme's blog posts where he went into detail about the .net runtimes and some of the decisions they'd not do again if they had the chance to start over. The one on exceptions was brilliant).

Yes, C++ is harder than PHP, but that's maybe the point. I've seen so much truly awful code and most of it is in 'easy' languages. I do despair that the answer to a difficult problem (coding) is to make yet another accessible language that doesn't solve the problem well enough, and you end up with more coders who think they can do the job when really its all about education and training. To my mind C++ isn't that difficult, but then I've been doing it for years and I understand what happens under the covers, which allows me to make much more informed decisions on how to design my code. A lot of my junior colleagues seem to just slap something together that works and leave it at that. Then I have to come in and fix the performance issues.

Threading is probably better in C++ now. You have the new thread constructs (eg thread thread1 = thread(myfunc, paraam1, param2); will start a thread going. But you also have a load of power over what else you can do compared to other languages).

Or if threading is too difficult, you should look into things like Thread Building Blocks that try to keep the threads compartmentalised (which is the problem most people have with threading - getting their shared data mixed up between the threads). Or you could use OpenMP which is amazingly easy to code for (just slap a pragma before your code and your loops with magically become parallelised)

Maybe C++ isn't that hard after all, it just has that 'my language is so much easier and just as powerful' hype working against it.

Re:Not seeing (1)

[gbjbaanb]

"Modern" C++ code that uses STL and smart pointers tends to waste a lot of time copying memory

this is false. Unless you explictly code to pass by value all the time, the optimiser will be making it work without the copying. Modern C++ even has the move constructs now that make it easy to ensure your memory is moved rather than copied in the tricky cases.

I always thought the problems with the java-style languages were more memory based. Every one I've seen sucks up RAM like there's no tomorrow - which is fair, coders in those languages are told that memory is cheap and that the GC will fix all their problems for them. Its a lie (of course) but enough still believe it.

And there are enough reports of poor performance with WPF that you have to think these new languages with their fancy libraries are poorly designed, or engineered. When your GUI requires better performance you know your language isn't up to scratch.

Re:Not seeing (1)

[SuperKendall]

For another, it's plainly not true. Looking at the set of apps running on my desktop, or those around me, I can see maybe 2-3 managed apps, and the rest is native.

You can release C# / VB apps in compiled form, how do you know that is not what has been done?

Yes I know VB runs on the .Net runtime, though a lot of VB6 people never moved on because it also changed the language somewhat (just like C++ on the .Net runtime was not quite the same thing either).

Re:Not seeing (1)

[shutdown -p now]

You can release C# / VB apps in compiled form, how do you know that is not what has been done?

What do you mean by "compiled form"? It's pretty easy to tell a CLR .exe/.dll from a native one.

just like C++ on the .Net runtime was not quite the same thing either

Not so. VC++ can actually compile the entirety of ISO C++ (to the extent it normally supports that), sans setjmp/longmp, to target .NET. C++/CLI is a set of language extensions that enables access to CLR object model, which can be used as a glue language between C++ proper and other .NET stuff, but it does not have to be used in C++ code compiled to IL.

Re:Not seeing (1)

[shutdown -p now]

Managed C++ was a bad thing, but everything I said still applies - it was a bunch of syntactic extensions that only had to be used to glue together vanilla C++ code and .NET libraries. You could compile plain C++ to managed IL since the very first versions of VC++ that shipped with .NET - that was not coincidental, as CLR was designed with that in mind, hence why it has e.g. raw function and data pointers.

He's optimistic

[mark-t]

FTA

I expect to see the first complete C++11 compiler sometime in 2012

I expect to see the first complete C++11 compiler sometime after I see the apocalypse.

Oh right... I guess that would be December 2012, wouldn't it? :)

Seriously... while a lot of compilers implement some of the features, I really don't think there's a hope in hell of seeing any real progression to adopting the standard. With C, the standard developed around what many compilers were already doing... ditto with the original C++ spec. But C++11 describes a standard that absolutely nobody has ever got anywhere close to, so I don't imagine that there's going to be a lot of drive to adopt it.

Re:He's optimistic

[19thNervousBreakdown]

The majority of it is implemented. http://gcc.gnu.org/projects/cxx0x.html

Re:He's optimistic

[grumbel]

> But C++11 describes a standard that absolutely nobody has ever got anywhere close to, so I don't imagine that there's going to be a lot of drive to adopt it.

All popular C++ compilers already implement large parts of C++11, so the chance of seeing widespread C++11 adaption in the not so distant future is pretty high. Also this wasn't really any different with C++98, which essentially no compiler supported on release and which then took a few years to gain widespread adoption.

Re:He's optimistic

[shutdown -p now]

We never had a "complete" C++98 or C++03 compiler, either. Didn't stop people from writing successful production software in that.

Re:He's optimistic

[mark-t]

Indeed... more of it than what I thought. Thanks for the link

But the concurrency stuff still seems quite far from being fully supported.

Re:He's optimistic

[mark-t]

My complaint wasn't about lack of successful software, I was complaing about calling something a standard when nobody is really particularly close to following it yet.

Re:He's optimistic

[shutdown -p now]

Well, C++ has always been like that. Come to think of it, so has HTML/CSS. It still works out in the end, more or less.

Re:He's optimistic

[jgrahn]

All popular C++ compilers already implement large parts of C++11, so the chance of seeing widespread C++11 adaption in the not so distant future is pretty high. Also this wasn't really any different with C++98, which essentially no compiler supported on release and which then took a few years to gain widespread adoption.

C++98 was worse. There was extern templates, which was a major mistake (read the proposal to remove it from C++11 for some amusement). There was Microsoft, who lost interest in C++ around that time, and condemned a generation of Windows programmers to Visual Studio 6 and a weak standard library implementation. And yet gcc was usable around 1999 or so. I started using the std namespace in late November that year.

Re:He's optimistic

[CSMoran]

We never had a "complete" C++98 or C++03 compiler, either. Didn't stop people from writing successful production software in that.

Didn't Comeau C++ use to be 100% compliant, extern included?

Re:He's optimistic

[shutdown -p now]

They had all the features, yes, but I'm pretty sure they had some conformance bugs, too. With spec of this size (and that many defect reports), everybody does.

Re:George Bjarne Lucas Stroustrup

[Anthony Mouse]

WTF?

Re:For my next trick

[Anonymous Coward]

That's nothing. I overloaded eof.

Re:For my next trick

[boaworm]

C++ SUCKS!! It's a piece of shit language with a very crappy garbage collector

If you are making extensive use of the C++ garbage collector and it isn't working very well, I can understand your frustration :D

Some idiotic stuff too

[Daniel Phillips]

I guarantee you will quickly come to hate the new "narrowing" errors, for example any time int converts to float inside initializer curlies, or double to float. As a language feature, this lies firmly in the category of wanking.

That said, my code is all full of lambdas now, thankyou. On the other hand, lambda syntax is uglier than sin. While a lambda can do anything a lexically scoped nested function can, it is not pretty. Now obviously, there is no reason not to support proper lexically scoped nested functions, as GCC already does. Arguing that they are now unnecessary because of lambdas is, again, wanking. The practical fallout is that when you move a lambda-style helper function to global scope or to member status, you have a bunch of editing to do, to remove the ugly auto/lambda bits.

Another big disappointment is, nothing was done to address the good features C99 has that C++ does not. Designated initializers and variable size array parameters, to name two. Wanking again.

On the whole, there is too much wanking going on in the C++ stewardship process. Guys, you need to remember, C++ does not exist only as a means of compiling the STL.

Re:Some idiotic stuff too

[Daniel Phillips]

Dear Mr Coward, I am perfectly happy programming in a statically typed language for the applications I currently develop. However, I am against wanking in general, including the sort of wanking you just stooped to.

Re:Some idiotic stuff too

[Daniel Phillips]

Its painfully obvious from your brain vomit in the comment that you have little to no understanding of modern C++.

Dear cowardly wanker,

I do not hesitate to presume that I have written more and better C and C++11 than you. Come back when you are in a correct frame of mind to debate intelligently.

Assigning new values to constants can be useful!

[MarcAuslander]

I was amused by the comment "If that incr(0) were allowed either some temporary that nobody ever saw would be incremented or - far worse - the value of 0 would become 1. The latter sounds silly, but there was actually a bug like that in early Fortran compilers that set aside a memory location to hold the value 0. "

Back then, I wrote Fortran subroutines which took computed dimension arrays by declaring the arrays with crazy bounds, numbers I hoped would never be used as constants, and then "assigning" the real bounds to the "constants".

Those were the good old days.

Re:George Bjarne Lucas Stroustrup

[dyingtolive]

I think he either forgot his LSD today, or took too much. Not sure which yet.

Re:For my next trick

[busyqth]

Since the advent of 64-bit pointers, the garbage collector in all of my C/C++ compilers has been working great.

Re:A decade late and a dollar short

[Anonymous Coward]

It is easy to refute your argument on memory safety and auto with a single line of code:

auto obj = make_shared( arg1, arg2 );

lambda expressions can only be assigned to an auto, because the actual type is compiler defined.

auto some_callable_type = []( float f ){ return f * f; };

Currency isn't supported? What more do you want apart from: threads, mutexes, atomics, thread local storage, concurrency safe memory model, futures, promises, async tasks and thread exception transfer?

Re:Better than I expected

[Anonymous Coward]

Banning random parts of the language because you don't like them? Glad I don't work for you. Fucking dinosaurs.

Re:A decade late and a dollar short

[maxwell demon]

The new version of C++ is a decade behind schedule,

So you're saying it was planned to be finished in 2001? Given that the previous version is from 2003, I strongly doubt that.

Just awful what C++ is turning into

[GodfatherofSoul]

I watched a few of the "Gone Native" webcasts on the C++ extensions, and it's crazy what they're doing with the language. Are the features useful? Yes, but they're taking a complex language and slapping on yet more functionality. Some new C++ code syntax doesn't even *look* like C++ anymore it's so different. Not everyone is a C++ guru and the language is bad enough supporting so many different paths to the same implementation outcomes. This is just going to make staffing, testing, training, and code review that much worse trying to juggle yet another barrel-full of C++ "improvements".

They need to just start from scratch and create a limited subset of features that doesn't pretend to be C and doesn't lug around all of the past mistakes in the standard, and call it C+++.

Re:Just awful what C++ is turning into

[shutdown -p now]

They need to just start from scratch and create a limited subset of features that doesn't pretend to be C and doesn't lug around all of the past mistakes in the standard, and call it C+++.

The whole point of C++ is to be a very powerful language while retaining backwards compatibility with a large body of existing C++ code - some decades old by now - and also allowing to reuse plain C headers with little or no changes. It does that admirably.

If you need a whole new language along those lines, Clay is probably what you want.

Re:Just awful what C++ is turning into

[GodfatherofSoul]

Your complain boils down to "C++11 has some changes".

That's not my complaint, your level of comprehension maybe

Re:Just awful what C++ is turning into

[euroq]

They need to just start from scratch and create a limited subset of features that doesn't pretend to be C and doesn't lug around all of the past mistakes in the standard, and call it C+++.

They did. Check out the D Programming Language.

Re:For my next trick

[Imagix]

Don't leave garbage lying around. Clean up after yourself.

So, has it gained a standard ABI yet?

[blackpaw]

Probably the last thing preventing it from being truly safe and useful in shared libraries across implementations.

How many years has it been?

Re:News?

[rubycodez]

prominent compilers support it? the one supporting the most platforms, gcc, doesn't have it all yet

So what is a good book to learn C++11

[Anomalyst]

and these new features?

Re:So what is a good book to learn C++11

[oldhack]

Ulysses by James Joyce.

Re:So what is a good book to learn C++11

[LizardKing]

Dante's Inferno. Sample quote:

Obscure, profound it was, and nebulous, So that by fixing on its depths my sight - Nothing whatever I discerned therein.

Re:To little, to late

[91degrees]

Who cares about C++ these days?

The games industry, the financial software industry, and most companies developing niche hardware.

Re:For my next trick

[shutdown -p now]

Garbage collectors only manage memory. Smart pointers, on the other hand, can manage any kind of resource - whatever you release in your destructor.

That's why languages like Java and C# still need stuff like Closeable and IDisposable, and syntactic sugar for them to avoid writing try/finally ladders. Whereas in C++, resource management has always been done right, and memory is treated as just another kind of resource.

Re:A decade late and a dollar short

[shutdown -p now]

The main purpose of "auto" is to allow for (auto p = arr.begin(); p != arr.end(); p++) {... } without worrying about the type of arr.

No, it's not. The above is written as follows in C++11:

for (auto x : arr) { ... }

And, of course, you can just as well use the actual element type there instead of auto.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Meh...

[jythie]

I gave up on C++ years ago. It has really become a 'geek cred' language with a constantly changing 'right' way an aesthetic, perfect for figuring out if a fellow geek is from the same snapshot of teaching you came from, but that is about it. It has become overly complex with redundant language features that one needs to keep relearning in order to understand other people's code.. and of course with complexity comes the ability to show off your knowledge through doing things in 'clever' ways.

Good for showing off.. bad for getting actual work done, esp for projects that last more then a year or two.

Re:Meh...

[jgrahn]

I gave up on C++ years ago. It has really become a 'geek cred' language with a constantly changing 'right' way an aesthetic, perfect for figuring out if a fellow geek is from the same snapshot of teaching you came from, but that is about it. It has become overly complex with redundant language features that one needs to keep relearning in order to understand other people's code.. and of course with complexity comes the ability to show off your knowledge through doing things in 'clever' ways. Good for showing off.. bad for getting actual work done, esp for projects that last more then a year or two.

Well, what are the alternatives? I my domain, it's plain old C. Java is not an option, and from the little I hear fashion changes *more* quickly there anyway.

I think your impression of the changing "right" way is warped, or perhaps you're in a subculture I'm not familiar with. I see these different ways:
(a) C with classes, from C programmers who've read a book but don't quite get it.
(b) OOP/Design Patterns rule! Popular in the mid-1990s. Lots of inheritance and stuff; every piece of code aspiring to generality and inclusion in a reusable library.
(c) The pragmatic view, e.g. in Stroustrup's "The C++ programming language".
(d) Template Meta-Programming rules!

(a) and (b) are dead ideologies today, although you discover lost tribes practicing them now and then. I happily ignore the (d) crowd unless they can provide a stable, documented library which I don't have to debug. Besides, they seem to have settled down a bit in recent years.

To summarize, I see no big change since the late 1990s.

Re:Meh...

[Greyfox]

I've been doing some system-level programming and... stuff... with the language again lately. I was getting tired of having to load a language VM to run my code (Flavors of perl, Ruby or Java) and not having a whole lot of control over the hardware I'm running on. I'm just as happy rolling up a raw process and seeing how little memory I can get away with using. A mostly-C socket server and a tiny little btree class is all I need to serve up some legitimately useful information with a memory footprint under 20 kilobytes. You can't even run fucking ls in under 20 kilobytes these days!

I know, I know, why do that when you can dedicate an entire system to an oracle database instead. Eventually you just can't bludgeon your problems to death with hardware anymore and need more subtle solutions.

My last demo (Which you can find at https://github.com/FlyingRhenquest/fr_demo) is still pretty rough around the edges but was mostly to allow me to play with Cppunit and boost::thread. My C++ socket server makes for a weightier process, but probably scales better since it uses threads instead of forking off a new process for each request. You can always fork if you want to, at least on Linux -- it just copies the thread you're currently in. So you can exec off a new process if you want to. I should probably be using boost::asio instead but that seems like a lot of extra complexity just to get the bits I need.

Gotta say I really like Cppunit. I feel like I'm abusing it making it test multi-threaded things but it just keeps working beautifully. It's not at all difficult to set up a suite of unit tests to run. If you do it the way I did, most of the work is just linking the new object into your unit test executable in the makefile.

I also like boost's threads, or more specifically their mutexes. scoped_lock is teh sexieh! C and C++ scope handling in general is just really nice.

Re:News?

[rubycodez]

looks like the same situation as gcc, some C++ 11 things to be supported in Visual Studio 11 but other not:

15 years too late

[cheekyboy]

Thats the sort of stuff I heard about 15 years ago, a little late, those guys should have been hard at a new release the day java got popular and got $100s of millions of dollars in developer seeding in the 90s

Come on intel, give us a microcode C# & java VM accelerator in the cpu.

Doesn't mean all that much...

[jonwil]

Doesn't mean all that much if the compiler vendors dont implement all these great features.

Visual C++ (the compiler I have to use for a certain project due to C++ ABI compatibility issues with existing code and a better compiler on Windows than GCC IMO) doesn't support any of the interesting stuff like "Delegating Constructors", "Inheriting Constructors", "Initializer Lists", "Range-based for-loop", "constexpr" and "Non-static data member initializers".

Even the next version is little better on supporting the nice bits of C++11 :(

Instead Microsoft spent a lot of effort adding all kinds of useless new compiler crap to support their WinRT junk (which to me seems like the answer to a question nobody asked)

Re:For my next trick

[shutdown -p now]

In one corner we have memory, which is 99% of the "resources" needed to be managed

Go ahead, count the number of calls to "Close" and "Dispose" in a real world C# or Java app. Then get back to us with some solid number for that 99% claim.

Simple example, open a file, write to it, let the dtor flush and close. If flushing fails, you won't know, because dtors can't return anything, and exceptions in dtors is a big no-no (because, incidentally, there's no GC to free the stuff). That's _wrong_.

Suppose you're right, and you detect that flush failed during close. What are you going to do?

Suppose furthermore that you have an exception in flight, and you've just had flush fail in your finally-block (assuming C#/Java). What are you going to do now?

If you want exception safety, you need RAII, period. If you have RAII, you might as well use it for memory.

Smart pointers are a lousy GC scheme that does memory badly (ref counting is inefficient, especially on MP systems, and cannot handle cycles)

Those claims that refcounting is inefficient are old, but somehow they only show up in synthetic tests. In real world apps, something written in C++ is invariably faster and more responsive than alternatives written in managed languages. That's precisely why C++ is still used far more widely for desktop apps, and is used almost exclusively anywhere perf really matters (like games).

And there's weak_ptr for cycles.

Re:A decade late and a dollar short

[QuasiEvil]

If your compiler is doing anything different with p++ and ++p in that expression, it has a sucktastic optimizer. There's no reason it should create a copy when the value of the expression is thrown away.

Re:Better than I expected

[Anonymous Coward]

Amen.

Re:For my next trick

[superwiz]

Except, of course, in case of circular references. Oh, and before you mention weak references (to be totally honest, I am not even sure if there is a standard weak reference in C++), I'll mention that very few C++ programmers know what they are. The syntax of C++ is so crowded that the language is only used for low level stuff where the extra 5% performance boost is a big deal. I am not sure if CUDA programming can only be done in C++, but I think that if one absolutely needs CUDA, then he is already doing some low-level stuff.

goto is all you need for modern programming?

[reiisi]

(Not arguing with your broad point that these new addirions to C++ will be useful.)

Goto is no way sufficient for modern programming. You also need some way to manipulate whatever passes for the (effectively stack) constructs that allow nested parameters and locals. And you need some way to hide the bulky extra code (as in text macros and such).

I got bit on this when I should have known better, back in '97 or so -- using a Fujitsu CoBOL, forgot that the old CoBOL PERFORM was kind of like the old BASIC GOSUB. Found myself trying to use recursive calls in some UI code, and the variables I was expecting to be local to the procedures were, of course, global, and my fancy UI screen would keep blowing up.

I'd have had to implement effective stacks all over that code to keep it from blowing up. Gave up and reverted to the older, much harder to understand UI.

Re:goto is all you need for modern programming?

[martin-boundary]

In principle, all you need is to have a set of instructions that can recreate all the machine code instructions in your PC. So that means I think comparisons, jumps and reading/writing global values (a memory location is a global variable, eg named byte000001, byte000002 etc). But your point is well made, without support for local variables and stack frames you'd have to simulate all that as well. There's a lot of layers.

Re:goto is all you need for modern programming?

[jrumney]

Goto is no way sufficient for modern programming. You also need some way to manipulate whatever passes for the (effectively stack) constructs that allow nested parameters and locals. So push, pop and goto then. Anything more is syntactic sugar.

Re:To little, to late

[LizardKing]

The games industry

Can't speak for them ... never worked there. However ...

the financial software industry

I currently work there, and it's almost all Java or C# apart from a few legacy things in VB (shudder). The only place a subset of C++ is used is with the extremely time critical stuff that a single team uses to do arbitrage where we can host servers close enough to the exchange - and nigh on all of that would actually compile with a C compiler rather than a C++ one.

and most companies developing niche hardware

Where I used to work (doing automation), and most of my programming acquaintances still do. And it's mostly C with a little ARM assembler. C++ has never been big there because the libraries are too big and the memory use too unpredictable thanks to the amount of copying idiomatic STL code results in.

Re:For my next trick

[dyingtolive]

Oh yeah? I modded your mom flamebait!

Prime sieves are easy to miswrite.

[reiisi]

I was playing around with a factoring sieve the other day when I realized just how much my choice of language colored the algorithm I used.

If you use the same algorithm across all the languages, it prejudices your results. If you use a different algorithm for each, you end up comparing apples and oranges.

Sure, if you use the stuff in your language that requires overhead, the overhead will be there.

Re:Prime sieves are easy to miswrite.

[superwiz]

There is a sweat spot for benchmarking though. Roughly 50 mil primes will guarantee that you won't need to go over 4 byte integers. Also don't bother skipping even numbers or numbers divisible by a few of the other lower primes. It will bias the result towards the language with inlining techniques (unless you actually duplicate the code in the languages which don't have inlining). And skipping all the even or all the 3,5 multiples will make you test less numbers, but won't make you spend less time testing. Most of the time is not spend on the numbers which are rejected quickly. Most time is spent on the numbers with least divisors (like primes themselves).

Re:For my next trick

[shutdown -p now]

Oh, and before you mention weak references (to be totally honest, I am not even sure if there is a standard weak reference in C++)

std::weak_ptr in C++11. Been there for 7 years now (originally as std::tr1::weak_ptr), and for a few years before that in Boost.

I'll mention that very few C++ programmers know what they are.

That's the problem with those programmers, not the language. C++ is powerful and fast by design; that, unfortunately, also makes it complex by design. It's not a language for everyone, and Java and C# certainly have their very large niche. But C++ is a very powerful tool when used right.

The syntax of C++ is so crowded that the language is only used for low level stuff where the extra 5% performance boost is a big deal.

That's emphatically not true. I've repeated it several times already in this thread, and I'll repeat it again: most desktop software today is written in C++. Heck, even a fair bit of OS X software is written mostly in C++, especially if you look at the size of it (MS Office, Photoshop). The reason for that is that perf boost (relative to Java/C#) is more like 20% for common tasks; but, more importantly, there is a marked responsiveness improvement due to lack of GC. And responsiveness is some really subtle stuff - it's not quite the same as "fast", but it's very sensitive to stutter on the order of tens of ms (a delay over 100ms is already noticeable by the user).

You can write good UI software in managed languages, but then you need libraries that are themselves written in native code, at least rendering and input layer. Otherwise you end up with a clumsy pig like Swing.

Hahaha, windows is still bloated

[cheekyboy]

Yeah that has helped, look at Win2008 Server and Exchange 2010.

What bloody hungry hippos, either too many coders re implementing shit, or fucked If i know.

But interfaces/guis dont need C++, they would work as well in C#.

Judging by MS's C++ API, stop using long named objects, and 12 function calls to achieve one objective.

Hey, windows2000 uses less ram than android on a $60 phone. Why not just use win2000-64bit as a datacenter OS in VMs, running non-MS open sourced linux apps.

Boot Win2008Svr, and it uses more ram than 4 linux distros running at once in 4 VMs.

Re:Hahaha, windows is still bloated

[gbjbaanb]

amen. Windows 2000 was a good OS. I can't think why the new ones use so much resources to do pretty much the same thing.

Guis don;t work too well in C# - look at the performance issues many people have with WPF. Now, this can mean that WPF was poorly designed (all that XML... I can believe it) or it can mean it was badly implemented (too much copying 'cheap' memory about?) or it could mean that C# GUI apps can be crap too.

Given than, I don't think people have many problems with C++/Qt apps though.

Or imagine just how bad it would be if Windows really was re-implemented in C#.

Re:For my next trick

[superwiz]

I'll mention that very few C++ programmers know what they are.

That's the problem with those programmers, not the language. C++ is powerful and fast by design;

Not really. Most Java programmers know about the weak references in Java. And in Java they are less necessary than they are in C++ (because the C++ gc model steaming from smart pointers is based on reference counts). If a necessary tool goes underused in a certain context, then it is the problem with how the context is presented to its audience -- not with the audience.

But C++ is a very powerful tool when used right.

Any tool is only as powerful as it is useful. It is not reasonable to judge tools only by the peak performance achieved by its most committed users.

The reason for that is that perf boost (relative to Java/C#) is more like 20% for common tasks;

And I posted a fairly simple benchmark which shows otherwise.

there is a marked responsiveness improvement due to lack of GC.

Only for a certain class of problems. Btw, I would say that mark-and-sweep is a type of gc -- not that it is gc. Reference count is also a gc method. But that's a semantic argument. And I am more than willing to admit that it is a matter of opinion.

You can write good UI software in managed languages

All application languages are managed.... by the operating system.

Otherwise you end up with a clumsy pig like Swing.

Swing is only clumsy because it attempts cross-platform functionality (which necessitates that it supports only the least common denominator of features). It's not clumsy for any kind of inherent performance design issues in the Java language.

Re:To little, to late

[91degrees]

Plenty of legacy C++ in the finance industry. Heaps of jobs advertised want Boost, and last time I was interviewed for a position (at Bloomberg) they were interested in my C++ skills.

Not all niche hardware is small scale ARM based. A lot of it is based on Windows or Unix powered by a pretty standard desktop PC. Digital billboards, large touch screens. Things like that.

Re:The Leviathan...

[Chrisq]

This is just Lisp with an overcomplicated syntax.

This must be one of the least insightful comments I have ever read.

Being all things to all programmers

[caywen]

I think C++ 11 may be falling into the trap of trying to be all things to all programmers. Certainly developments in C# and Java had something to do with some of these improvements. But, at what point can one say that a system has become too complicated to quickly reason with? Has C++ reached that point?

That said, certainly these changes are welcome improvements for existing C++ developers who want easier ways to reduce complexity of their code.

Re:Being all things to all programmers

[bames53]

One thing I found interesting about Herb Sutter's talk at the Going Native conference was his slide comparing language complexity. According to the metric he used (page count of the language specification) C++11 is very close to Java 7 and the current version of C#. (IIRC, marginally smaller than Java, marginally larger than C#).

And a great thing about C++11 is that many features exist mainly for backwards compatibility, and a new programmer doesn't need to start out learning them at all; there's a clean, modern path through learning C++, and learning the rest can be left to when you actually have to maintain legacy code. Bjarne Stroustrup's intro to programming book teaches C++ this way and it's quite good.

Re:Uh. No.

[The Askylist]

I'm one of those who detests operator overloading, for the simple reason that if you want a new operator behaviour, then you should define a new operator - it makes code easier to read and maintain, and avoids confusion.

But that's just my experience - you may differ.

Re:Uh. No.

[Electricity Likes Me]

Operator overloading is to address the ambiguity of having by-value and by-reference passing of objects being possible via different semantics in the language.

If I have a pointer and write:
ObjType* pObjRef =
then it's pretty obvious I have an object reference.

But but what does
ObjType Obj2 = Obj1;
actually mean?

C++ defines this type of transaction as always being a copy operation. But an object is a complex datatype - doing a straight copy of all it's memory doesn't necessarily give me sensible behavior. So you need operator overloading to let you enforce sensible behavior.

That you can also use it to create syntactic sugar or completely illogical behavior doesn't make it bad though. And absent a garbage collector, I'm not sure it actually makes sense to do what C# does and try and treat all object variables as references (in that when would you deallocate things?)

Re:Uh. No.

[Electricity Likes Me]

Huh, ok, did not know I couldn't use the ampersand in a post.

Re:Uh. No.

[Anonymous Coward]

Operator overloading abuse is bad, but being able to write, for example, z*z + c instead of cplx_add(cplx_mul(z,z), c) or set - set2 instead of set.difference(set2) adds a lot to readability.

I, for one, dislike language communities driven by "Somebody can cut his finger, so let's remove all cutlery from the house" principle.

Re:For my next trick

[CSMoran]

I am not sure if CUDA programming can only be done in C++, but I think that if one absolutely needs CUDA, then he is already doing some low-level stuff.

CUDA Fortran is where it's at for hard-core number-crunching. See e.g. http://www.pgroup.com/resources/cudafortran.htm

Re:Uh. No.

[The Askylist]

I may be biased here - I first came across operator overloading a good decade and a half ago, when C++ was used in the first iterations of object-oriented databases.

It was a proper mess back then, and I fear it still is - if I want the sort of behaviour you wish to enforce, then Scala would be my language of choice - I still view C++ as C with object wrappings, templates and lots of stuff that gets in the way of efficient code.

Re:Uh. No.

[The Askylist]

Coming from a Lisp background, I, for one, find cplx_add(cplx_mul(z,z),c) deficient in parentheses and overburdened with commas ;-)

Re:Uh. No.

[The Askylist]

Try &

Re:Uh. No.

[Pseudonym]

But that's just my experience - you may differ.

My experience is that it's beyond confusing when you need to use a mathematical ring (say), but its implementation uses operators other than * and + to implement the ring operations.

My further experience is that using your own operators is a great idea, and works extremely well right up until the point where you use a second third-party library which defines its own set of (sometimes clashing) operators. I also happen to know that no language has yet managed a sane syntax for namespace-qualifying an operator, which suggests that it may be impossible.

Re:Yeah but C++ is the Baron Harkonnen of Language

[petermgreen]

Still i'd rather have a language with features I don't want than a language that is lacking features I do want.

Re:just awful

[khipu]

You don't like the new language features? Well that's great, don't use them then. You can still fall back to plain C code as much as you like.

How naive are you? In the real world, every language feature that gets added is a feature that all developers have to deal with, because it is used in libraries (including the standard library), affects debuggers, optimization, error handling, resource management, IDEs, etc.

Furthermore, an even bigger problem is the missed opportunity: C++ tries to be a modern systems programming language, but it fails to do a good job at that. Yet, it has enough inertia to discourage people from investing in doing something better.

So, you enjoy writing web browsers in 6800 asm?

[reiisi]

I can write a FORTH in the old Motorola M6800 assembler. Once I have the FORTH, it's not that far to a rudimentary web browser, although the address space limitations will prove a source of frustration.

Implementing FORTH on the 6809 is a bit more fun. High level constructs, more registers, access to the stack that does not have to tunnel through arcane sequences of pushes/pops/swaps.

Implementing FORTH on the 68000 is much more interesting, because it has enough registers to access parameters/locals, persistent allocation areas, thread locals and globals, etc. It's not just syntactic sugar when you don't have to waste half of your code fighting the botlenecks.

Goto is not enough.