4 ms·

The surface area of C++ 17 is so huge it's already largely a write only language (impossible for a normal maintenance programmer to have learned and mastered al

by yodon 8y ago

The surface area of C++ 17 is so huge it's already largely a write only language (impossible for a normal maintenance programmer to have learned and mastered all the syntaxes and idioms). I'm not looking forward to trying to maintain a C++ 20 codebase that a bunch of architecture astronaut devs went wild on.

saagarjha 8y ago
> The surface area of C++ 17 is so huge it's already largely a write only language You don’t necessarily have to use every C++17 feature…
- corysama 8y ago
  And, a whole lot of the new features are there to replace difficult and verbose common uses of old features.
  - Gibbon1 8y ago
    You can't rewrite all the code you come in contact with.
- jarfil 8y ago
  That's only true when writing new code. When you have to maintain code, you need to use all the features used by any one of the people who've ever worked on it, which at some point becomes all of the features.
- jhayward 8y ago
  When reading/reviewing someone else's code you have to know the entire set of problems and constraints that may arise from their code, including syntax traps, semantic esoterica, and effects. You can't simply decide on a subset of the language that you like and declare than none of the rest of it affects the code unless you want to trust that none of the excluded set has any impact.
beached_whale 8y ago
That is a conversation with who you work with. You don’t use all the tools in the garage but are really happy they are there when you need them. Also, a large part of modern c++ is that simplicity is not only better for people but for compilers.
- Gibbon1 8y ago
  Friends of mine say each new job comes with a new dialect of C++.
  - waynecochran 8y ago
    It is rare to find practitioners that understand modern C++. Those dialects are usually old C++98 with a hodgepodge of C++11 throw in. Mostly missing the powerful functional additions and using to the old OOP stuff.
    - beached_whale 8y ago
      You can do lots of modern c++ with C++98...mostly with a few things like move construction/assignment thrown in. A lot of it is using the type system to help you or better describe your intent. Putting your values invariants into it's type means we can guarantee them and not forget. Use RAII. This is the biggest and it has been here since the beginning. Yeah, the old polymorphic class hierarchies can be tough. Who owns this pointer I have right now? One hopes the library takes ownership, but a pointer type doesn't have that invariant or ownership. This is where unique_ptr really shines. Also, one can create a type like poly_value<Base> that can be a Base or Child of Base and then treat it like a value with copies and all if the currently held type supports it. But yeah, lots of people are working with 20 year old code and can at best do boyscout rule to clean up what they touch. There are a lot cppcon/c++now like talks about working with these.
    - zvrba 8y ago
      I'm one of those people. As for why: modern, heavily-templated C++ doesn't mesh well with dynamic linking, i.e., plugin architecture. I can send even a pointer to `std::function` over ABI boundary (COM, in-process server) as int64, and it even works (given compatible compilation -- this is checked for), but uninstantiated templates are a no-go from the start. So anything that's to cross the ABI boundary must be wrapped in vtables with methods taking/returning primitive types. Of course, you have to unwrap it on "the other side", and the more such wrapping/unwrapping you have to do (casting to/from void* or intptr), the higher the chance that you'll mess it up somewhere along the lane. This naturally leads to OO design from the start and "functional techniques", if any, are buried deep in the implementation code. Though they make awful compile times and debugging experience is awful as well (ever tried to inspect a boost::fusion::map in a debugger?).
jb1991 8y ago
"write only language" ? If anything, C++ is becoming more const-sensitive as it ages.
noobermin 8y ago
I guess this is my feeling. We are learning nothing from the class-based OOP of the late 90s and early 00s.
- gumby 8y ago
  I wrote a fairly large code base that started from an empty buffer in c++17. I don't really consider C++ an OOP language, though it can be used in that way if you wish.
  - noobermin 8y ago
    Uh, let me clarify. We are not learning the lessons that we should have learned after class based OOP lead to unneccessary complexity in many cases.
