6 ms·

I’m not a C++ dev. I took one class of it in college and even then it was 90% C and only hit pointers and classes on the final unit. But holy smokes this is no

I’m not a C++ dev. I took one class of it in college and even then it was 90% C and only hit pointers and classes on the final unit. But holy smokes this is not your grandmother’s C++, is it just me or is the language trying to be all things to all people? It’s getting too big, no? I mean how long do you have to be writing C++ code to fully master the language? Or can you be a high level dev without ever touching the new features? I’m assuming production codebases are likely still stuck on older versions of the language and might never move on. I hope golang doesn’t grow this large over time.

sp332 7y ago
Oh yeah, C++ has been huge for decades. You pick a subset and program in that. The changes in C++11 had structural implications that took years to work through which is why it was late. The working name was C++0x because they expected to release it in '08 or maybe '09. http://www.stroustrup.com/C++11FAQ.html http://www.stroustrup.com/C++11FAQ.html
- noobermin 7y ago
  This is what people say, how will C++ then not turn out like lisp then? Lisp became so idiomatic that people couldn't share code.
  - kazinator 7y ago
    > Lisp became so idiomatic that people couldn't share code. That is only a false meme spread by non-Lisp programmers.
    - ncmncm 7y ago
      Numerous other reasons explain Lisp's failure to take flight. Nobody agrees on which exactly they are, only that there are plenty of them.
      - noobermin 7y ago
        I feel like this is a sort of meta joke.
- DoofusOfDeath 7y ago
  > Oh yeah, C++ has been huge for decades. You pick a subset and program in that. My impression is that the C++ standards committee sees the standard like a pile of papers on a professor's desk, where most programmers only need to understand what's currently visible on the top. And so they keep on adding papers to the top, they're getting the least-bad combo of innovation and backwards-compatibility. My experience has been different. These days I mostly deal with codebases that are about 50% original C++ code, and 50% third-party code pulled in via CMake "super builds". Even within the first 50% that's ostensibly under the control of a single organization, I find a large variety of C++ coding styles in effect. Continuing with the papers-on-desk metaphor, I generally have to deal with code that draws from the entire stack of papers.
alexhutcheson 7y ago
Yes, it's very complex and hard to stay on top of current best practices. However, every one of the major features listed in this post replace an existing language feature with something that is easier/safer/less verbose. For new code you shouldn't have to use the old features, and you can just rely on the new ones. Existing code is trickier, which is already a problem for large C++ codebases. You'll find dramatically different styles depending on when the code was written. All in all, though, the recent changes have made C++ much more pleasant to program in. They're mostly less complex for an application developer than the things they are replacing, and the really complex bits (concepts, etc.) are only needed for writing complicated template libraries.
- eikenberry 7y ago
  Does anyone know of a mind-map or info-graphic that sort of lays out the new features and which older features they replace. Something to help someone who hasn't looked at C++ in years get a feel for how to map things?
- MadWombat 7y ago
  "every one of the major features listed in this post replace an existing language feature" That is the part that annoys the hell out of me in regards to C++. Nothing ever gets replaced, things just get added on top of everything. And to add to that there is generally very little indication which is the "new, safe and cool way" and which is "old, shoot yourself in the foot" way of doing things. Like std::string is cool and generally you want to use it everywhere... except you can use []char everywhere and be completely unaware that you are doing anything wrong (well, until you segfault on memory access). Or unique_ptr and shared_ptr and auto_ptr. Cool things, but you can use a regular pointer in their place and again, never realize something is wrong (again, until you segfault). And every C++ book I ever saw happily discusses raw pointers and memory allocation and []char strings without ever giving you any warning that under most normal circumstances you should not use any of this.
  - alexhutcheson 7y ago
    Yeah, I agree that part is frustrating - it's very difficult to stay on top of current best practices, especially when even experts (and many "experts") disagree on best practices. The "Nothing ever gets replaced" problem is a direct consequence of the committee's focus on backwards compatibility. That compatibility has been absolutely crucial for the language's continued success. Backwards-incompatible changes would result in even more divergence between the C++ dialect supported by various compilers and compiler versions, and would probably result in an even worse version of the problems that occurred in the Python 2->3 transition. In my experience, the the ABSL "Tip of the Week" posts[1] are a great source for "best practice" info, but they aren't exhaustive, and some are specific to the ABSL libraries, rather than general C++. [1] https://abseil.io/tips/ https://abseil.io/tips/
