I am a programmer in C and C++, although I don't stick to either language and write a mixture of the two. Sometimes having code in classes, possibly with operator overloading, or templates and the oh so great STL is obviously a better way. Sometimes use of a simple C function pointer is much much more readable and clear. So I find beauty and practicality in both languages. I don't want to get into the discussion of "If you mix them and compile with a C++ compiler, it's not a mix anymore, it's all C++" I think we all understand what I mean by mixing them. Also, I don't want to talk about C vs C++, this question is all about C++11.

C++11 introduces what I think are significant changes to how C++ works, but it has introduced many special cases, exceptions and irregularities that change how different features behave in different circumstances, placing restrictions on multiple inheritance, identifiers that act as keywords, extensions of string literals, lambda function variable capturing, etc.

I know that at some point in the future, when you say C++ everyone would assume C++11. Much like when you say C nowadays, you most probably mean C99. That makes me consider learning C++11. After all, if I want to continue writing code in C++, I may at some point need to start using those features simply because my colleagues have.

Take C for example. After so many years, there are still many people learning and writing code in C. Why? Because the language is good. What good means is that, it follows many of the rules to create a good programming language. So besides being powerful (which easy or hard, almost all programming languages are), C is regular and has few exceptions, if any. C++11 however, I don't think so. I'm not sure that the changes introduced in C++11 are making the language better.

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

2

I understand that there should not be a C++11 rant in this forum and I totally agree on this: every developer has the right to have their personal taste regarding programming languages and tools. There is, however, a much more practically issue for me: I am a C++ developer and I do not like C++11, will I be forced to use C++11 or be out of the market / switch to another language within a few years?
–
GiorgioNov 9 '11 at 17:01

Well I thought a bit about that, of course there are more modern from-scratch languages such as the D programming language or Go. These might be suitable for your problem domain, easier more consistent, etc. However market share.. none of the key players in the industry supports D and even Go seems to be one of googles "experiments".. So the motivation behind C++11 should be the useful improvements which allow you to write better readable, safer and faster code as well as the wide industry support.
–
NilsMar 16 '12 at 9:46

@giorgio, during the past two years, I stopped using C++ as much as I did before (mostly because of realizing how religious C++ fans are, reading answers to this question), but still I did also work in a C++ library which I willingly used C++11 for. My experience was this: C++11 addresses a lot of crappy corners of C++, and that's admirable and indeed it improves on it. The way it does it have its own crappy corners (see the original unedited post). However, those crappy corners seem to be out of the way if you do things "the normal way" (e.g. not store a lambda for future use).
–
anonJul 9 '14 at 15:27

@giorgio, what I mean is, C++11 may look bad in the beginning, in fact C++ itself looks terrible, but if you are ok with C++, you would probably like C++11 too. Just avoid touching its crappy parts and you may actually enjoy it.
–
anonJul 9 '14 at 15:29

@anon: One way to get rid of the crappy parts of a language is to cut with the past and start a new language, like Apple is doing with Swift (to name only one of numerous examples). Interfacing with legacy code can be done through separate compilation. The problem with C++ is that it gets extended indefinitely, probably because it is supported by a community of fans who religiously believe that C++ is the one true language. Bottom line: I found C++03 a bit crappy but it got the job done, especially thanks to libraries like Qt and boost. On the other hand, I will keep my hands off C++11.
–
GiorgioJul 9 '14 at 16:47

10 Answers
10

You should learn it if you think you will need to know it in the future in order to get a job. If you are confident you will remain marketable in the workforce as a C/C++ [ and whatever else you might know ] then don't learn it. If your boss tells you to use C++11, say "no, I don't do that". If he fires you, go work somewhere else. Learn C++11 when you foresee that soon you will be unable to find satisfactory employment with the skills you currently know.

Wanted to clarify my rationale: I'm not anti-C++11. Just saying you could generalize the OP's question to "Why should I learn X". I never learned ML, scheme, or haskell because I have a job with C and C++. I'm sure those languages are useful to someone, but they're not beneficial for me to learn right now. If someone offered me good money to program in ML, I might try to learn it.

If you're a "C/C++" developer, and if your boss tells you to use C++11, shouldn't you just go ahead and add that to your arsenal? I agree that you shouldn't spend all your time learning languages just for the sake of learning them, but when your boss says, "Learn this", it's probably a good idea to go ahead and learn it. It also makes you more marketable, as opposed to having to explain on your next application that you got fired over insubordination.
–
PanzercrisisJul 9 '14 at 15:04