twic 8y ago
I don't think that C++ is write-only. Now rewrite-in-Rust-only, maybe!
gumby 8y ago
A number of the new features like concepts are aimed more at library designers to help them do efficient things that make their libraries easier for callers. User code may not need to use all the power.

by yodon 8y ago

saagarjha 8y ago

> The surface area of C++ 17 is so huge it's already largely a write only language You don’t necessarily have to use every C++17 feature…

corysama 8y ago
And, a whole lot of the new features are there to replace difficult and verbose common uses of old features.
- Gibbon1 8y ago
  You can't rewrite all the code you come in contact with.
jarfil 8y ago
That's only true when writing new code. When you have to maintain code, you need to use all the features used by any one of the people who've ever worked on it, which at some point becomes all of the features.
jhayward 8y ago
When reading/reviewing someone else's code you have to know the entire set of problems and constraints that may arise from their code, including syntax traps, semantic esoterica, and effects. You can't simply decide on a subset of the language that you like and declare than none of the rest of it affects the code unless you want to trust that none of the excluded set has any impact.

beached_whale 8y ago

That is a conversation with who you work with. You don’t use all the tools in the garage but are really happy they are there when you need them. Also, a large part of modern c++ is that simplicity is not only better for people but for compilers.

Gibbon1 8y ago
Friends of mine say each new job comes with a new dialect of C++.
- waynecochran 8y ago
  It is rare to find practitioners that understand modern C++. Those dialects are usually old C++98 with a hodgepodge of C++11 throw in. Mostly missing the powerful functional additions and using to the old OOP stuff.
  - beached_whale 8y ago
    You can do lots of modern c++ with C++98...mostly with a few things like move construction/assignment thrown in. A lot of it is using the type system to help you or better describe your intent. Putting your values invariants into it's type means we can guarantee them and not forget. Use RAII. This is the biggest and it has been here since the beginning. Yeah, the old polymorphic class hierarchies can be tough. Who owns this pointer I have right now? One hopes the library takes ownership, but a pointer type doesn't have that invariant or ownership. This is where unique_ptr really shines. Also, one can create a type like poly_value<Base> that can be a Base or Child of Base and then treat it like a value with copies and all if the currently held type supports it. But yeah, lots of people are working with 20 year old code and can at best do boyscout rule to clean up what they touch. There are a lot cppcon/c++now like talks about working with these.
  - zvrba 8y ago
    I'm one of those people. As for why: modern, heavily-templated C++ doesn't mesh well with dynamic linking, i.e., plugin architecture. I can send even a pointer to `std::function` over ABI boundary (COM, in-process server) as int64, and it even works (given compatible compilation -- this is checked for), but uninstantiated templates are a no-go from the start. So anything that's to cross the ABI boundary must be wrapped in vtables with methods taking/returning primitive types. Of course, you have to unwrap it on "the other side", and the more such wrapping/unwrapping you have to do (casting to/from void* or intptr), the higher the chance that you'll mess it up somewhere along the lane. This naturally leads to OO design from the start and "functional techniques", if any, are buried deep in the implementation code. Though they make awful compile times and debugging experience is awful as well (ever tried to inspect a boost::fusion::map in a debugger?).

jb1991 8y ago

"write only language" ? If anything, C++ is becoming more const-sensitive as it ages.

noobermin 8y ago

I guess this is my feeling. We are learning nothing from the class-based OOP of the late 90s and early 00s.

gumby 8y ago
I wrote a fairly large code base that started from an empty buffer in c++17. I don't really consider C++ an OOP language, though it can be used in that way if you wish.
- noobermin 8y ago
  Uh, let me clarify. We are not learning the lessons that we should have learned after class based OOP lead to unneccessary complexity in many cases.

twic 8y ago

I don't think that C++ is write-only. Now rewrite-in-Rust-only, maybe!

gumby 8y ago

A number of the new features like concepts are aimed more at library designers to help them do efficient things that make their libraries easier for callers. User code may not need to use all the power.