saagarjha 7y ago
> I mean how long do you have to be writing C++ code to fully master the language? To be honest I don’t think you can ever fully master the language.
- wheels 7y ago
  You could, at one point. C++98 and C++03 were minor updates, meaning C++ had 22 years where learning it wasn't a fast moving target (between C++89 and C++11). I would happily call myself an expert in that dialect of C++, but getting there took 5-10 years. I can't call myself a C++ expert anymore, and, in fact, find it hard for anyone to, because with a language so complex, idioms and best practices aren't evolving at the same rate that the standard is changing, especially in cases where one has to deal with a mix of modern C++ and legacy (C++03 and earlier) C++.
tejohnso 7y ago
I recently started trying to learn c++ and I'd say I've got the basics down. Sometimes I'll watch a talk by Scott Meyers or Jason Turner and realize how little I know, and how deeply complicated things can get. Then I go back to my code base and continue being productive writing useful code. I know it's probably not perfect, but it's still satisfying. As for reaching perfection or mastery, that's an enjoyable journey, even knowing that the final destination is likely unreachable.
asauce 7y ago
One of the worst interview questions I have had was "Rate your C++ knowledge from 1 - 10". I had just finished my second year of college, and although I felt fairly confident in my C++ abilities I had no idea how to answer. I thought it would be best to be honest and said "4" based on the subset of the huge language I knew (honestly this rating was probably too high at the time!). One of the interviewers was obviously unhappy with the answer, and was unpleasant the rest of the interview. I have always wondered what they expected from such an vague question.
- meheleventyone 7y ago
  It’s just a trap to quiz people on language errata when they say a high number the guy would have been just as unpleasant in a different way.
- leetcrew 7y ago
  I agree this is a bad question, but when people ask, they almost always mean relative to your peers. they're not trying to decide whether to hire a summer intern or a senior dev. they just wanted to hear that you were better than most of your classmates.
- noobermin 7y ago
  I guarantee you his/er knowledge was probably a 3 or lower. If this were reddit I would ironically reply they clearly were just jealous of you or didn't believe you had such a well-developed grasp of C++ fresh out of college.
  - asdf9240 7y ago
    If this was reddit, I would reply how it is funny that you imply that you would not say that on hacker news, but you actually did indirectly
- ksec 7y ago
  >One of the worst interview questions I have had was "Rate your C++ knowledge from 1 - 10". >One of the interviewers was obviously unhappy with the answer, and was unpleasant the rest of the interview. I have always wondered what they expected from such an vague question. I knew enough of C++ to know my knowledge on the subject is approximately close to Zero. Basically no one on earth knows C++, they mostly know a subset of it. *C++ here referring to Modern C++, Pre 2000 era C++ was still manageable. Edit: On that thought it seems to me every PL in 90s were all manageable. Somewhere along the line things got ugly.
agumonkey 7y ago
I don't write cpp but it seemed c++11 and later were almost shrinking.
gumby 7y ago
> is it just me or is the language trying to be all things to all people? Well yes, in the sense that it's a systems programming language designed not to be a single-paradigm language (you can write procedural, or somewhat functional, or classic OOP, or generic functions-based OOP) and to be very efficient at all. Some of the features are seemingly arcane in order to preserve the zero-cost abstraction approach as much as possible. > Or can you be a high level dev without ever touching the new features? So some features are arcane as I wrote above but some are deliberately high level, designed to make it easier to write safe, efficient high-level code without getting into the weeds. Being able to type for (auto& a_frob : from_manager) ... and have it be fast, efficient and not leak memory is a feature, right? > I hope golang doesn’t grow this large over time. Go's explicit design goals are the opposite: have only a few constructs, a specific "opinion" as to how things should be done, and to deliberately limit expressiveness in favor of other objectives. So I doubt it will come close. Edit: I don't agree with go's design criteria, but I respect them.