nullptr is a VAST improvement over the old 0. It's type-safe and doesn't convert when it shouldn't- unlike 0. It's a good thing that nullptr won't convert to an int. It doesn't make sense for that to happen at all. Do you know what the C++ Committee found when they tried to consider #define NULL nullptr? Stuff like char c = NULL;. How terrible is that? The only reason there's an exception here is because bool is considered an integral type, which is quite wrong- but that was there in C++ before, and in C. The fact that nullptr doesn't convert is good, it's great and you should love it.

Or how about rvalue references and variadic templates? Faster, more generic code. That's a total win right there.

How about the library improvements? Stuff like function, unique_ptr and shared_ptr are so much better than what was there before, it's impossible to argue that the C++03 way was better.

#define adding_func(x, y) ((x)+(y))

Not even remotely equivalent. Macros are bad for six billion reasons. I'm not going to quote all of them here, but it's well known that macros should be avoided for pretty much all purposes that they can possibly be avoided for. What are you going to do when it's

#define add_twice(x) (x + x)

Oh wait, I hope you didn't increment or something on x. Which the template function version is totally immune to. I also hope that you don't appreciate namespaces, for example.

Then you open yourself to a world of undefined behavior for using
external variables whose scopes are already finished.

In a functional API, e.g. STL algorithms, then reference is fine. If it's a stored callback, then you need to capture by value. Whatever documentation you have on the function should clearly indicate which is necessary. The fact that the code is written in a lambda is irrelevant to the problem of referring to local variables- if you pass a regular function object, then you're going to have the exact same trouble. And it's not a trouble. At all. Because it's inherently obvious when you can and can't refer to local variables.

Take C for example. After so many years, there are still many people
learning and writing code in C. Why?

There are many people who don't brush their teeth in the morning. There are many murderers, and rapists, and prostitutes. And politicians. People who commit suicide. Would you argue that that therefore makes these activities good or useful? Of course not. It's a logical fallacy that just because someone did it, therefore it must be good or useful.

C is still being written for three reasons: because C++ is a bitch to implement, for example on embedded or kernel mode; because legacy codebases are written in C and would cost too much to upgrade, although even that's questionable given C++'s excellent C interop; and because the people writing it don't know how to program. That's it. There's no other reason to write C.

If you take C or the old style C++, you wouldn't find many exceptions.

How about the pathetic C-style arrays, for a simple example? The number of people who can't get arrays and pointers straight in their head is obscene. Not to mention the fact that the C Standard library is incredibly unsafe.

Your core arguments are full of logical fallacies and misunderstandings.

>The fact that nullptr doesn't convert is good, it's great and you should love it. OK your opinion, but calm down a while about what somebody else should LOVE, please ... The next step is C++ lawyers talibanism!
–
Emilio GaravagliaNov 9 '11 at 12:15

4

I think the later part of your answer is more of why C++ should be preferred to C. That is out of question. "C libraries are unsafe" - how on earth does this answer the question? I mean of course one should learn the new features C++11 offers, but C and C++ are NOT meant to do the same things. If C++ is a bitch to implement at low level, so are C#, Java, Python and whatnot because they weren't intended to run that low. Just because C++ compiles to native code doesn't mean you can use OO and the page thrashing associated with it for critical, kernel level code.
–
yati sagadeNov 9 '11 at 21:06

@yatisagade C++ is a multi-paradigm language that doesn't enforce virtual functions for everything, and my programs in C++ are similar. Parts of it use object-oriented design, parts of it are functional, etc., depending on what solves that particular sub-problem best. I appreciate C++ for adding the object-oriented style, and I appreciate C++11 for greatly expanding support for functional programming.
–
David StoneApr 24 '12 at 18:19

5

"That's it. There's no other reason to write C.": C is lower level than C++, so what? C++ is lower level than Java, so what? Java is (maybe?) lower level than Haskell. Again, so what? Every language offers a different abstraction level that is appropriate for a different task. Some readers have criticized the question as a rant against C++, I do not find it valuable to answer with a rant against C. -1.
–
GiorgioApr 30 '12 at 5:16

C++11 is not a new language; it is only an extension/modification of C++ that you already know . C++11 just like any other programming language consists of features. A lot of them were there from before, some of them are new. But your question really is, should I learn all features of the language (in this case C++11), or only familiarize myself with 90% of it?

IMO even if you are not using all of the language, you should at least read up on what the new features do for you. A lot of them were introduced to make library/framework code (especially templates) easier to write (for example, before C++11 perfect forwarding was impossible), but if you never had the need for those feature before, chances are you won't notice that these features were added in C++11.

