3 ms·

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 power

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?).
- gpderetta 8y ago
  Well, you can use std:: function on an ABI boundary if your platform ABI guarantees ABI stability. If not you might need to roll your own implementation.

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?).

gpderetta 8y ago
Well, you can use std:: function on an ABI boundary if your platform ABI guarantees ABI stability. If not you might need to roll your own implementation.