8 ms·

9 reasons to start using C++11

cageface 14y ago
C++ is very much a mixed bag but the new features in the C++11 standard do help a lot. The "auto" keyword and range-based for loops alone have decluttered my code quite a bit. The new smart pointers make me nervous after the auto_ptr fiasco but they seem to be working fine in my code so far. I'm looking forward to trying out the lambdas as soon as they hit in XCode.
- okamiueru 14y ago
  The BOOST_FOREACH has helped declutter my code a lot as well. After getting used to it, I feel it expresses intent better than a for loop with auto begin-end.
simias 14y ago
Is there a resource somewhere listing which compilers support which features of C++11? Or do all major compilers already support the new standard? Portability is probably the main reason I'm concerned about switching my codebase to the new standard...
- nonsequitur 14y ago
  C++11 support in common compilers: http://wiki.apache.org/stdcxx/C++0xCompilerSupport http://wiki.apache.org/stdcxx/C++0xCompilerSupport
  - simias 14y ago
    Thanks to you both, that what I was looking for.
- cageface 14y ago
  All the major compilers support at least some of the standard now, but I'm not aware of any that support all of it. For details consult the following: http://clang.llvm.org/cxx_status.html http://clang.llvm.org/cxx_status.html http://gcc.gnu.org/projects/cxx0x.html http://gcc.gnu.org/projects/cxx0x.html http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.a...
- deleted 14y ago
  [deleted]
johnx123-up 14y ago
Any good IDE and references?
haberman 14y ago
Pretty much everything in C++11 sounds extremely cool and useful. It seems like the committee did their homework; from what I can see all of the new features are well-designed and thought through. Lots of things that were verbose or inefficient before are fixed, and as a result the language will be more expressive. But I just have this nagging worry that C++ is going to collapse under its own weight. C++ was already the most complicated language in common use IMO (except possibly Perl); with C++11 there are more keywords, more constructs, more variations. I just hope this doesn't make C++ seem totally unapproachable to beginners, or too hard to keep up with for people who are already using it.
- cageface 14y ago
  C++ isn't going away but its domain continues to contract. The C++11 standard will slow the erosion but I'm very doubtful that we'll see the "C++ renaissance" that people like Herb Sutter are predicting. Even now on low-powered devices like phones you can often get away with more wasteful languages like Java or even Javascript. And server-side there are a bunch of much higher-level languages that are close enough in performance and usually with a far richer ecosystem to boot.
  - pjmlp 14y ago
    I used to think like that, but now I am back to languages with native code generation for the projects where I can dictate a language choice. Depending on the project requirements, this means C++, D, Go, Haskell or OCaml. Sadly from all options I listed above, C++ is still the best one supported in the industry. But coupled with a good static analyzer, it is quite nice. What we miss is the possibility to have native code generation support for higher level languages to become more widespread.
    - akg 14y ago
      I'd be curious to know why you switched back to languages with native code generation? Is it mostly due to the control you have over code performance? Is so, are such applications fairly specific in scope, e.g., fluid-simulation on the GPU?
toemetoch 14y ago
3 questions before moving to C++11 - which architectures is the author discussing when he talks about performance gains, what are the ISA requirements and numbers? - what compilers are supporting it? - why is it good to have "magic" happening in the background? E.g. reason 4 is not something I'd promote.
- cageface 14y ago
  #4 isn't really magic. It's just a way to let the compiler fill in the blanks with information it already knows. The benefits are debatable for simple, obvious types but for the hairier generic types you often encounter in C++ it's a godsend. Of course, the fact that this is so useful might make you wonder if C++'s type system is too complex in the first place.
  - JamesLeonis 14y ago
    Of course it's complex. The template system is Turing complete! http://stackoverflow.com/questions/189172/c-templates-turing-complete http://stackoverflow.com/questions/189172/c-templates-turing...