On the other hand, if you've previously dabbled in writing library/core code that mimics some of STL/Boost functionality and found yourself being limited by the language because you've come 95% to having a very cool, elegant solution but then you were stopped because you found out language simply doesn't support what you want, you will realize the truly awesome power of C++11. Ever since our team upgraded to VS2010 (and we've discovered Boost in the process), I've been able to crank out some crazy awesome code, that would simply be impossible prior to things like r-value references and template parameter forwarding.

Also things like lambda's may look foreign, but they don't introduce a new construct. Instead they make what we used to have before so much easier to write. Previously every lambda function would have to be a separate class. Now it's just {...code...}. Love it.

The key is don't look at these features and think how daunting the list is. Instead, use C++ as you normally do and when you come across some scenario where these new C++11 features come in handy (more than 90% of people will never get to that point), you'll be very happy that the extension to the language was done. For now, I'd suggest you just learn enough about the language to know what's there, not necessarily how to use all of it.

@Shahbaz - I think you still missing the intention of why nameless functions were added. And "using variables without taking them as input" is called closure and is available in many other high-level languages. If you wrote a lot of template code with functor objects, with C++11 you would be welcoming lambda functions with open arms. Think of it this way... when compiler generates machine code, there's no such thing as template function or class. They are all "instantiated" to create concrete classes/functions prior to that point. Lambdas are the same thing when it comes to stateful...
–
DXMNov 9 '11 at 10:04

4

...functors. Instead of having people write a ton of code, one for each type of functor and every closure element you want to pass in, C++11 allows you to specify a shortcut syntax and it will auto-instantiate an entire internal functor class just like it instantiates templates. Again, keep in mind that most of these features will not be used in 98% of application-level code, but they were added to make libraries like STL/Boost that much more powerful and easier to implement/maintain/debug
–
DXMNov 9 '11 at 10:08

8

@Shahbaz: Okay, you don't understand lambda functions or closures. That's reasonable. The fact that they're used in many different languages should suggest that they are useful, whether or not you understand them, and that you should understand them before criticizing them too much.
–
David ThornleyNov 9 '11 at 14:59

7

@Shahbaz: If you think closures are similar to global variables, you don't understand closures. (Hint: global variables cause problems because any function can modify them.) If you understood the concept of lambdas, not the implementation, you'd not be attributing it to confusion of classes vs. code. Everything in the C++ Standard is there for reasons that were convincing to a large number of intelligent people. You don't have to agree with the reasons, but without knowing them you're criticizing from ignorance.
–
David ThornleyNov 9 '11 at 16:08

Is it so hard to write a function, that you have to write the content of the function inline with the code, besides giving it no name?

When you do that you scroll up, or open a new source file and add the definition of the function there. Then you have to go back and continue on what you were working on, which distracts you to some degree.

Other than that, when other people are reading you code a lambda may be more self-documenting in some cases, instead of saying "Oh, what does this function do?" and jumping to its declaration you can just have a look at what it is doing in its own place.

There is a nice talk by Herb Sutter about lambdas, maybe he can convince you better:

Well, why don't you just write the code there instead of making it a lambda-function?

Because you can't do it when you are using STL algorithms, or any function that you are using which requires you to pass a function.

#define adding_func(x, y) ((x)+(y))

There is no way to justify this usage instead of lambdas, you cannot fill your code with macros everywhere. Macros and functions have different purposes, and one, in general, is not a replacement for the other.

I agree, this is ugly. However I remember myself saying "why the hell should I figure the type of this expression even though the compiler can infer this?" in lots of cases. This might help a lot during those moments.

To sum up:

Even though the new features of C++11 seem ugly in their syntax, I think one can get used to them in a short time. Every new language construct is difficult to learn at first; imagine the first time you learned to write a whole class: Putting the declaration in the header file, not forgetting the extra semicolon at the end, putting the definitions in the source file, including the header file while ensuring that it has a guard for preventing multiple inclusions, not forgetting the scope resolution operator in the member function declarations and so on...

But I am pretty sure that after writing a few classes you get used to it, and you don't think about the complexity of this process: Because you know that a class makes your job as a programmer a lot easier, and the utility you are earning from this new construct is a lot greater than the utility loss during the time you were trying to learn the language. I think this can be the reason why one should try to learn, or use C++11 in a similar manner.

Arguments about self documenting and less scrolling etc, I'm pretty sure opposite arguments such as "cluttering code", "restricting access" etc were once used to argue why functions outside class must be banned. I think people need to get more experienced to decide which is better. Seems to me this is either a failing experiment or a bad design. I am more convinced not to be the lab rat in this experiment.
–
ShahbazNov 9 '11 at 9:57

