5 ms·

I watched this entire talk a couple days ago. As a life long C++ native Software Engineer, cppfront/cpp2 is one of the few efforts in c++ that interest me thes

I watched this entire talk a couple days ago. As a life long C++ native Software Engineer, cppfront/cpp2 is one of the few efforts in c++ that interest me these days. I am also the hiring manager for our teams, and it's shocking that applicants that proudly include c++20 on their resumes but can not answer the intentionally open-ended question: Tell me about std::move(). IMO: If c++ is to thrive, it is in desperate need of the "10x simpler and safer" vision that is at the core of cppfront.

zabzonk 3y ago
sure, people should be able to say what std::move does (basically nothing) but people asking the questions need to be aware of what they are asking about - most c++ programmers are not writing library code.
- deleted 3y ago
  [deleted]
- schaefer 3y ago
  zabzonk, thank you for raising this point and the discussion it teases out. std::move is nothing but a cast - but it means that means that for every new class, we should be actively considering if a move constructor is appropriate for that class. The consequences of a missing move constructor would be calling the copy constructor... pretty dry stuff I agree. about as exciting as discussing pass by value or pass by reference... but for certain domains of programming (embedded), just as critical. Nicolai M. Josuttis , a 20 year veteran of the standards committee, can be quoted as saying "Move semantics, introduced with C++11, has become a hallmark of modern C++ programming." [1] But if we take a step back and consider the broader picture I think of "the average language proficiency of the team" as being a very real pressure. If the complexity of the code base creeps above the average proficiency of the team, the health of the code base struggles. So, here's the thing. As a hiring manager for embedded products, If I can't get applicants that know about std::move(), then the scope of the c++ language has outpaced it's own talent pool, and something like cppfront becomes all the more critical. [1]: http://www.cppmove.com/ http://www.cppmove.com/
  - zarzavat 3y ago
    You’ll never find two C++ programmers with the same skill set. Every C++ project has its own peculiar subset of the language. Forget rvalue references, some code doesn’t even use references. This is a result of backwards compatibility. Features can only be added, not removed (or at least only removed if nobody is using them, like export templates and GC). As a result C++ hoovered many different types of users over the years who all had their own idea of what they wanted from the language. For a C++ programmer, navigating this by learning and adapting your skill set for a new project is simply a part of the job. You’ll always be able to find missing spots in even the most grizzled C++ vet’s knowledge.
- Animats 3y ago
  Rust is a move-first language. Move is standard; you have to deliberately make anything non-trivial copyable. Rust strongly prefers to be single-assignment and to pass things as read-only references or moves. Those are the right defaults. In C++, the good defaults are all harder, because they were added as afterthoughts to the language. C++ has been gradually back-porting Rust features, but it provides help only for carefully written new code. You can still get raw pointers out, which breaks safety. To make forward progress with the C++ model, you have to throw stuff out of the language. That breaks too much old code. So they're stuck. Many, many people, including me, have tried to make C/C++ safer without breaking backwards compatibility too much. It doesn't seem to be possible to do both. You have to disallow some things or the exercise is pointless. Did this new proposal include array slices for C++? If you have slices, most of the need for pointer arithmetic goes away. But you need either a garbage collector, as in Go, a borrow checker, as in Rust, or restrictive scope rules to track when the underlying array goes away.
  - rewmie 3y ago
    > C++ has been gradually back-porting Rust features, I would hardly say that move semantics, or reusing temporary objects instead of deep copying them, is something invented by Rust. Also, move semantics were introduced in C++ with C++11, which was in the works since the early 2000s. Rust first appeared in 2015. Are you actually trying to claim that C++ in 2011 specified in an international standard features that it back ported from a language that only saw the light of day in 2015? > To make forward progress with the C++ model, you have to throw stuff out of the language. No, not really. Mindlessly removing features only breaks backward compatibility with no reason. We have progress by offering improvements. It's up to the developer to manage how he manages their projects. Mindlessly breaking compatibility prevents that same developer from benefitting from improvements for no reason whatsoever. > Many, many people, including me, have tried to make C/C++ safer without breaking backwards compatibility too much. It doesn't seem to be possible to do both. You have to disallow some things or the exercise is pointless. This is an absurdly silly thing to say. It's a kin to complaining that making Rust safe is pointless because Rust still supports unsafe.
    - 3y ago
thweor23423 3y ago
Rust, Go, and even TS roles all have better comp. The C++ people you want to hire are not applying to C++ anymore.
- pjmlp 3y ago
  Someone has to keep LLVM, GCC, CUDA, Unreal, Godot... going.
  - kajaktum 3y ago
    Don't worry, there's plenty of masochistic C++ enthusiast to keep all these project going.
    - pjmlp 3y ago
      Including Rust folks, if they want rustc to keep going. Naturally they are free to make Cranelift as good as LLVM, and fully bootstrap Rust instead.