sp332 7y ago

Oh yeah, C++ has been huge for decades. You pick a subset and program in that. The changes in C++11 had structural implications that took years to work through which is why it was late. The working name was C++0x because they expected to release it in '08 or maybe '09. http://www.stroustrup.com/C++11FAQ.html http://www.stroustrup.com/C++11FAQ.html

noobermin 7y ago
This is what people say, how will C++ then not turn out like lisp then? Lisp became so idiomatic that people couldn't share code.
- kazinator 7y ago
  > Lisp became so idiomatic that people couldn't share code. That is only a false meme spread by non-Lisp programmers.
  - ncmncm 7y ago
    Numerous other reasons explain Lisp's failure to take flight. Nobody agrees on which exactly they are, only that there are plenty of them.
    - noobermin 7y ago
      I feel like this is a sort of meta joke.
DoofusOfDeath 7y ago
> Oh yeah, C++ has been huge for decades. You pick a subset and program in that. My impression is that the C++ standards committee sees the standard like a pile of papers on a professor's desk, where most programmers only need to understand what's currently visible on the top. And so they keep on adding papers to the top, they're getting the least-bad combo of innovation and backwards-compatibility. My experience has been different. These days I mostly deal with codebases that are about 50% original C++ code, and 50% third-party code pulled in via CMake "super builds". Even within the first 50% that's ostensibly under the control of a single organization, I find a large variety of C++ coding styles in effect. Continuing with the papers-on-desk metaphor, I generally have to deal with code that draws from the entire stack of papers.

alexhutcheson 7y ago

Yes, it's very complex and hard to stay on top of current best practices. However, every one of the major features listed in this post replace an existing language feature with something that is easier/safer/less verbose. For new code you shouldn't have to use the old features, and you can just rely on the new ones. Existing code is trickier, which is already a problem for large C++ codebases. You'll find dramatically different styles depending on when the code was written. All in all, though, the recent changes have made C++ much more pleasant to program in. They're mostly less complex for an application developer than the things they are replacing, and the really complex bits (concepts, etc.) are only needed for writing complicated template libraries.

eikenberry 7y ago
Does anyone know of a mind-map or info-graphic that sort of lays out the new features and which older features they replace. Something to help someone who hasn't looked at C++ in years get a feel for how to map things?
MadWombat 7y ago
"every one of the major features listed in this post replace an existing language feature" That is the part that annoys the hell out of me in regards to C++. Nothing ever gets replaced, things just get added on top of everything. And to add to that there is generally very little indication which is the "new, safe and cool way" and which is "old, shoot yourself in the foot" way of doing things. Like std::string is cool and generally you want to use it everywhere... except you can use []char everywhere and be completely unaware that you are doing anything wrong (well, until you segfault on memory access). Or unique_ptr and shared_ptr and auto_ptr. Cool things, but you can use a regular pointer in their place and again, never realize something is wrong (again, until you segfault). And every C++ book I ever saw happily discusses raw pointers and memory allocation and []char strings without ever giving you any warning that under most normal circumstances you should not use any of this.
- alexhutcheson 7y ago
  Yeah, I agree that part is frustrating - it's very difficult to stay on top of current best practices, especially when even experts (and many "experts") disagree on best practices. The "Nothing ever gets replaced" problem is a direct consequence of the committee's focus on backwards compatibility. That compatibility has been absolutely crucial for the language's continued success. Backwards-incompatible changes would result in even more divergence between the C++ dialect supported by various compilers and compiler versions, and would probably result in an even worse version of the problems that occurred in the Python 2->3 transition. In my experience, the the ABSL "Tip of the Week" posts[1] are a great source for "best practice" info, but they aren't exhaustive, and some are specific to the ABSL libraries, rather than general C++. [1] https://abseil.io/tips/ https://abseil.io/tips/