About the syntax looking ugly, take these two for example: bool is_alive; and bool thisSpecialObjectOfMineIsAlive;. Both do the same, but the second looks really ugly. Why? Because I mistakenly thought putting more info makes it more clearly, but it has done the opposite. It's the same deal here, Stroustrup meant good by giving us features, but he just didn't make it good looking. To me this shows a bad design.
–
ShahbazNov 9 '11 at 12:04

@Shahbaz: I think lambdas are a great concepts (and have been around for many years in languages like Lisp). I use them a lot in Haskell. I am less sure that they fit in languages like C++, Java, etc. They feel a bit like an afterthought to me: something that was added later because lambdas have become popular. Why weren't they introduced in these languages from the very beginning? Had Stroustrup and Goslin never heard of Lisp?
–
GiorgioSep 10 '12 at 16:42

Actually the OP have some points, as of the most of the answers. But they are "distant" in vision. C++ (including C subset) has a long history where a number of features had been added across the time, some of them used more or less frequently and -through teir useage and mistakes- perfectioned into others and others.

Sometimes it happens that, after introducing a new feature, an old one is anymore needed, or feels in contradiction with it. A "clean" language should be self-consistent as it is, and not anymore needed features should be removed.

But adding doesn't destroy anything. Removing (or changing) breaks existing code that it is still in production, so whatever feature you add, you must take care to don't break existing code (in particular, don't break it silently, making it doing different things as intended).

Do you have to learn all of that?
Yes, because all features are -in the good or bad, sooner or later- used.
Whether this is a good thing for language "quality" (admitting there is an objective measure for it) is another story: how long should backward compatibility retained? hard to find an answer, when someone say 3 years and some other say 50.

The alternative to keep C++ more "regular" is... break it more often, with a scratch restart. But it will be no C++ anymore.

There are attempts to do that as well (think to D, for example: much much more orthogonal as C++ (even 11) actually is), but how popular are them? On of the reasons of their difficult in having momentum is the incompatibility with many existing code that still has to run.

C++11, to me, is clearly a compromise between new needs and backward compatibility. That resulted in a certain "messiness" of its specs and implementation. Until the cost of that "messiness" is less than the cost of incompatibility... you have to leave with that compromise.

If you cannot anymore tolerate it, ... better to consider another younger language. C++ simply cannot be simplified in that sense. Not at this age.

I also agree. And as a developer I find it very disturbing to have a language that is a changing all the time (that I have to learn again and again). If you develop a new language you should make a new start and use a different name. If you want it to cooperate with legacy code, there is separate compilation for that. So I really do not understand the policy of changing an existing language by incorporating the latest features that have become fashionable. As someone said: further development does not automatically imply progress.
–
GiorgioNov 13 '11 at 9:47

"C++ simply cannot be simplified in that sense. Not at this age.": Why aren't other programming languages (e.g. C, Ada, ...) following the same path then? Maybe because they have their own niche of applications and they are not expected to be the tool for all possible application areas.
–
GiorgioApr 30 '12 at 8:31

@giorgio: yes ... you're probably right in the "pragmatic" sense. But in theory ... I remember some good days where pascal was the "teaching reference language" and ada was the "everything programming language wannabe".
–
Emilio GaravagliaApr 30 '12 at 9:00

I also learnt programming in Pascal. As far as I know Ada went through several revisions but the basic design of the language was not subverted. The same with C and Pascal. If one wants to develop a really new language, one should be brave enough to make a clear cut and start something new, like D, Java, C#. My problem with the current path C++ is taking is it is (unnecessarily) getting too complex. If the KISS and YAGNI principles apply to software design, why shouldn't they apply to programming language design too?
–
GiorgioApr 30 '12 at 18:14

@Giorgio: oh ... they apply ... exactly as you said. If you think C# or D did a better choice than a "boiled out" C++ (my interpretation of your feeling), just use them instead of C++. An as time moves on C++ will slowly die. Right now,I see C++11 giving a new chance to the "boiled" C++03, and D with still something missing to break the starting barrier. Economics and corporation interests also play a role in how development is financed and encouraged. You're right in theory, but real world is more complex.
–
Emilio GaravagliaMay 2 '12 at 19:12

After so many years, there are still many people learning and writing
code in C. Why? Because the language is good.

First, most students these days are learning Java or .NET, not C. Second, people are still using C not only because of its advantages as a language, but mainly because there is a huge amount of existing software written in C that needs to be maintained and extended, and because in many cases (e. g. embedded platforms) a C compiler is all there is. Incidentally, these are some of the reasons why people still write COBOL.

It is very rare for a programmer in the industry to start working on a brand-new project that is not tied to an existing code base, and to continue working alone. So, the reason to learn C++11 is that you are likely to have to deal with code written by other people, that uses the new features. Also, the features that were added were added for a reason. Once you learn them and use them, you might come to appreciate them.

You quoted my sentence incompletely. Like I said in the sentence after, good means it follows rules of a good programming language design. I don't know where you study, but I know of 4 or 5 countries and they all start learning programming with C. Like I said, with C, there are next to no exceptions (something that is opposite in Java, you could barely find a construct that doesn't have an exception).
–
ShahbazNov 9 '11 at 16:42

