5 ms·

As a talented C++ developer... yes there is a dearth of talented C++ developers. I've been to several C++ conferences. Even there, many of the engineers end up

As a talented C++ developer... yes there is a dearth of talented C++ developers. I've been to several C++ conferences. Even there, many of the engineers end up learning "new" things that are IMO basic concepts that have been around for years. I recently went through a hiring phase for Senior C++ engineers and most of the applicants were familiar with old tech. It was really disheartening to me to realize how many "senior" C++ engineers weren't senior in real C++ experience. Even one of the hires ended up using a C style array in their first commit instead of std::array. It's really frustrating and makes me wonder if perhaps I'm in the wrong job: maybe I shouldn't be a software engineer, maybe I should be a software educator to teach modern concepts and un-teach ancient concepts. Indeed, a lot of the ancient concepts directly contribute to the modern world's problem of software safety.

brnt 4y ago
> C style array in their first commit instead of std::array. In my neck of the C++ woods, neither are a good choice. My point is: C++ is not a language, it is a language group. Most north Europeans speak a Germanic language, which have many shared features and often partially shared dictionaries, yet they mostly won't understand each other without some further study. As a Dutch speaker I can't judge the quality of somebody's German, even though it sometimes feels like I should be able to.
- inetknght 4y ago
  > In my neck of the C++ woods, neither are a good choice. Just off the top of my head: "it's not resizeable" (use a std::vector instead) or "it's allocated on the stack instead of the heap" (you can use a std::unique_ptr<std::array> to put it on the heap). But what are the reasons to not use `std::array` in your neck of the C++ woods? > I can't judge the quality of somebody's German, even though it sometimes feels like I should be able to. The cool part about software languages is that they're implementations of data structures and algorithms. Understanding those gets you most of the way to understanding what the code does regardless of whatever native language is spoken.
thedracle 4y ago
The reality hammer hits quite a bit harder when people are playing the "fake it until you make it" game with C++ versus other languages as well.
WkndTriathlete 4y ago
I can't help but wonder if developers are simply off-put by the complexity of the language itself. Way back in 1989 I was fortunate enough to get Borland's C/C++ compiler, the K&R C book, and Stroustrup's C++ book - which, at the time, was about the same size as the K&R C book. The C++ language was relatively simple to learn at that time: no STL, no odd pointer types, no template metaprogramming, etc. Fast-forward to 1997 and I'm listening to a talk about C++ compilers and hear that templates are now a Turing-complete language, and how the compiler developers used the template language to coerce the compiler into printing out the prime numbers. Fast forward again to 2022 (with trips to Java, Kotlin, Scala, and Haskell in between) and I've got a project that requires JNI and Python bindings to a core C engine. Great, I'll use C++! I proceed to start searching for containers/constructs and realize that at least 50% of the C++ language and standard library is unreadable to me. I only have a guess as to what a `shared_ptr` or `unique_ptr` type is, and I certainly don't know when to use them, and concepts/traits outlined in the STL documentation seem to be some sort of generalizations that the STL might provide default implementations for, but might not? What exactly is the syntax and/or type of a lambda function and how do they interact with C function pointers? etc., etc. I get the sense that C++'s evolution has been driven by esoteric corner cases that a handful of developers have encountered and the language & STL design has been driven by those cases. I'm still surprised by how many problems I can easily address in something like Scala or Haskell that C++ simply does not provide the facilities to express easily.
- olvy0 4y ago
  I'm with you mostly, although as the mostly sole maintainer of an 22 years old and still evolving C++ codebase (among some other responsibilities) I do try to keep up with the language. But if I didn't feel this was necessary for my job I probably wouldn't do it or at least won't sink too much time into it. I've also programmed in Haskell and I've had the same reaction as you, as to the things I can easily express there and not in C++. However I think the 2 cultures (Haskell and C++) are similar in that they both attract people who like to produce clever code which is unreadable to other people, even though the base language is not that complicated. As for your questions: 1) shared_ptr / unique_ptr: Personally I liked this presentation. Watch it on x2 speed until it gets to parts that are difficult for you. https://www.youtube.com/watch?v=xGDLkt-jBJ4 https://www.youtube.com/watch?v=xGDLkt-jBJ4 2) lambdas: https://www.youtube.com/watch?v=3jCOwajNch0 https://www.youtube.com/watch?v=3jCOwajNch0 This is more dense than the previous one. As for your question "how do lambdas interact with C function pointers": rough explanation is they are not the same, since they can possibly allocate memory if they capture. But if they don't capture anything they are just like a (static) function, and can be converted to a function pointer. As for concepts / traits, rough answer is that you don't need to know about them for everyday work, unless you write a library / API for consumption by other C++ developers. In that case, they help the compiler provide better/shorter error messages in case template functions/classes aren't used properly.
