5 ms·

Well at the risk of stating the obvious, there's a lot of armchair programmer style "read this", "watch this" instruction here. It's much better to do something

Well at the risk of stating the obvious, there's a lot of armchair programmer style "read this", "watch this" instruction here. It's much better to do something concrete. Go and do a trivial project in it, cppreference.com and cplusplus.com have c++11 tags on the new features. I'm sure you've had ideas recently and I'm sure the project is less trivial than you thought! I think looking at language features first is "a solution looking for a problem" attitude.

to3m 12y ago
People who learn C++ this way tend to miss stuff out, I think - there are a lot of thing that you can just muddle your way though without really understanding. I'm sure there are some people that think this will be OK; after all, lots of people say you don't really have to understand templates unless you're writing a library (and so on). But I don't think it will be OK. There was very little in C++98 (that I knew well, at the time) that it was OK not to know; unless you knew all of it, pretty much, you couldn't really use any of it safely. (This is how Scott Meyers makes his living.) I can't imagine C++11 will be any different; I might not know it well, but I do note that it has many of the same people behind it.
- throwawayaway 12y ago
  obviously we disagree! i think it's ok to miss out on language features. templates, as you say yourself you're ok not to know. you're also not ok not to know exceptions. there's other stuff too, you can get away without the C preprocessor. C++ is too big to know all of and it's a waste of time to invest time trying to, unless you are on a standards committee or are writing a compiler...(and even then you can get away with being a specialist!). it's much better to be a program writer than a language lawyer and dare I say it: more satisfying too. i draw a huge distinction between people that understand a language and people that can use a language, and i think people underestimate the time and effort in understanding a language. i think that time and effort could be better spent writing programs.
  - egwor 12y ago
    I agree; sometimes you have to start somewhere. Then come back and improve knowledge. Trying to be a theoretical expert early on will bite you
    - danieldk 12y ago
      The thing is that most of the things that your parent mentions are not just some theory. Exceptions, templates, and the C preprocessor are used in most real-life C++ code. I think starting from somewhere with modern C++ means not starting at C strings, arrays, and bare pointers but starting with STL containers, STL algorithms, and smart pointers etc. to build good habits. But eventually any good introduction has to cover C arrays etc. as well. Back when I started C++, Accelerated C++ was that sort of introduction. But AFAIK it's not updated for C++ 11 or 14.
      - throwawayaway 12y ago
        I agree that picking a subset is the way to go. Google avoid two out of the three i mentioned that you take issue with avoiding. Places I have worked the code is divided into libraries and coding standards per library are different to the whole. The point is to lazily learn the part that the codebase you are working on uses and get cracking rather than waste time getting book smart on parts you may never use.
  - danieldk 12y ago
    unless you are on a standards committee or are writing a compiler... Or you work on an existing codebase. Most C++ code that I worked on had templates, exceptions, and used the C preprocessor. I used to have your attitude. This works for many languages, e.g. if you know some of the syntax of Python or Go and the usual stuff from the standard library, you can get pretty far. If you want to write modern C++, this is not really true. You need to know about const correctness, lifetimes, some templates, etc. Or you cannot deal with most projects or libraries, like Boost, Eigen, etc. It's like saying you can program Haskell in 2014 without knowing typeclasses, lenses, GADTs, etc. You can write some educational form of Haskell, sure. But many libraries use these.
- angersock 12y ago
  unless you knew all of it, pretty much, you couldn't really use any of it safely. Thank you for perhaps the best summation of everything wrong with using C++ in a project, and everything wrong with C++ as a language!
  - throwawayaway 12y ago
    i also disagree with that statement, while amusing, it's untrue. you can use C++ without the things I have mentioned quite safely. in fact the less features you use, the less they interact and the safer the whole experience is.
    - angersock 12y ago
      You know what we call (C++)--? C. :)
      - throwawayaway 12y ago
        you should actually preincrement there to avoid the copy constructor, the correct formulations is (++C)--
        angersock 12y ago
        How do you know that my preincrement and postincrement are the same? ;) Well played, at any rate.
ctb_mg 12y ago
I think you make a very valid point and I would agree to an extent. However I wouldn't discount the value in seeking to understand the personality and capabilities of a language as it evolves over time. I think of any language as another tool in my toolbox. The better I know a tool, the better I know when and how to apply it to a specific problem. I'd wager that just one trivial project won't fully demonstrate the personality and capabilities of a language.
- throwawayaway 12y ago
  absolutely, but I think acquiring knowledge by reading a 500 page book dutifully is a time sink. much better to get a touristic overview and solve actual problems rather than trying to get book smart.
fredophile 12y ago
I think the correct approach is a mix. I firmly believe that one of the things that makes good programmers good is developing the correct habits. Once something has been ingrained as a habit you don't even think about it any more and just do it. I'd take a book like Scott Meyer's new Effective Modern C++ book (which I recommend) and focus on applying one item every week. At the start of the week read through the item. Every time you write code for that week make an effort to see if that item applies to what you're doing. Maybe read the item again midweek or towards the end of the week to see if the practical experience changes your view on what he wrote. The book contains 42 items so if you go through it like this you'd be done in less than a year. I'm not saying that people shouldn't read the whole book at once. However, if you just read it through once and put it on the shelf I don't think you'll get the same benefit that you would get from spending time focusing on individual areas.