- nknight 14y ago
  It's absolutely not "magic", it's clearly-defined, easily-understood syntactic sugar that makes code smaller, simpler, and cleaner. There is never a case where you have to wonder what the type of an "auto" variable is, it is always the return type of whatever function or method you are invoking. If you don't already know what that return type is, you won't be able to use the result anyway.
  - pubby 14y ago
    std::initializer_list is pretty magical.
    - nknight 14y ago
      I don't really buy that. It enables a syntax that otherwise wouldn't be possible, but so does struct. The only thing really "magical" about it is the optimizations it makes possible, but if that were your concern, it would be the first time I heard anyone complain that compiler optimization is "magical" in any negative sense.
webreac 14y ago
Of course, if you are a C++ programmer, you should migrate to C++11 as soon as possible. But do not forget that the improvements given by C++11 do not void all the reasons to not use C++ at all. Avoid C++ if you can.
- okamiueru 14y ago
  As has been said a million times, C++ covers applications that are not really suited for any other language. This applies to C as well. As much as newer languages come about, in the end, you are working with a Von Neumann machine, of which both C and C++ are well suited for. The only problem with C++ as far as I can tell is that you need to know a lot, not to make mistakes. There are too many ways to do things, that if you don't know what you are doing, you are probably going to do things wrong. However, once you _do_ know, and use libraries like Boost, I think it is difficult to come up with a reason why not to use C++ for lower level programming, with performance requirements.
  - webreac 14y ago
    The problem is that the prerequisite does not apply only to you, but also to all your team. It is ok to use C++ for lower level programming with performance requirements if all the development team knows very very well C++. Even if you fill these conditions during initial development of a project, during the maintenance years, you always happen to have a not so well educated developer. C++ use is a very narrow market.
    - okamiueru 14y ago
      Code practices and code reviews help with getting beginners up to speed and not clutter the code base. If you remove all experienced developers with inexperienced ones? Surely this will cause problems in any language. Also, I'll have to disagree with C++ being a narrow market. Just the market where C/C++ is almost required (high performance or low level) is large enough as it is. Then there is the discussion of which language is _more_ suited for a given task when you are doing higher level stuff that doesn't have high performance requirements. It might be wasted resources to put people with high knowledge of C/C++ to that kind of tasks. As for the language itself, in terms of productivity; _if_ the developers are experienced, I don't see any problem with it. With help from Boost and/or Qt, it is as easy as writing python (almost, sometimes :) ).