misnome 3y ago
What level are you hiring at? I could well imagine e.g. fresh graduates not having a good handle on some of the nuances of the language. You can get pretty far without having to refine your understanding of rvalue semantics.

zabzonk 3y ago

sure, people should be able to say what std::move does (basically nothing) but people asking the questions need to be aware of what they are asking about - most c++ programmers are not writing library code.

deleted 3y ago
[deleted]
schaefer 3y ago
zabzonk, thank you for raising this point and the discussion it teases out. std::move is nothing but a cast - but it means that means that for every new class, we should be actively considering if a move constructor is appropriate for that class. The consequences of a missing move constructor would be calling the copy constructor... pretty dry stuff I agree. about as exciting as discussing pass by value or pass by reference... but for certain domains of programming (embedded), just as critical. Nicolai M. Josuttis , a 20 year veteran of the standards committee, can be quoted as saying "Move semantics, introduced with C++11, has become a hallmark of modern C++ programming." [1] But if we take a step back and consider the broader picture I think of "the average language proficiency of the team" as being a very real pressure. If the complexity of the code base creeps above the average proficiency of the team, the health of the code base struggles. So, here's the thing. As a hiring manager for embedded products, If I can't get applicants that know about std::move(), then the scope of the c++ language has outpaced it's own talent pool, and something like cppfront becomes all the more critical. [1]: http://www.cppmove.com/ http://www.cppmove.com/
- zarzavat 3y ago
  You’ll never find two C++ programmers with the same skill set. Every C++ project has its own peculiar subset of the language. Forget rvalue references, some code doesn’t even use references. This is a result of backwards compatibility. Features can only be added, not removed (or at least only removed if nobody is using them, like export templates and GC). As a result C++ hoovered many different types of users over the years who all had their own idea of what they wanted from the language. For a C++ programmer, navigating this by learning and adapting your skill set for a new project is simply a part of the job. You’ll always be able to find missing spots in even the most grizzled C++ vet’s knowledge.
Animats 3y ago
Rust is a move-first language. Move is standard; you have to deliberately make anything non-trivial copyable. Rust strongly prefers to be single-assignment and to pass things as read-only references or moves. Those are the right defaults. In C++, the good defaults are all harder, because they were added as afterthoughts to the language. C++ has been gradually back-porting Rust features, but it provides help only for carefully written new code. You can still get raw pointers out, which breaks safety. To make forward progress with the C++ model, you have to throw stuff out of the language. That breaks too much old code. So they're stuck. Many, many people, including me, have tried to make C/C++ safer without breaking backwards compatibility too much. It doesn't seem to be possible to do both. You have to disallow some things or the exercise is pointless. Did this new proposal include array slices for C++? If you have slices, most of the need for pointer arithmetic goes away. But you need either a garbage collector, as in Go, a borrow checker, as in Rust, or restrictive scope rules to track when the underlying array goes away.
- rewmie 3y ago
  > C++ has been gradually back-porting Rust features, I would hardly say that move semantics, or reusing temporary objects instead of deep copying them, is something invented by Rust. Also, move semantics were introduced in C++ with C++11, which was in the works since the early 2000s. Rust first appeared in 2015. Are you actually trying to claim that C++ in 2011 specified in an international standard features that it back ported from a language that only saw the light of day in 2015? > To make forward progress with the C++ model, you have to throw stuff out of the language. No, not really. Mindlessly removing features only breaks backward compatibility with no reason. We have progress by offering improvements. It's up to the developer to manage how he manages their projects. Mindlessly breaking compatibility prevents that same developer from benefitting from improvements for no reason whatsoever. > Many, many people, including me, have tried to make C/C++ safer without breaking backwards compatibility too much. It doesn't seem to be possible to do both. You have to disallow some things or the exercise is pointless. This is an absurdly silly thing to say. It's a kin to complaining that making Rust safe is pointless because Rust still supports unsafe.
  - 3y ago

thweor23423 3y ago

Rust, Go, and even TS roles all have better comp. The C++ people you want to hire are not applying to C++ anymore.

pjmlp 3y ago
Someone has to keep LLVM, GCC, CUDA, Unreal, Godot... going.
- kajaktum 3y ago
  Don't worry, there's plenty of masochistic C++ enthusiast to keep all these project going.
  - pjmlp 3y ago
    Including Rust folks, if they want rustc to keep going. Naturally they are free to make Cranelift as good as LLVM, and fully bootstrap Rust instead.

misnome 3y ago

What level are you hiring at? I could well imagine e.g. fresh graduates not having a good handle on some of the nuances of the language. You can get pretty far without having to refine your understanding of rvalue semantics.