to3m 12y ago

People who learn C++ this way tend to miss stuff out, I think - there are a lot of thing that you can just muddle your way though without really understanding. I'm sure there are some people that think this will be OK; after all, lots of people say you don't really have to understand templates unless you're writing a library (and so on). But I don't think it will be OK. There was very little in C++98 (that I knew well, at the time) that it was OK not to know; unless you knew all of it, pretty much, you couldn't really use any of it safely. (This is how Scott Meyers makes his living.) I can't imagine C++11 will be any different; I might not know it well, but I do note that it has many of the same people behind it.

throwawayaway 12y ago
obviously we disagree! i think it's ok to miss out on language features. templates, as you say yourself you're ok not to know. you're also not ok not to know exceptions. there's other stuff too, you can get away without the C preprocessor. C++ is too big to know all of and it's a waste of time to invest time trying to, unless you are on a standards committee or are writing a compiler...(and even then you can get away with being a specialist!). it's much better to be a program writer than a language lawyer and dare I say it: more satisfying too. i draw a huge distinction between people that understand a language and people that can use a language, and i think people underestimate the time and effort in understanding a language. i think that time and effort could be better spent writing programs.
- egwor 12y ago
  I agree; sometimes you have to start somewhere. Then come back and improve knowledge. Trying to be a theoretical expert early on will bite you
  - danieldk 12y ago
    The thing is that most of the things that your parent mentions are not just some theory. Exceptions, templates, and the C preprocessor are used in most real-life C++ code. I think starting from somewhere with modern C++ means not starting at C strings, arrays, and bare pointers but starting with STL containers, STL algorithms, and smart pointers etc. to build good habits. But eventually any good introduction has to cover C arrays etc. as well. Back when I started C++, Accelerated C++ was that sort of introduction. But AFAIK it's not updated for C++ 11 or 14.
    - throwawayaway 12y ago
      I agree that picking a subset is the way to go. Google avoid two out of the three i mentioned that you take issue with avoiding. Places I have worked the code is divided into libraries and coding standards per library are different to the whole. The point is to lazily learn the part that the codebase you are working on uses and get cracking rather than waste time getting book smart on parts you may never use.
- danieldk 12y ago
  unless you are on a standards committee or are writing a compiler... Or you work on an existing codebase. Most C++ code that I worked on had templates, exceptions, and used the C preprocessor. I used to have your attitude. This works for many languages, e.g. if you know some of the syntax of Python or Go and the usual stuff from the standard library, you can get pretty far. If you want to write modern C++, this is not really true. You need to know about const correctness, lifetimes, some templates, etc. Or you cannot deal with most projects or libraries, like Boost, Eigen, etc. It's like saying you can program Haskell in 2014 without knowing typeclasses, lenses, GADTs, etc. You can write some educational form of Haskell, sure. But many libraries use these.
angersock 12y ago
unless you knew all of it, pretty much, you couldn't really use any of it safely. Thank you for perhaps the best summation of everything wrong with using C++ in a project, and everything wrong with C++ as a language!
- throwawayaway 12y ago
  i also disagree with that statement, while amusing, it's untrue. you can use C++ without the things I have mentioned quite safely. in fact the less features you use, the less they interact and the safer the whole experience is.
  - angersock 12y ago
    You know what we call (C++)--? C. :)
    - throwawayaway 12y ago
      you should actually preincrement there to avoid the copy constructor, the correct formulations is (++C)--
      - angersock 12y ago
        How do you know that my preincrement and postincrement are the same? ;) Well played, at any rate.

ctb_mg 12y ago

I think you make a very valid point and I would agree to an extent. However I wouldn't discount the value in seeking to understand the personality and capabilities of a language as it evolves over time. I think of any language as another tool in my toolbox. The better I know a tool, the better I know when and how to apply it to a specific problem. I'd wager that just one trivial project won't fully demonstrate the personality and capabilities of a language.

throwawayaway 12y ago
absolutely, but I think acquiring knowledge by reading a 500 page book dutifully is a time sink. much better to get a touristic overview and solve actual problems rather than trying to get book smart.

fredophile 12y ago

I think the correct approach is a mix. I firmly believe that one of the things that makes good programmers good is developing the correct habits. Once something has been ingrained as a habit you don't even think about it any more and just do it. I'd take a book like Scott Meyer's new Effective Modern C++ book (which I recommend) and focus on applying one item every week. At the start of the week read through the item. Every time you write code for that week make an effort to see if that item applies to what you're doing. Maybe read the item again midweek or towards the end of the week to see if the practical experience changes your view on what he wrote. The book contains 42 items so if you go through it like this you'd be done in less than a year. I'm not saying that people shouldn't read the whole book at once. However, if you just read it through once and put it on the shelf I don't think you'll get the same benefit that you would get from spending time focusing on individual areas.