1

@Shahbaz: I quoted complete sentences. You made a causal connection, and I said that it is at best incomplete. Thankfully, I don't study any more. :) I have done quite enough of that. I live in the US, and when I went to college (over 15 years ago) C was the introductory language. However, today most US schools begin with Java, and there are not that many young programmers who know C.
–
DimaNov 9 '11 at 17:03

5

@Shahbaz: I really don't see the problem with language rules having exceptions. Yes, C is a much simpler language than C++. On the other hand, C++ makes it easier to write simpler code. To write simpler code you need more language features. That makes the language more complex. I, for one, like things like classes, references, RAII, templates, constructors, destructors, exceptions, and namespaces. But you said your question was not about C vs C++, so I did not write about that in the answer.
–
DimaNov 9 '11 at 17:09

Even if you decide to ignore the new C++11 features, you'll still benefit from them because the C++ Standard Library will use them. For instance, in C++ 98 having a variable of type vector<string> was potentialy a performance disaster because of the number of copies needed to be made when the vector grows. With C++11 move constructor, it is a non-issue. In fact, I wish C++11 brought us more new features, not less - especially in the Standard Library.

That's the answer, basically. Everything else is just details as to how exactly you can benefit from it and what powers you have by knowing it, and they're so many that any enumeration would be incomplete.

One example is your own question. You wouldn't be able to even ask it without learning at least a bit of it.

And as I commented - the real concern is not why to learn, but why to use. And that's an entirely different question.

All the languages were created because someone didn't like the existing ones. That doesn't make any of them good.
–
ShahbazNov 9 '11 at 16:43

I don't say NULL should be an int. It shouldn't. What I don't find proper is to introduce a construct in the language that solves this, but introduces exceptions. They should have been able to do the same thing in a better way.
–
ShahbazNov 9 '11 at 16:45

2

"C++11 was created because people didn't like writing C++": if they didn't like writing C++, why is C++ a subset of C++11?
–
GiorgioNov 13 '11 at 9:49

1

It should be: C# and Java was created because people didn't like writing C++.
–
CalmariusSep 10 '12 at 15:57

You should learn C++11 because the features added allow you to write better code. Some people have mentioned type safety of NULL pointers and lambdas, which are very nice. But I want to draw attention to what I think is the most dramatic change in C++11, especially in a large production environment: move semantics.

C++11 supports separate notions of 'moving' and 'copying'. In regular C++, we just have the = operator which basically does both of these. But really, we are expressing two separate ideas with one operator, which is hazardous.

The most obvious example of where this is useful is the new unique_ptr. It has all the best features of the old auto_ptr and scoped_ptr. Suppose we want to have a pointer that is guaranteed to be the only pointer pointing to an object. How do we deal with a = b? Well, before, we were stuck, you could either disallow it completely (as scoped_ptr), or we could do what auto_ptr does where a=b steals ownership from b. This behavior of auto_ptr is very confusing because a = b actually changes b. unique_ptr handles this: a = b is not allowed, but you have a = std::move(b) to steal ownership. How is this useful? Where, there is a separate (overloaded) version of swap that uses move semantics rather than copy semantics. This means that that unique_ptr can be swapped, no problem. This means that unique_ptr, unlike auto_ptr, is safe to use in a container and then say sort. unique_ptr is basically the be all and end all of safe memory management when you don't need multiple pointers on the same object.

Another great example: suppose you have an object that is uncopyable. This is useful in a number of situations. You can never return this object from a function, because when the function ends it copies out whatever you are returning. The ironic thing is that usually the compiler actually optimizes this out (i.e. nothing actually gets copied at the end, the return value is created at the address of eventual assignment). But this has nothing to do with why we made it uncopyable; returning from a function is really just moving the object from inside function scope to outside. You can now write objects that are uncopyable but ARE movable, and these objects can be returned from functions.

Move semantics make it much easier to write code that won't leak and is thread safe.