×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Stroustrup Reveals What's New In C++ 11

Soulskill posted more than 2 years ago | from the please-don't-say-facebook-and-twitter-integration dept.

Programming 305

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.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

305 comments

"Not a major overhaul"? (5, Insightful)

Godai (104143) | more than 2 years ago | (#39152079)

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!

In practice it's like a different language. (1)

Anonymous Coward | more than 2 years ago | (#39152243)

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

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

Roachie (2180772) | more than 2 years ago | (#39153681)

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. (4, Insightful)

DeathFromSomewhere (940915) | more than 2 years ago | (#39153861)

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. (5, Interesting)

tibit (1762298) | more than 2 years ago | (#39153929)

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. (1)

Alex Belits (437) | more than 2 years ago | (#39153939)

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:"Not a major overhaul"? (1)

interval1066 (668936) | more than 2 years ago | (#39152421)

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"? (5, Interesting)

genjix (959457) | more than 2 years ago | (#39152533)

I've been using the C++11 for 6 months now in my own project (libbitcoin [libbitcoin.org]) 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"? (1)

genjix (959457) | more than 2 years ago | (#39152575)

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"? (0)

Anonymous Coward | more than 2 years ago | (#39152823)

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.

Re:"Not a major overhaul"? (5, Informative)

swillden (191260) | more than 2 years ago | (#39152945)

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"? (-1)

Anonymous Coward | more than 2 years ago | (#39153035)

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, and 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. 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?

Re:"Not a major overhaul"? (2, Informative)

Anonymous Coward | more than 2 years ago | (#39153085)

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"? (2, Informative)

Anonymous Coward | more than 2 years ago | (#39153155)

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"? (1)

Bill_the_Engineer (772575) | more than 2 years ago | (#39152897)

What C++ compiler are you using?

Re:"Not a major overhaul"? (4, Informative)

genjix (959457) | more than 2 years ago | (#39153439)

> 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"? (1)

bipbop (1144919) | more than 2 years ago | (#39153967)

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

Re:"Not a major overhaul"? (2, Informative)

Tyler Durden (136036) | more than 2 years ago | (#39153289)

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"? (-1, Troll)

muon-catalyzed (2483394) | more than 2 years ago | (#39153371)

>> C++ is no longer that unsafe

You can code safely in assembly, if you know what you are doing. Today's dumb hires dumber IT situation yielded some fascinating language restrictions that 'disarmed' the coder and traded performance for dubious safety, buzzwords like "managed code" emerged so the exec could have an easy time choosing platform - Sun mastered this kind of marketing with Java. The result is that you need a multi-gigahertz quad core to run a simple 2D text browser or a simple GET replier at decent speeds.

Re:"Not a major overhaul"? (1)

Anonymous Coward | more than 2 years ago | (#39153585)

Bullshit.

Re:"Not a major overhaul"? (1)

loufoque (1400831) | more than 2 years ago | (#39153925)

constexpr (a far more expressive metaprogramming utility than templates)

That is incorrect.

Re:"Not a major overhaul"? (5, Informative)

19thNervousBreakdown (768619) | more than 2 years ago | (#39152555)

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"? (1)

Godai (104143) | more than 2 years ago | (#39153467)

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"? (1)

DeathFromSomewhere (940915) | more than 2 years ago | (#39153605)

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.

I want auto! (1)

boaworm (180781) | more than 2 years ago | (#39152087)

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

Re:I want auto! (1, Interesting)

Anonymous Coward | more than 2 years ago | (#39152217)

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! (3, Insightful)

DeathFromSomewhere (940915) | more than 2 years ago | (#39152289)

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! (1, Funny)

Anonymous Coward | more than 2 years ago | (#39152471)

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! (1)

smelch (1988698) | more than 2 years ago | (#39152477)

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! (2)

DeathFromSomewhere (940915) | more than 2 years ago | (#39152745)

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

Re:I want auto! (-1)

Anonymous Coward | more than 2 years ago | (#39153219)

Eclipse CDT begs to differ.

Re:I want auto! (-1)

Anonymous Coward | more than 2 years ago | (#39153329)

And Fails.

Re:I want auto! (-1)

Anonymous Coward | more than 2 years ago | (#39153551)

The poor craftsman blames the tools.

Re:I want auto! (1)

smelch (1988698) | more than 2 years ago | (#39153449)

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! (4, Insightful)

SpryGuy (206254) | more than 2 years ago | (#39152337)

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 [blogspot.com]

Re:I want auto! (1)

aztracker1 (702135) | more than 2 years ago | (#39153623)

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! (1)

Anonymous Coward | more than 2 years ago | (#39152373)

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! (0)

smelch (1988698) | more than 2 years ago | (#39152607)

Why would you be using an anonymous type if you needed a reference to it that couldn't be handled with the [object] type? That sounds down-right wonky.

Re:I want auto! (4, Insightful)

19thNervousBreakdown (768619) | more than 2 years ago | (#39153141)

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! (0)

smelch (1988698) | more than 2 years ago | (#39153565)

My point is that it seems to me that if you are doing something with it that you couldn't do to any type, you shouldn't be using an anonymous type. I would genuinely like to know what a valid case is for using an anonymous type where later you will be accessing one of its properties by name. If you pass that anonymous type to another function it will have to be an [object] anyway, and if its just the same function, build the properties for the anonymous type before initializing the anonymous type. You can't pass an anonymous type to another function as its type (and it would be stupid if you could), and you can't cast from an object to the anonymous type (which would lead to the errors you mentioned above). So, within the same function, your anonymous type may as well be an object instead of a var.

Re:I want auto! (1)

Anonymous Coward | more than 2 years ago | (#39152407)

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! (2)

Anrego (830717) | more than 2 years ago | (#39152637)

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! (3, Interesting)

WARM3CH (662028) | more than 2 years ago | (#39152723)

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! (1)

TheSkepticalOptimist (898384) | more than 2 years ago | (#39152829)

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! (0)

Anonymous Coward | more than 2 years ago | (#39153093)

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.

I agree on the usage of var here - but I disagree with using var as a replacement for superclass/interface assignment:

    MyCollectionSuperclass myCollection = new CollectionSubclass();

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).

Stupid. You should know which superclass/generic someclass.ACollection is. (Your IDE should show you, and as long as you're making that argument to begin with, stop being lazy and mouse over the RHS expression.)

this is particularly helpful using Linq such as:

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

Maybe, but as it seems that Linq is just abridged JDBC code anyway that doesn't strike me as particularly useful to begin with. There are better ways to manipulate database information.

Re:I want auto! (2)

91degrees (207121) | more than 2 years ago | (#39152969)

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! (0, Interesting)

Anonymous Coward | more than 2 years ago | (#39153547)

Interestingly, K&R shows that "auto" is a reserved keyword, but it's only just been implemented. So it seems it was a good idea that just never happened for 30 years...

Re:I want auto! (5, Funny)

godrik (1287354) | more than 2 years ago | (#39152705)

chances that oracle will see the light? :-)

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

Re:I want auto! (1)

Daniel Phillips (238627) | more than 2 years ago | (#39152973)

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.

News? (0)

PatDev (1344467) | more than 2 years ago | (#39152109)

Seriously? This is months old! You know how old this is?

It's a collection of new C++ features, and prominent compilers have already added support for it. Getting C++ compiler vendors off their butts to implement new features takes freakin' forever, but I can already play with lambdas, auto, and variadic templates - at least.

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

Re:News? (5, Funny)

busyqth (2566075) | more than 2 years ago | (#39152165)

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

Stop pretending and get back to your FORTRAN!

George Bjarne Lucas Stroustrup (-1, Troll)

smoothnorman (1670542) | more than 2 years ago | (#39152113)

Someone should insist with (much-beloved) Professor Stroustrup that it's ok/desirable to leave it so Han Solo shoots first.

Nothing to see (1)

Jorl17 (1716772) | more than 2 years ago | (#39152201)

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

Seriously, a big disappointment.

For my next trick (2)

davidoff404 (764733) | more than 2 years ago | (#39152255)

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;

Re:For my next trick (-1)

Anonymous Coward | more than 2 years ago | (#39152429)

Does this count:

std::cout "Hello, World!" std::endl;

Re:For my next trick (0)

Anonymous Coward | more than 2 years ago | (#39152565)

Yeah, everyone knows 'using namespace' is for chumps.

Re:For my next trick (1)

Anonymous Coward | more than 2 years ago | (#39152455)

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:For my next trick (2, Funny)

Anonymous Coward | more than 2 years ago | (#39152511)

That's way to verbose. I overloaded the ;

Re:For my next trick (1)

Anonymous Coward | more than 2 years ago | (#39152715)

That's nothing. I overloaded eof.

Not seeing (1) (4, Insightful)

SuperKendall (25149) | more than 2 years ago | (#39152609)

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:For my next trick (0, Troll)

rmstar (114746) | more than 2 years ago | (#39152659)

Hey you,

I've written big apps in C++ and can tell you: C++ SUCKS!! It's a piece of shit language with a very crappy garbage collector, a baroque, undecidable syntax, no end of karma, and a community that revels in BDSM programming. With an emphasis on the M.

So there.

Re:For my next trick (0)

Anonymous Coward | more than 2 years ago | (#39152709)

I nearly thought you were serious, until you started complaining about C++'s garbage collector...

Re:For my next trick (0)

rmstar (114746) | more than 2 years ago | (#39153445)

I nearly thought you were serious, until you started complaining about C++'s garbage collector...

Well, the thing is that this is typical C++ brain damage. If you criticize that there is no garbage collector, you get some bullshit involving std::shared_ptr. I mantain that most C++ programmers think that that rotten POS is actually a garbage collector. If you then say, well, whatever, "C++ has a rotten POS of a garbage collector", then, of course, it turns out C++ has no garbage collector. Go figure.

Brain damage all around.

Re:For my next trick (0)

Anonymous Coward | more than 2 years ago | (#39153709)

I always thought if you're going to go to all the trouble of smartpointers, you might as well just use garbage collection and make your life easier.

Re:For my next trick (1)

boaworm (180781) | more than 2 years ago | (#39152807)

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

Re:For my next trick (1)

busyqth (2566075) | more than 2 years ago | (#39153123)

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

Re:For my next trick (0)

Anonymous Coward | more than 2 years ago | (#39153229)

I've written big apps in C++ and can tell you: C++ SUCKS!!

Based on your comment about the C++ garbage collector, I assume your big C++ app was something like:

for (int i=0; i<10; i++)
    std::cout << "Hello, World." << std::endl;
std::cout << "You had me at the first Hello!" << std::endl;

Fascinating Software Engineering Challenge (5, Insightful)

Bookwyrm (3535) | more than 2 years ago | (#39152351)

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.

Optional GC = Bad (0)

bky1701 (979071) | more than 2 years ago | (#39152435)

Optional Garbage Collection, which is in the new standard, is a horrible idea. You cannot depend on it, as it is not guaranteed, and it will slow programs which do not need it, as well as potentially break low-level operations on memory. I have no idea what they were thinking when they allowed that in, but it is a very dangerous "feature."

"Help me protect myself from my own incompetence!" (-1)

Anonymous Coward | more than 2 years ago | (#39152485)

Bjarne Stroustrup (pronounced "Sack Stroker") is a friggin' idiot who couldn't write robust code in C so he created a monstrosity to protect himself from doing stupid things that competent programmers knew not to do in the first place.

He's optimistic (1)

mark-t (151149) | more than 2 years ago | (#39152613)

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 (4, Informative)

grumbel (592662) | more than 2 years ago | (#39153489)

> 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 (0)

Anonymous Coward | more than 2 years ago | (#39153503)

When will we see the first C++11 book from Addison Wesley (now Pearson I think) with Brian Kernighan as senior editor?

I think that'll be the informal "Gentlemen, start your engines" moment with respect to pulling developers' attention away from C++98.

More on C++11 (0)

Anonymous Coward | more than 2 years ago | (#39152777)

a video of Stroustrup presenting C++11 style: http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Keynote-Bjarne-Stroustrup-Cpp11-Style
a paper by Stroustrup describing C++11 for software infrastructure: http://www.computer.org/portal/web/computingnow/0212/whatsnew/computer-r?src=cnhome-v1

A decade late and a dollar short (0, Troll)

Animats (122034) | more than 2 years ago | (#39152811)

The new version of C++ is a decade behind schedule, and consists mostly of marginal features. Memory safety hasn't improved. Concurrency isn't really supported in the language; all that's really been done is to nail down some of the semantic issues that matter when multiple threads are executing on superscalar processors. There are lots of new features only useful to people writing templates, which are a terrible programming environment. "auto" is useful (I wanted to call it "let", but there was objection to a new short keyword), mainly because the type definitions of iterators are so bulky. The main purpose of "auto" is to allow for (auto p = arr.begin(); p != arr.end(); p++) {... } without worrying about the type of arr. As long as arr is an iterable collection, that should work.

This still doesn't prevent buffer overflows, but at least the most concise way to iterate over an array is reasonably safe. (Not totally safe; modifying a collection over which you are iterating breaks the memory model.) Over the next few decades, the number of buffer overflow bugs might decrease slightly.

It's an improvement, but not one that was worth waiting a decade for.

Re:A decade late and a dollar short (2, Informative)

Anonymous Coward | more than 2 years ago | (#39153245)

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:A decade late and a dollar short (0)

Anonymous Coward | more than 2 years ago | (#39153363)

The p++ is wrong, you must use ++p since it doesn't create a copy.

Clearly you are a terrible C++ programmer, and hence unqualified to comment on it.

Re:A decade late and a dollar short (1)

maxwell demon (590494) | more than 2 years ago | (#39153511)

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.

Some idiotic stuff too (3, Interesting)

Daniel Phillips (238627) | more than 2 years ago | (#39152881)

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 (0)

Anonymous Coward | more than 2 years ago | (#39153759)

It sounds like you want to be programming in a dynamically typed language where compilers raise a minimum of fuss when you do the wrong thing. Any argument you make to the contrary lies firmly in the category of wanking. Now isn't that a persuasive argument?

Assigning new values to constants can be useful! (2)

MarcAuslander (517215) | more than 2 years ago | (#39153077)

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.

Better than I expected (0)

Anonymous Coward | more than 2 years ago | (#39153091)

Actually makes a lot of sense. I normally pretty much ignored the committee, since most of their work seemed to involve things (template madness) that I strictly ban from my teams' projects anyway. The influence of C# is obvious and largely welcome; I'm less thrilled about seeing more boost (a lot of banned code there too, though most of it here looks okay) and attempts to bolt on functional paradigms. That falls under the same heading as garbage collection, as in Apple's misbegotten attempt with Objective-C++.

Still no viable replacement for the preprocessor, but a fair amount of stuff that looks useful, and some to be avoided.

Re:Better than I expected (1)

Anonymous Coward | more than 2 years ago | (#39153465)

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

To little, to late (0)

Anonymous Coward | more than 2 years ago | (#39153339)

Who cares about C++ these days?

Time to move on to something modern

Re:To little, to late (0)

Anonymous Coward | more than 2 years ago | (#39153713)

There is always Common Lisp and Smalltalk to fall back on. Or have all their features been ported into other languages by now? Only took a few decades.

Just awful what C++ is turning into (1)

GodfatherofSoul (174979) | more than 2 years ago | (#39153615)

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 (0)

Anonymous Coward | more than 2 years ago | (#39153831)

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".

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

With time you will stop complaining about how things changed, you will learn the new features and you will understand how silly your comment is. The sooner you will learn, the faster you will stop complaining.

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+++.

So, to your complain that C++ has changed you provide your answer of simply "starting from scratch". Suffice to say, your complaint isn't coherent.

No Problems Here (0)

Anonymous Coward | more than 2 years ago | (#39153657)

All of the issues with C++ are easily dealt with simply by coding in C and checking back in to see what C++ is like in another ten years.

So, has it gained a standard ABI yet? (1)

blackpaw (240313) | more than 2 years ago | (#39153957)

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

How many years has it been?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...