saagarjha 7y ago

> I mean how long do you have to be writing C++ code to fully master the language? To be honest I don’t think you can ever fully master the language.

wheels 7y ago
You could, at one point. C++98 and C++03 were minor updates, meaning C++ had 22 years where learning it wasn't a fast moving target (between C++89 and C++11). I would happily call myself an expert in that dialect of C++, but getting there took 5-10 years. I can't call myself a C++ expert anymore, and, in fact, find it hard for anyone to, because with a language so complex, idioms and best practices aren't evolving at the same rate that the standard is changing, especially in cases where one has to deal with a mix of modern C++ and legacy (C++03 and earlier) C++.

tejohnso 7y ago

I recently started trying to learn c++ and I'd say I've got the basics down. Sometimes I'll watch a talk by Scott Meyers or Jason Turner and realize how little I know, and how deeply complicated things can get. Then I go back to my code base and continue being productive writing useful code. I know it's probably not perfect, but it's still satisfying. As for reaching perfection or mastery, that's an enjoyable journey, even knowing that the final destination is likely unreachable.

asauce 7y ago

One of the worst interview questions I have had was "Rate your C++ knowledge from 1 - 10". I had just finished my second year of college, and although I felt fairly confident in my C++ abilities I had no idea how to answer. I thought it would be best to be honest and said "4" based on the subset of the huge language I knew (honestly this rating was probably too high at the time!). One of the interviewers was obviously unhappy with the answer, and was unpleasant the rest of the interview. I have always wondered what they expected from such an vague question.

meheleventyone 7y ago
It’s just a trap to quiz people on language errata when they say a high number the guy would have been just as unpleasant in a different way.
leetcrew 7y ago
I agree this is a bad question, but when people ask, they almost always mean relative to your peers. they're not trying to decide whether to hire a summer intern or a senior dev. they just wanted to hear that you were better than most of your classmates.
noobermin 7y ago
I guarantee you his/er knowledge was probably a 3 or lower. If this were reddit I would ironically reply they clearly were just jealous of you or didn't believe you had such a well-developed grasp of C++ fresh out of college.
- asdf9240 7y ago
  If this was reddit, I would reply how it is funny that you imply that you would not say that on hacker news, but you actually did indirectly
ksec 7y ago
>One of the worst interview questions I have had was "Rate your C++ knowledge from 1 - 10". >One of the interviewers was obviously unhappy with the answer, and was unpleasant the rest of the interview. I have always wondered what they expected from such an vague question. I knew enough of C++ to know my knowledge on the subject is approximately close to Zero. Basically no one on earth knows C++, they mostly know a subset of it. *C++ here referring to Modern C++, Pre 2000 era C++ was still manageable. Edit: On that thought it seems to me every PL in 90s were all manageable. Somewhere along the line things got ugly.

agumonkey 7y ago

I don't write cpp but it seemed c++11 and later were almost shrinking.

gumby 7y ago

> is it just me or is the language trying to be all things to all people? Well yes, in the sense that it's a systems programming language designed not to be a single-paradigm language (you can write procedural, or somewhat functional, or classic OOP, or generic functions-based OOP) and to be very efficient at all. Some of the features are seemingly arcane in order to preserve the zero-cost abstraction approach as much as possible. > Or can you be a high level dev without ever touching the new features? So some features are arcane as I wrote above but some are deliberately high level, designed to make it easier to write safe, efficient high-level code without getting into the weeds. Being able to type for (auto& a_frob : from_manager) ... and have it be fast, efficient and not leak memory is a feature, right? > I hope golang doesn’t grow this large over time. Go's explicit design goals are the opposite: have only a few constructs, a specific "opinion" as to how things should be done, and to deliberately limit expressiveness in favor of other objectives. So I doubt it will come close. Edit: I don't agree with go's design criteria, but I respect them.