CrLf 14y ago
What I would like to see is a (convincing) list of why use C++ (in new projects) at all. In my opinion (and experience) when you need the performance advantages of C++, you are usually within the domain where C is good enough (and perhaps a better choice for its simplicity). When you need the features of C++, you are probably better off with something like Python (not specifically, but in the same "league"). Seeing how easy it is to use a higher-level language combined with C for critical sections, I just don't see the point of C++ anymore. Disclaimer: I don't really like C++. The only pleasant experience I had with it involved ignoring the STL completely and using Qt (http://qt.nokia.com/ http://qt.nokia.com/). I like C though.
- bjoernbu 14y ago
  let's say you write a search engine, a route planning system, a database, rule-based NLP (for most ML-based approaches fast, native math libs + python may be great enough because nearly all the time is spent in the math part) on HUGE datasets, etc, etc pretty much any system involving long list- or set-like types with a decent level of complexity. Most other languages enforce far too much indirection, padding et. al for collection types. Especially generics fail miserably compared to templates for that particular matter. C, on the other hand, will make everything MUCH harder. Especially proper use of RAII and (const) references allow (almost) zero overhead and almost no error-prone pointers (especially zero pointer arithmetic) in the whole system.
  - CrLf 14y ago
    I wasn't saying that C++ had no use. I'm saying that its domain is narrower that what's commonly believed. It is false that C "will make everything MUCH harder". How hard something is to implement in a particular language depends on the problem and the people doing the implementation. C is only perceived to be much harder because people have become overly-dependent on language features (aka "syntactic sugar") and cannot reason about problems in terms that do not require those features. I'm not talking about using assembly here. It is not a matter of an unstructured language vs. a structured one. I'm talking about features. This is particularly relevant because in many places where C++ is used, the coding standards prohibit the use of more than a limited subset of the language, effectively transforming it into "C with classes".
option_greek 14y ago
Unfortunately as the number of new projects involving C++ keeps going down, the fields in which C++ jobs are available are getting narrower every year. Almost all middleware is now written in Java. C# took over the frontend development on Windows. New openings in C++ seem limited to quant fields (bank backends on linux) and driver development.
- reddit_clone 14y ago
  > Almost all middleware is now written in Java. That is a bit worrying with Oracle's recent shenanigans with Java copyright. I wonder what people like Rich Hicky and Martin Odersky have to say about this subject.
- NickPollard 14y ago
  And Games. AAA game dev (for PC and Console) is almost entirely C++, with some embedded scripting languages (normally Lua, for performance reasons).
tseabrooks 14y ago
As a long time C++ / C programmer I love every feature here... except one. I really abhor the new auto keyword. Perhaps it's personal taste (I also dislike the "Var" in JS). It really seems to make the code harder to follow with only minimal advantages (that I can see / use/ etc).
- 16s 14y ago
  While I understand the reason for auto, and see the benefit in less typing, etc, I still do it the old-fashioned waytoo. I prefer be explicit.
k4st 14y ago
One of the reasons I like C++ is that it lets you throw away type safety and still maintain it through abstraction. This sounds awful, so let me explain. In one project, I implemented an EDSL for performing a destructuring bind on a string (CFG production, actually). The types of the components of the pattern determined what the pattern would actually match. This was all done in a previous version of C++, so I didn't have variadic templates available. I also didn't want to heap allocate the internals of patterns. What I did was to store an array of void pointers and a function pointer as private fields within a pattern class. When constructing the pattern, pointers to the things to which parts of the string to be bound were put into the array, thus throwing away their types. BUT, the function pointer pointed to a static method in of a class template, which only operated on the array of void pointers in a type-safe way, precisely because it was compiled with the knowledge of the types. I use this type of subversion when appropriate, and it's often a very convenient solution to an otherwise tricky problem. Such a thing would either not be possible--or be incredibly inconvenient--in C. It's often very useful to treat different stuff uniformly, knowing that your abstractions can maintain type safety.

C++ is very much a mixed bag but the new features in the C++11 standard do help a lot. The "auto" keyword and range-based for loops alone have decluttered my code quite a bit. The new smart pointers make me nervous after the auto_ptr fiasco but they seem to be working fine in my code so far. I'm looking forward to trying out the lambdas as soon as they hit in XCode.

okamiueru 14y ago
The BOOST_FOREACH has helped declutter my code a lot as well. After getting used to it, I feel it expresses intent better than a for loop with auto begin-end.

simias 14y ago

Is there a resource somewhere listing which compilers support which features of C++11? Or do all major compilers already support the new standard? Portability is probably the main reason I'm concerned about switching my codebase to the new standard...

nonsequitur 14y ago
C++11 support in common compilers: http://wiki.apache.org/stdcxx/C++0xCompilerSupport http://wiki.apache.org/stdcxx/C++0xCompilerSupport
- simias 14y ago
  Thanks to you both, that what I was looking for.
cageface 14y ago
All the major compilers support at least some of the standard now, but I'm not aware of any that support all of it. For details consult the following: http://clang.llvm.org/cxx_status.html http://clang.llvm.org/cxx_status.html http://gcc.gnu.org/projects/cxx0x.html http://gcc.gnu.org/projects/cxx0x.html http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.a...
deleted 14y ago
[deleted]

johnx123-up 14y ago

Any good IDE and references?

haberman 14y ago

Pretty much everything in C++11 sounds extremely cool and useful. It seems like the committee did their homework; from what I can see all of the new features are well-designed and thought through. Lots of things that were verbose or inefficient before are fixed, and as a result the language will be more expressive. But I just have this nagging worry that C++ is going to collapse under its own weight. C++ was already the most complicated language in common use IMO (except possibly Perl); with C++11 there are more keywords, more constructs, more variations. I just hope this doesn't make C++ seem totally unapproachable to beginners, or too hard to keep up with for people who are already using it.

cageface 14y ago
C++ isn't going away but its domain continues to contract. The C++11 standard will slow the erosion but I'm very doubtful that we'll see the "C++ renaissance" that people like Herb Sutter are predicting. Even now on low-powered devices like phones you can often get away with more wasteful languages like Java or even Javascript. And server-side there are a bunch of much higher-level languages that are close enough in performance and usually with a far richer ecosystem to boot.
- pjmlp 14y ago
  I used to think like that, but now I am back to languages with native code generation for the projects where I can dictate a language choice. Depending on the project requirements, this means C++, D, Go, Haskell or OCaml. Sadly from all options I listed above, C++ is still the best one supported in the industry. But coupled with a good static analyzer, it is quite nice. What we miss is the possibility to have native code generation support for higher level languages to become more widespread.
  - akg 14y ago
    I'd be curious to know why you switched back to languages with native code generation? Is it mostly due to the control you have over code performance? Is so, are such applications fairly specific in scope, e.g., fluid-simulation on the GPU?

toemetoch 14y ago

3 questions before moving to C++11 - which architectures is the author discussing when he talks about performance gains, what are the ISA requirements and numbers? - what compilers are supporting it? - why is it good to have "magic" happening in the background? E.g. reason 4 is not something I'd promote.

cageface 14y ago
#4 isn't really magic. It's just a way to let the compiler fill in the blanks with information it already knows. The benefits are debatable for simple, obvious types but for the hairier generic types you often encounter in C++ it's a godsend. Of course, the fact that this is so useful might make you wonder if C++'s type system is too complex in the first place.
- JamesLeonis 14y ago
  Of course it's complex. The template system is Turing complete! http://stackoverflow.com/questions/189172/c-templates-turing-complete http://stackoverflow.com/questions/189172/c-templates-turing...
nknight 14y ago
It's absolutely not "magic", it's clearly-defined, easily-understood syntactic sugar that makes code smaller, simpler, and cleaner. There is never a case where you have to wonder what the type of an "auto" variable is, it is always the return type of whatever function or method you are invoking. If you don't already know what that return type is, you won't be able to use the result anyway.
- pubby 14y ago
  std::initializer_list is pretty magical.
  - nknight 14y ago
    I don't really buy that. It enables a syntax that otherwise wouldn't be possible, but so does struct. The only thing really "magical" about it is the optimizations it makes possible, but if that were your concern, it would be the first time I heard anyone complain that compiler optimization is "magical" in any negative sense.

webreac 14y ago

Of course, if you are a C++ programmer, you should migrate to C++11 as soon as possible. But do not forget that the improvements given by C++11 do not void all the reasons to not use C++ at all. Avoid C++ if you can.

okamiueru 14y ago
As has been said a million times, C++ covers applications that are not really suited for any other language. This applies to C as well. As much as newer languages come about, in the end, you are working with a Von Neumann machine, of which both C and C++ are well suited for. The only problem with C++ as far as I can tell is that you need to know a lot, not to make mistakes. There are too many ways to do things, that if you don't know what you are doing, you are probably going to do things wrong. However, once you _do_ know, and use libraries like Boost, I think it is difficult to come up with a reason why not to use C++ for lower level programming, with performance requirements.
- webreac 14y ago
  The problem is that the prerequisite does not apply only to you, but also to all your team. It is ok to use C++ for lower level programming with performance requirements if all the development team knows very very well C++. Even if you fill these conditions during initial development of a project, during the maintenance years, you always happen to have a not so well educated developer. C++ use is a very narrow market.
  - okamiueru 14y ago
    Code practices and code reviews help with getting beginners up to speed and not clutter the code base. If you remove all experienced developers with inexperienced ones? Surely this will cause problems in any language. Also, I'll have to disagree with C++ being a narrow market. Just the market where C/C++ is almost required (high performance or low level) is large enough as it is. Then there is the discussion of which language is _more_ suited for a given task when you are doing higher level stuff that doesn't have high performance requirements. It might be wasted resources to put people with high knowledge of C/C++ to that kind of tasks. As for the language itself, in terms of productivity; _if_ the developers are experienced, I don't see any problem with it. With help from Boost and/or Qt, it is as easy as writing python (almost, sometimes :) ).

CrLf 14y ago

What I would like to see is a (convincing) list of why use C++ (in new projects) at all. In my opinion (and experience) when you need the performance advantages of C++, you are usually within the domain where C is good enough (and perhaps a better choice for its simplicity). When you need the features of C++, you are probably better off with something like Python (not specifically, but in the same "league"). Seeing how easy it is to use a higher-level language combined with C for critical sections, I just don't see the point of C++ anymore. Disclaimer: I don't really like C++. The only pleasant experience I had with it involved ignoring the STL completely and using Qt (http://qt.nokia.com/ http://qt.nokia.com/). I like C though.

bjoernbu 14y ago
let's say you write a search engine, a route planning system, a database, rule-based NLP (for most ML-based approaches fast, native math libs + python may be great enough because nearly all the time is spent in the math part) on HUGE datasets, etc, etc pretty much any system involving long list- or set-like types with a decent level of complexity. Most other languages enforce far too much indirection, padding et. al for collection types. Especially generics fail miserably compared to templates for that particular matter. C, on the other hand, will make everything MUCH harder. Especially proper use of RAII and (const) references allow (almost) zero overhead and almost no error-prone pointers (especially zero pointer arithmetic) in the whole system.
- CrLf 14y ago
  I wasn't saying that C++ had no use. I'm saying that its domain is narrower that what's commonly believed. It is false that C "will make everything MUCH harder". How hard something is to implement in a particular language depends on the problem and the people doing the implementation. C is only perceived to be much harder because people have become overly-dependent on language features (aka "syntactic sugar") and cannot reason about problems in terms that do not require those features. I'm not talking about using assembly here. It is not a matter of an unstructured language vs. a structured one. I'm talking about features. This is particularly relevant because in many places where C++ is used, the coding standards prohibit the use of more than a limited subset of the language, effectively transforming it into "C with classes".

option_greek 14y ago

Unfortunately as the number of new projects involving C++ keeps going down, the fields in which C++ jobs are available are getting narrower every year. Almost all middleware is now written in Java. C# took over the frontend development on Windows. New openings in C++ seem limited to quant fields (bank backends on linux) and driver development.

reddit_clone 14y ago
> Almost all middleware is now written in Java. That is a bit worrying with Oracle's recent shenanigans with Java copyright. I wonder what people like Rich Hicky and Martin Odersky have to say about this subject.
NickPollard 14y ago
And Games. AAA game dev (for PC and Console) is almost entirely C++, with some embedded scripting languages (normally Lua, for performance reasons).

tseabrooks 14y ago

As a long time C++ / C programmer I love every feature here... except one. I really abhor the new auto keyword. Perhaps it's personal taste (I also dislike the "Var" in JS). It really seems to make the code harder to follow with only minimal advantages (that I can see / use/ etc).

16s 14y ago
While I understand the reason for auto, and see the benefit in less typing, etc, I still do it the old-fashioned waytoo. I prefer be explicit.

k4st 14y ago

One of the reasons I like C++ is that it lets you throw away type safety and still maintain it through abstraction. This sounds awful, so let me explain. In one project, I implemented an EDSL for performing a destructuring bind on a string (CFG production, actually). The types of the components of the pattern determined what the pattern would actually match. This was all done in a previous version of C++, so I didn't have variadic templates available. I also didn't want to heap allocate the internals of patterns. What I did was to store an array of void pointers and a function pointer as private fields within a pattern class. When constructing the pattern, pointers to the things to which parts of the string to be bound were put into the array, thus throwing away their types. BUT, the function pointer pointed to a static method in of a class template, which only operated on the array of void pointers in a type-safe way, precisely because it was compiled with the knowledge of the types. I use this type of subversion when appropriate, and it's often a very convenient solution to an otherwise tricky problem. Such a thing would either not be possible--or be incredibly inconvenient--in C. It's often very useful to treat different stuff uniformly, knowing that your abstractions can maintain type safety.