5 ms·

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 larg

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?).
    - 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.
Waterluvian 8y ago
I feel this way about Python. The stdlib is wildly huge. I use a certain 2% of it all the time. But having skimmed the entire thing, every so often I'll have a moment of, "oh! I know the right tool for this!"
- beached_whale 8y ago
  I do this with C++'s algorithms, numerics and containers. Also, getting into the practice of naming things and letting the optimizer inline really helps. Have a loop, put it into a small function and name it. The code starts to look like it is full of C++ algorithms and reads at the same abstraction levels at each method body
seanwilson 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. When a language contains lots of ways to shoot yourself in the foot, it's just not realistic to expect that those features aren't going to be misused when potentially millions of programmers might be coding in it. Even getting agreement of how to use features within a small team can be difficult, and you're always going to have to use external libraries developed by others that don't follow your coding standards. The language design should make it easy to do the right thing and difficult to do the wrong thing in my opinion. When the language isn't designed this way, it's always an uphill struggle where the coding community has to devise and enforce their own standards.
- beached_whale 8y ago
  Often, not always, the other side of that shooting in foot is a very useful tool for another purpose. And it is unattainable to code review other libraries, put the hard stop at the API boundary. But yeah, that can force your hand in some decisions too... It's complicated I am of the mind that any language that is useful for general purpose or at least outside of small niche areas will provide many ways to shoot yourself in the foot. C++ does have a lot of them, but it also has a lot of tools.

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

Waterluvian 8y ago

I feel this way about Python. The stdlib is wildly huge. I use a certain 2% of it all the time. But having skimmed the entire thing, every so often I'll have a moment of, "oh! I know the right tool for this!"

beached_whale 8y ago
I do this with C++'s algorithms, numerics and containers. Also, getting into the practice of naming things and letting the optimizer inline really helps. Have a loop, put it into a small function and name it. The code starts to look like it is full of C++ algorithms and reads at the same abstraction levels at each method body

seanwilson 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. When a language contains lots of ways to shoot yourself in the foot, it's just not realistic to expect that those features aren't going to be misused when potentially millions of programmers might be coding in it. Even getting agreement of how to use features within a small team can be difficult, and you're always going to have to use external libraries developed by others that don't follow your coding standards. The language design should make it easy to do the right thing and difficult to do the wrong thing in my opinion. When the language isn't designed this way, it's always an uphill struggle where the coding community has to devise and enforce their own standards.

beached_whale 8y ago
Often, not always, the other side of that shooting in foot is a very useful tool for another purpose. And it is unattainable to code review other libraries, put the hard stop at the API boundary. But yeah, that can force your hand in some decisions too... It's complicated I am of the mind that any language that is useful for general purpose or at least outside of small niche areas will provide many ways to shoot yourself in the foot. C++ does have a lot of them, but it also has a lot of tools.