7 ms·

I tend to think the new C++ is apt for a new project with no historical burden. We can always use the more modern features. However this may not hold true for e

I tend to think the new C++ is apt for a new project with no historical burden. We can always use the more modern features. However this may not hold true for existing projects with a number of developers

meaty 14y ago
Except that's not how it works. The realistically high skilled C++ people are far and few between so you end up with a shit crock cludged together out of vaguely bastardised MFC'ish code, knotted with Win32 and ATL and Boost with a load of "features which were too dangerous to use" removed. C++ has such a bad legacy, it's going to be really hard to shake off the bad old days. Perhaps in time when the newer generations actually have been using C++11 for a while, but not for at least 5-10 years if you ask me.
- rerere 14y ago
  We could start with a little honesty. Perhaps the C++ zealots could explain to us how the great new features they promoted for so long were actually a crock of shit. Things like auto_ptr, throw specifications, the export keyword and so forth were promoted as the bee's knees. It's funny how they love to criticize C and its "evil arrays and pointers", but never admit their own mistakes. And they've made so many, so many more than C ever did.
  - andrewcooke 14y ago
    toning down the rhetoric, a good "modern c++" book would be awesome - something that shows how to use a solid, simple core with the latest features in, say, the first half, and then has further chapters extending that with more complex approaches where needed. i've asked for this kind of thing before,but never had a really good suggestion. seems like it could be a huge seller... [when i last asked here what, 6 months ago, i think the only vaguely useful answer i got was to read the draft standard]
    - Nursie 14y ago
      This sort of thing would be extremely useful for me at the moment. I have a new role starting in a month or so, with a lot of green-field C++ development work. I'm happy with OO concepts and have extended a variety of pre-existing C++ in my time, but my main body of knowledge is most definitely C. Can anyone recommend a quick-start guide to modern(ish) C++ for the experienced C developer?
      - zeugma 14y ago
        C++ Primer was updated to C++11. http://www.amazon.com/Primer-5th-Edition-Stanley-Lippman/dp/0321714113/ref=dp_ob_title_bk http://www.amazon.com/Primer-5th-Edition-Stanley-Lippman/dp/... The C++ FAQ is really helpful but doesn't seem to be updated to C++11 http://www.parashift.com/c++-faq/ http://www.parashift.com/c++-faq/ Fortunately you can refer to Stroustrup's FAQ about C++11 http://www.stroustrup.com/C++11FAQ.html http://www.stroustrup.com/C++11FAQ.html For reference (like libc manpage, basic usage, which header to include): http://en.cppreference.com/ http://en.cppreference.com/
      - drothlis 14y ago
        If you're coming from C, then you need to understand the STL's concepts of "Concepts", "Modeling", "Refinement", and Iterators etc: http://www.sgi.com/tech/stl/index.html http://www.sgi.com/tech/stl/index.html (that link doesn't cover C++11, nor even the STL additions in C++03 and TR1; but it is still essential background reading). When some people say "Modern C++" they mean template meta-programming (traits, partial template specialisation, etc) as exemplified by Alexandrescu's book "Modern C++ design": http://www.amazon.com/Modern-Design-Generic-Programming-Patterns/dp/0201704315 http://www.amazon.com/Modern-Design-Generic-Programming-Patt... (note that I am not necessarily advocating such techniques, but understanding them will certainly help when you run across them in the wild).
      - shawn-butler 14y ago
        "Welcome Back to C++ (Modern C++)" while not a book is not a bad place to start (I posted the link earlier in a prior comment, sorry for the dup): http://msdn.microsoft.com/en-us/library/hh279654.aspx http://msdn.microsoft.com/en-us/library/hh279654.aspx
  - CJefferson 14y ago
    Where are you getting these ideas from? Who are these C++ zealots you have been listening to? Certainly no-one I talk to. No-one thinks auto_ptr was a great thing. It was a tool, which could be used with care, but for years most books have said "don't use auto_ptr". Throw specifications are... throw specifications. Some people like them, over time it has turned out they don't scale too well. Java has gone through a very similar process. I don't get why you were so angry about them. I don't know why you think anyone thought export was the bee's knees, it's never been available in any of the major compilers since introduction. In particular, I think everyone agrees export and auto_ptr were bad ideas. That's what literally everyone I hear talk about them says. I don't get why you think these mistakes aren't admitted?
    - saurik 14y ago
      (In a way this is off-topic, but I feel the need to point out that the throws() specifiers in C++ are not like Java's: they are more like a runtime assertion that "if this function throws something not in this set of types, terminate my program"; the result is a situation where you gain nothing at compile time, force an on-some-architectures-painfully-slow exception check on the function, and in the end find yourself with a very similar result to having just not caught the exception at all. This particular C++ feature was sufficiently useless as to be downright harmful. The Java feature, by comparison, has some defensible merit ;P.) To say something more on-topic: as someone who has been programming in C++ for 15 years, I agree with your comments regarding how C++'a community typically admits the things it sucks at, and is rather pragmatic about the whole thing. (You kind of have to be with a kitchen-sink language like C++ ;P.)
    - betterunix 14y ago
      On the other hand, when I talk about the problems with exceptions in C++, the C++ zealots come out in force. Rather than admit that C++ does exceptions the wrong way, they (a) point to other languages as having the same problem (b) claim that exceptions should not be used in cases where the problems are problems and (c) accuse you of not really understanding what exceptions, destructors, constructors, and object oriented programming are about. Rather than fix the problems with C++ exception in C++11, the standards committee further cemented those problems.
- wslh 14y ago
  Beyond the complexity of C++ I think one of the biggest problems with it is the lack of self sufficient standard libraries. There was always something extra that needs to be done. For example, simple things like converting a string to a number involves more thinking and knowledge (using string streams) that what is really necessary.
  - CJefferson 14y ago
    I agree entirely. The one thing which is pushing me from C++ to Haskell is cabal, and a large selection of easy-to-install libraries. One thing that makes this hard in C++ of course is people tend to get annoyed if libraries don't work with clang, g++ and a recent visual studio. Even then you have the problem of older g++ and old visual studio, and then esoteric compilers. In Haskell on the other hand people tend to always be running a recent version of ghc.
  - ksherlock 14y ago
    c++11 includes std::string/number conversion. eg: int stoi(const std::string& str, size_t *pos = 0, int base = 10); std::string to_string(int value); http://en.cppreference.com/w/cpp/string/basic_string http://en.cppreference.com/w/cpp/string/basic_string
    - wslh 14y ago
      But it's 2012! it's late.
- Shorel 14y ago
  Actually, in that case you would use wxWidgets instead of any MFC&Win32. Or some Qt with its non-standard metacompiler. But yes, that can be considered bad legacy stuff.
kybernetyk 14y ago
We were lucky enough to start a new project ~1 year ago - completely in C++11. We make heavy use of all the new fun C++11 stuff like lambdas, move constructors (yay, no vectors of pointers anymore!) and all that auto/decltype syntactic sugar. And I must say: It's a whole different programming language and a new level of productivity.
- forrestthewoods 14y ago
  Depending on move constructors scare the bajeezus out of me because I have no way of knowing if it's working properly. It's behavior is also implementation specific. Given the following test you'll get a variety of results depending on your platform. struct Foo{...} std::vector<Foo> vec; for( int i = 0; i < 10; ++i) { vec.push_back( Foo() ); } Results: 35 move / 25 copy / 10 move + 15 copy / 25 move. It all depends on your compiler and STL implementation. Not knowing scares the hell out of me.
  - shawn-butler 14y ago
    I don't understand your comment. Please try the following: vec.reserve(10); and report back how many allocations occur.
  - CJefferson 14y ago
    I assume what you are saying is the following? * Compilers are introducing move as we move in C++11. If you compile your code in C++03 (or a compiler with partial C++11 support, no move). * The standard doesn't place a strict definition on how vectors are increased in size as you push_back. Of course, if you want to control the amount of space in a vector manually, rather than let your compiler decide, you can reserve in advance. Is your problem just with moving to C++11, or do you get different numbers (other than different numbers of moves) in a compiler with proper C++11 support (basically, the most recent version of everything).
  - ksherlock 14y ago
    You could also look into emplace_back() http://en.cppreference.com/w/cpp/container/vector/emplace_back http://en.cppreference.com/w/cpp/container/vector/emplace_ba...
betterunix 14y ago
I disagree entirely. I would say that C++ should be treated like COBOL: useful only to maintain legacy code that nobody has the time or money to rewrite in a better language. C++ is a mess, and C++11 has done little to make C++ less of a mess.
- pjmlp 14y ago
  Ah that must be the reason why gcc migrated their codebase to C++!

meaty 14y ago

Except that's not how it works. The realistically high skilled C++ people are far and few between so you end up with a shit crock cludged together out of vaguely bastardised MFC'ish code, knotted with Win32 and ATL and Boost with a load of "features which were too dangerous to use" removed. C++ has such a bad legacy, it's going to be really hard to shake off the bad old days. Perhaps in time when the newer generations actually have been using C++11 for a while, but not for at least 5-10 years if you ask me.

rerere 14y ago
We could start with a little honesty. Perhaps the C++ zealots could explain to us how the great new features they promoted for so long were actually a crock of shit. Things like auto_ptr, throw specifications, the export keyword and so forth were promoted as the bee's knees. It's funny how they love to criticize C and its "evil arrays and pointers", but never admit their own mistakes. And they've made so many, so many more than C ever did.
- andrewcooke 14y ago
  toning down the rhetoric, a good "modern c++" book would be awesome - something that shows how to use a solid, simple core with the latest features in, say, the first half, and then has further chapters extending that with more complex approaches where needed. i've asked for this kind of thing before,but never had a really good suggestion. seems like it could be a huge seller... [when i last asked here what, 6 months ago, i think the only vaguely useful answer i got was to read the draft standard]
  - Nursie 14y ago
    This sort of thing would be extremely useful for me at the moment. I have a new role starting in a month or so, with a lot of green-field C++ development work. I'm happy with OO concepts and have extended a variety of pre-existing C++ in my time, but my main body of knowledge is most definitely C. Can anyone recommend a quick-start guide to modern(ish) C++ for the experienced C developer?
    - zeugma 14y ago
      C++ Primer was updated to C++11. http://www.amazon.com/Primer-5th-Edition-Stanley-Lippman/dp/0321714113/ref=dp_ob_title_bk http://www.amazon.com/Primer-5th-Edition-Stanley-Lippman/dp/... The C++ FAQ is really helpful but doesn't seem to be updated to C++11 http://www.parashift.com/c++-faq/ http://www.parashift.com/c++-faq/ Fortunately you can refer to Stroustrup's FAQ about C++11 http://www.stroustrup.com/C++11FAQ.html http://www.stroustrup.com/C++11FAQ.html For reference (like libc manpage, basic usage, which header to include): http://en.cppreference.com/ http://en.cppreference.com/
    - drothlis 14y ago
      If you're coming from C, then you need to understand the STL's concepts of "Concepts", "Modeling", "Refinement", and Iterators etc: http://www.sgi.com/tech/stl/index.html http://www.sgi.com/tech/stl/index.html (that link doesn't cover C++11, nor even the STL additions in C++03 and TR1; but it is still essential background reading). When some people say "Modern C++" they mean template meta-programming (traits, partial template specialisation, etc) as exemplified by Alexandrescu's book "Modern C++ design": http://www.amazon.com/Modern-Design-Generic-Programming-Patterns/dp/0201704315 http://www.amazon.com/Modern-Design-Generic-Programming-Patt... (note that I am not necessarily advocating such techniques, but understanding them will certainly help when you run across them in the wild).
    - shawn-butler 14y ago
      "Welcome Back to C++ (Modern C++)" while not a book is not a bad place to start (I posted the link earlier in a prior comment, sorry for the dup): http://msdn.microsoft.com/en-us/library/hh279654.aspx http://msdn.microsoft.com/en-us/library/hh279654.aspx
- CJefferson 14y ago
  Where are you getting these ideas from? Who are these C++ zealots you have been listening to? Certainly no-one I talk to. No-one thinks auto_ptr was a great thing. It was a tool, which could be used with care, but for years most books have said "don't use auto_ptr". Throw specifications are... throw specifications. Some people like them, over time it has turned out they don't scale too well. Java has gone through a very similar process. I don't get why you were so angry about them. I don't know why you think anyone thought export was the bee's knees, it's never been available in any of the major compilers since introduction. In particular, I think everyone agrees export and auto_ptr were bad ideas. That's what literally everyone I hear talk about them says. I don't get why you think these mistakes aren't admitted?
  - saurik 14y ago
    (In a way this is off-topic, but I feel the need to point out that the throws() specifiers in C++ are not like Java's: they are more like a runtime assertion that "if this function throws something not in this set of types, terminate my program"; the result is a situation where you gain nothing at compile time, force an on-some-architectures-painfully-slow exception check on the function, and in the end find yourself with a very similar result to having just not caught the exception at all. This particular C++ feature was sufficiently useless as to be downright harmful. The Java feature, by comparison, has some defensible merit ;P.) To say something more on-topic: as someone who has been programming in C++ for 15 years, I agree with your comments regarding how C++'a community typically admits the things it sucks at, and is rather pragmatic about the whole thing. (You kind of have to be with a kitchen-sink language like C++ ;P.)
  - betterunix 14y ago
    On the other hand, when I talk about the problems with exceptions in C++, the C++ zealots come out in force. Rather than admit that C++ does exceptions the wrong way, they (a) point to other languages as having the same problem (b) claim that exceptions should not be used in cases where the problems are problems and (c) accuse you of not really understanding what exceptions, destructors, constructors, and object oriented programming are about. Rather than fix the problems with C++ exception in C++11, the standards committee further cemented those problems.
wslh 14y ago
Beyond the complexity of C++ I think one of the biggest problems with it is the lack of self sufficient standard libraries. There was always something extra that needs to be done. For example, simple things like converting a string to a number involves more thinking and knowledge (using string streams) that what is really necessary.
- CJefferson 14y ago
  I agree entirely. The one thing which is pushing me from C++ to Haskell is cabal, and a large selection of easy-to-install libraries. One thing that makes this hard in C++ of course is people tend to get annoyed if libraries don't work with clang, g++ and a recent visual studio. Even then you have the problem of older g++ and old visual studio, and then esoteric compilers. In Haskell on the other hand people tend to always be running a recent version of ghc.
- ksherlock 14y ago
  c++11 includes std::string/number conversion. eg: int stoi(const std::string& str, size_t *pos = 0, int base = 10); std::string to_string(int value); http://en.cppreference.com/w/cpp/string/basic_string http://en.cppreference.com/w/cpp/string/basic_string
  - wslh 14y ago
    But it's 2012! it's late.
Shorel 14y ago
Actually, in that case you would use wxWidgets instead of any MFC&Win32. Or some Qt with its non-standard metacompiler. But yes, that can be considered bad legacy stuff.

kybernetyk 14y ago

We were lucky enough to start a new project ~1 year ago - completely in C++11. We make heavy use of all the new fun C++11 stuff like lambdas, move constructors (yay, no vectors of pointers anymore!) and all that auto/decltype syntactic sugar. And I must say: It's a whole different programming language and a new level of productivity.

forrestthewoods 14y ago
Depending on move constructors scare the bajeezus out of me because I have no way of knowing if it's working properly. It's behavior is also implementation specific. Given the following test you'll get a variety of results depending on your platform. struct Foo{...} std::vector<Foo> vec; for( int i = 0; i < 10; ++i) { vec.push_back( Foo() ); } Results: 35 move / 25 copy / 10 move + 15 copy / 25 move. It all depends on your compiler and STL implementation. Not knowing scares the hell out of me.
- shawn-butler 14y ago
  I don't understand your comment. Please try the following: vec.reserve(10); and report back how many allocations occur.
- CJefferson 14y ago
  I assume what you are saying is the following? * Compilers are introducing move as we move in C++11. If you compile your code in C++03 (or a compiler with partial C++11 support, no move). * The standard doesn't place a strict definition on how vectors are increased in size as you push_back. Of course, if you want to control the amount of space in a vector manually, rather than let your compiler decide, you can reserve in advance. Is your problem just with moving to C++11, or do you get different numbers (other than different numbers of moves) in a compiler with proper C++11 support (basically, the most recent version of everything).
- ksherlock 14y ago
  You could also look into emplace_back() http://en.cppreference.com/w/cpp/container/vector/emplace_back http://en.cppreference.com/w/cpp/container/vector/emplace_ba...

betterunix 14y ago

I disagree entirely. I would say that C++ should be treated like COBOL: useful only to maintain legacy code that nobody has the time or money to rewrite in a better language. C++ is a mess, and C++11 has done little to make C++ less of a mess.

pjmlp 14y ago
Ah that must be the reason why gcc migrated their codebase to C++!