ryandrake 4y ago
To be fair and assume competence: A lot of C++ programmers have been burned by adopting the latest and greatest bling, then having to port it to some backwards platform that doesn't have a recent compiler. Many of us use the legacy stuff when possible, because we know it works, there are already robust third party libraries that interoperate with the legacy stuff, and it is more likely to be portable than std::omfgbbq.
- nbjoerg 4y ago
  I find that argument funny, given that Rust can't be updated often enough before every other library breaks.
- sqeaky 4y ago
  This is getting better. Businesses that force a specific compiler for reasons other than technical merit are being punished in the market. I am currently at a not super advanced C++ shop that has to write for several compilers on locked platforms, and even the worst/oldest compilers are clang or gcc forks that support C++17 and some C++20. We have robust CI and if it passes there we can use it (presuming it doesn't violate style guide/best practices/code review/etc). It is unlikely we will be burned by adopting the latest thing for anytime longer one developer is working on it. I think the companies that are so afraid of upgrading software tooling and related processes incurred huge project costs because of otherwise needless major rewrites. One I worked for a college bookstore management software developer that was trying to rewrite their whole point of sale software. They were simply crushed by tech debt. Any fix in the original software took months and the rewrite wasn't finished before the company was bought by a competitor. Better unit tests, better practices staying up to date, better CI all would have contributed to business success.
- thefourthchime 4y ago
  Raises hand. Everyone needs to read "Effective C++", which is mostly a book about how not to shoot yourself in the foot with C++. The book is old enough now that the way he recommends writing C++ wouldn't make it into a PR. So for that reason, I tended to write C+, which is pretty much C+, with some classes.
flohofwoe 4y ago
That's the problem with the C++ ecosystem, it is actually many vastly different ecosystems mashed together. It's impossible to find a "C++ developer" because there is no agreed upon "one C++ style". It seems what you're looking for is a "C++ developer who likes to write the same C++ style as myself" ;)
- inetknght 4y ago
  > It seems what you're looking for is a "C++ developer who likes to write the same C++ style as myself" ;) No, I'm perfectly content with someone writing C++ in a different style. What I'm not content with is someone who uses old code without a technical reason why. C style arrays, for example, are 100% inferior to std::array. Old loops with indices are maybe 80% (off the cuff guesstimate) inferior to ranged-for. There's absolutely no reason whatsoever to use `delete` in any C++ code that doesn't directly handle allocations (and so, very esoteric), and simlarly for `new`. But I keep seeing these things (and many other examples) show up in newly-written C++ code from "experienced" developers. Maybe 90% of the time they'll fix their code when I point out the modern solution and what problems the modern solution solves, and the last 10% of the time ends up in a technical argument about the merit of the old code (and that's fine as long as there is a technical merit for it).
  - flohofwoe 4y ago
    > C style arrays, for example, are 100% inferior to std::array. Are the advantages of std::array over C arrays big enough to add 8kloc to each compilation unit though? (https://www.godbolt.org/z/8noTndhcv https://www.godbolt.org/z/8noTndhcv) A range-checked std::array replacement can probably be written in a few dozen lines of code. That's the problem with all C++ stdlib headers, they are incredibly overengineered for what they bring to the table.
    - inetknght 4y ago
      > Are the advantages of std::array over C arrays big enough to add 8kloc to each compilation unit though? I say yes, absolutely. C style arrays are _very easy_ to get wrong in many ways. Three just off the top of my head: - iterating using a size_t instead of an iterator - calculating the size of the array (and often using a preprocessor macro to do it) - leaving things uninitialized So a std::array provides iterators and works with a ranged-for loop. The only reason to use a size_t is if you truly need an index number (and I would argue: use `std::distance()` instead). A std::array provides a `size()` giving the total number of objects in it. It also provides the type, so you can do sizeof(type) * array.size() -- though that's still error prone. A std::array ensures that objects are correctly initialized. And, if you still need to dangerously decay the data to a pointer, you can use .data() to grab that pointer. > A range-checked std::array replacement can probably be written in a few dozen lines of code. Can you provide an example? > That's the problem with all C++ stdlib headers, they are incredibly overengineered for what they bring to the table. I would argue that the standard library isn't overengineered. It's engineered for more than just your use case. Just because code "is there" doesn't mean that code makes it into your product. Pay for what you use, don't pay for what you don't use.
vips7L 4y ago
I've had the same experience in Java. Experienced engineers that are learning "new" Java even though those features came out years ago. I really think this will be the case for any language. Most people are not the HN type that are going to live and breath programming.
- inetknght 4y ago
  I prefer to be proud that I've never touched Java... for Old Reasons. But that said, it's a valuable language. It's nice to know that other languages have similar problems :)
  - vips7L 4y ago
    I'll probably get down voted, but I honestly really enjoy Java. The language, while it has some legacy verbosity, is in my opinion the perfect balance of simplicity and complexity. It has just enough language features without becoming Scala/Rust/C++ levels of complexity, while still being competitive on performance.
- nbjoerg 4y ago
  The ones on HN that actually work don't have the time to run after every few language feature either ;)

brnt 4y ago

> C style array in their first commit instead of std::array. In my neck of the C++ woods, neither are a good choice. My point is: C++ is not a language, it is a language group. Most north Europeans speak a Germanic language, which have many shared features and often partially shared dictionaries, yet they mostly won't understand each other without some further study. As a Dutch speaker I can't judge the quality of somebody's German, even though it sometimes feels like I should be able to.

inetknght 4y ago
> In my neck of the C++ woods, neither are a good choice. Just off the top of my head: "it's not resizeable" (use a std::vector instead) or "it's allocated on the stack instead of the heap" (you can use a std::unique_ptr<std::array> to put it on the heap). But what are the reasons to not use `std::array` in your neck of the C++ woods? > I can't judge the quality of somebody's German, even though it sometimes feels like I should be able to. The cool part about software languages is that they're implementations of data structures and algorithms. Understanding those gets you most of the way to understanding what the code does regardless of whatever native language is spoken.

thedracle 4y ago

The reality hammer hits quite a bit harder when people are playing the "fake it until you make it" game with C++ versus other languages as well.

WkndTriathlete 4y ago

I can't help but wonder if developers are simply off-put by the complexity of the language itself. Way back in 1989 I was fortunate enough to get Borland's C/C++ compiler, the K&R C book, and Stroustrup's C++ book - which, at the time, was about the same size as the K&R C book. The C++ language was relatively simple to learn at that time: no STL, no odd pointer types, no template metaprogramming, etc. Fast-forward to 1997 and I'm listening to a talk about C++ compilers and hear that templates are now a Turing-complete language, and how the compiler developers used the template language to coerce the compiler into printing out the prime numbers. Fast forward again to 2022 (with trips to Java, Kotlin, Scala, and Haskell in between) and I've got a project that requires JNI and Python bindings to a core C engine. Great, I'll use C++! I proceed to start searching for containers/constructs and realize that at least 50% of the C++ language and standard library is unreadable to me. I only have a guess as to what a `shared_ptr` or `unique_ptr` type is, and I certainly don't know when to use them, and concepts/traits outlined in the STL documentation seem to be some sort of generalizations that the STL might provide default implementations for, but might not? What exactly is the syntax and/or type of a lambda function and how do they interact with C function pointers? etc., etc. I get the sense that C++'s evolution has been driven by esoteric corner cases that a handful of developers have encountered and the language & STL design has been driven by those cases. I'm still surprised by how many problems I can easily address in something like Scala or Haskell that C++ simply does not provide the facilities to express easily.

olvy0 4y ago
I'm with you mostly, although as the mostly sole maintainer of an 22 years old and still evolving C++ codebase (among some other responsibilities) I do try to keep up with the language. But if I didn't feel this was necessary for my job I probably wouldn't do it or at least won't sink too much time into it. I've also programmed in Haskell and I've had the same reaction as you, as to the things I can easily express there and not in C++. However I think the 2 cultures (Haskell and C++) are similar in that they both attract people who like to produce clever code which is unreadable to other people, even though the base language is not that complicated. As for your questions: 1) shared_ptr / unique_ptr: Personally I liked this presentation. Watch it on x2 speed until it gets to parts that are difficult for you. https://www.youtube.com/watch?v=xGDLkt-jBJ4 https://www.youtube.com/watch?v=xGDLkt-jBJ4 2) lambdas: https://www.youtube.com/watch?v=3jCOwajNch0 https://www.youtube.com/watch?v=3jCOwajNch0 This is more dense than the previous one. As for your question "how do lambdas interact with C function pointers": rough explanation is they are not the same, since they can possibly allocate memory if they capture. But if they don't capture anything they are just like a (static) function, and can be converted to a function pointer. As for concepts / traits, rough answer is that you don't need to know about them for everyday work, unless you write a library / API for consumption by other C++ developers. In that case, they help the compiler provide better/shorter error messages in case template functions/classes aren't used properly.

ryandrake 4y ago

To be fair and assume competence: A lot of C++ programmers have been burned by adopting the latest and greatest bling, then having to port it to some backwards platform that doesn't have a recent compiler. Many of us use the legacy stuff when possible, because we know it works, there are already robust third party libraries that interoperate with the legacy stuff, and it is more likely to be portable than std::omfgbbq.

nbjoerg 4y ago
I find that argument funny, given that Rust can't be updated often enough before every other library breaks.
sqeaky 4y ago
This is getting better. Businesses that force a specific compiler for reasons other than technical merit are being punished in the market. I am currently at a not super advanced C++ shop that has to write for several compilers on locked platforms, and even the worst/oldest compilers are clang or gcc forks that support C++17 and some C++20. We have robust CI and if it passes there we can use it (presuming it doesn't violate style guide/best practices/code review/etc). It is unlikely we will be burned by adopting the latest thing for anytime longer one developer is working on it. I think the companies that are so afraid of upgrading software tooling and related processes incurred huge project costs because of otherwise needless major rewrites. One I worked for a college bookstore management software developer that was trying to rewrite their whole point of sale software. They were simply crushed by tech debt. Any fix in the original software took months and the rewrite wasn't finished before the company was bought by a competitor. Better unit tests, better practices staying up to date, better CI all would have contributed to business success.
thefourthchime 4y ago
Raises hand. Everyone needs to read "Effective C++", which is mostly a book about how not to shoot yourself in the foot with C++. The book is old enough now that the way he recommends writing C++ wouldn't make it into a PR. So for that reason, I tended to write C+, which is pretty much C+, with some classes.

flohofwoe 4y ago

That's the problem with the C++ ecosystem, it is actually many vastly different ecosystems mashed together. It's impossible to find a "C++ developer" because there is no agreed upon "one C++ style". It seems what you're looking for is a "C++ developer who likes to write the same C++ style as myself" ;)

inetknght 4y ago
> It seems what you're looking for is a "C++ developer who likes to write the same C++ style as myself" ;) No, I'm perfectly content with someone writing C++ in a different style. What I'm not content with is someone who uses old code without a technical reason why. C style arrays, for example, are 100% inferior to std::array. Old loops with indices are maybe 80% (off the cuff guesstimate) inferior to ranged-for. There's absolutely no reason whatsoever to use `delete` in any C++ code that doesn't directly handle allocations (and so, very esoteric), and simlarly for `new`. But I keep seeing these things (and many other examples) show up in newly-written C++ code from "experienced" developers. Maybe 90% of the time they'll fix their code when I point out the modern solution and what problems the modern solution solves, and the last 10% of the time ends up in a technical argument about the merit of the old code (and that's fine as long as there is a technical merit for it).
- flohofwoe 4y ago
  > C style arrays, for example, are 100% inferior to std::array. Are the advantages of std::array over C arrays big enough to add 8kloc to each compilation unit though? (https://www.godbolt.org/z/8noTndhcv https://www.godbolt.org/z/8noTndhcv) A range-checked std::array replacement can probably be written in a few dozen lines of code. That's the problem with all C++ stdlib headers, they are incredibly overengineered for what they bring to the table.
  - inetknght 4y ago
    > Are the advantages of std::array over C arrays big enough to add 8kloc to each compilation unit though? I say yes, absolutely. C style arrays are _very easy_ to get wrong in many ways. Three just off the top of my head: - iterating using a size_t instead of an iterator - calculating the size of the array (and often using a preprocessor macro to do it) - leaving things uninitialized So a std::array provides iterators and works with a ranged-for loop. The only reason to use a size_t is if you truly need an index number (and I would argue: use `std::distance()` instead). A std::array provides a `size()` giving the total number of objects in it. It also provides the type, so you can do sizeof(type) * array.size() -- though that's still error prone. A std::array ensures that objects are correctly initialized. And, if you still need to dangerously decay the data to a pointer, you can use .data() to grab that pointer. > A range-checked std::array replacement can probably be written in a few dozen lines of code. Can you provide an example? > That's the problem with all C++ stdlib headers, they are incredibly overengineered for what they bring to the table. I would argue that the standard library isn't overengineered. It's engineered for more than just your use case. Just because code "is there" doesn't mean that code makes it into your product. Pay for what you use, don't pay for what you don't use.

vips7L 4y ago

I've had the same experience in Java. Experienced engineers that are learning "new" Java even though those features came out years ago. I really think this will be the case for any language. Most people are not the HN type that are going to live and breath programming.

inetknght 4y ago
I prefer to be proud that I've never touched Java... for Old Reasons. But that said, it's a valuable language. It's nice to know that other languages have similar problems :)
- vips7L 4y ago
  I'll probably get down voted, but I honestly really enjoy Java. The language, while it has some legacy verbosity, is in my opinion the perfect balance of simplicity and complexity. It has just enough language features without becoming Scala/Rust/C++ levels of complexity, while still being competitive on performance.
nbjoerg 4y ago
The ones on HN that actually work don't have the time to run after every few language feature either ;)