24 ms·

Compared to a decade ago a bunch of stuff in no particular order: 1) malloc/new & free/delete are now solidly legacy territory of the "unless it's a placement

Compared to a decade ago a bunch of stuff in no particular order: 1) malloc/new & free/delete are now solidly legacy territory of the "unless it's a placement `new`, you're likely doing it wrong". make_unique && make_shared all day long. 2) templates that are understandable by mortals thanks to `if constexpr` instead of SFINAE nightmares. 3) static_asserts 4) lambdas (which is going to get way more useful with https://en.cppreference.com/w/cpp/utility/functional/move_only_function/move_only_function https://en.cppreference.com/w/cpp/utility/functional/move_on... ) 5) std::format 6) attributes like [[nodiscard]] being standard 7) std::move making passing std:vector & similar containers around not being terrifying (this is what also really helps #1 be possible) I'm sure I missed some stuff, but I reach for all of those regularly.

hedora 4y ago
auto
charcircuit 4y ago
What makes move_only_functions useful?
- corysama 4y ago
  std::function is literally an object that can be invoked like a function. As an object, it can contain multiple values. Move-only values are very used for common situations of unique resources that should not be duplicated. But, what if you want to enclose a move-only value in a std::function? Are you simply out of luck and must give up on your dreams? A move-only function lets you get that work done.
- kllrnohj 4y ago
  My majority usage of lambdas is for use with work queues (so think Java executor). With the std only the easiest way to build that is a vector of std::function. But then your lambdas can't capture unique_ptrs, even though lambdas themselves have supported move captures for a long long time now. You can do this with std::packaged_task, but that has internal heap allocations for the future. Which if you don't need is just overhead, and not cheap overhead at that.
arinlen 4y ago
> 1) malloc/new & free/delete are now solidly legacy territory of the "unless it's a placement `new`, you're likely doing it wrong". make_unique && make_shared all day long. This is awfully wrong. C++ might be convenient to express ownership and manage object lifetimes, but they are not the only way to express ownership by far. Take for instance Qt, which relies heavily on new-ing up objects still up to this day, as it has its own ownership and object lifetime management system.
- kllrnohj 4y ago
  Swapping out unique_ptr/shared_ptr for some other smart pointer container doesn't negate what I said. New/delete are still basically deprecated territory. Qt isn't any different here, other than it seems they are behind the curve with make() variants of their pointer containers. So you'd want to make your own of that, and then go back to the world of "new/delete are deprecated"
  - BenFrantzDale 4y ago
    You can always create your own “algorithms”. Our codebase has one that creates a new QObject that is a child of an existing one, returning a (raw) pointer to the new child object. That’s a case of not “no raw `new`”, but the next-best thing: isolating raw `new` to the one algorithm that does just that, and letting all other code depend on that.
AtlasBarfed 4y ago
1) I'm always wary of something that is mature that has documented and extensive historical issues being handwaved away with "it's all fixed in this or the next release" 2) in light of that your comment is unintentionally hilarious. C++ became a syntax swamp 15 years ago and it is getting worse every release. I anticipate it getting worse as rust, a hilarious syntax soup in its own right, continues to march forward.

hedora 4y ago

auto

charcircuit 4y ago

What makes move_only_functions useful?

corysama 4y ago
std::function is literally an object that can be invoked like a function. As an object, it can contain multiple values. Move-only values are very used for common situations of unique resources that should not be duplicated. But, what if you want to enclose a move-only value in a std::function? Are you simply out of luck and must give up on your dreams? A move-only function lets you get that work done.
kllrnohj 4y ago
My majority usage of lambdas is for use with work queues (so think Java executor). With the std only the easiest way to build that is a vector of std::function. But then your lambdas can't capture unique_ptrs, even though lambdas themselves have supported move captures for a long long time now. You can do this with std::packaged_task, but that has internal heap allocations for the future. Which if you don't need is just overhead, and not cheap overhead at that.

arinlen 4y ago

> 1) malloc/new & free/delete are now solidly legacy territory of the "unless it's a placement `new`, you're likely doing it wrong". make_unique && make_shared all day long. This is awfully wrong. C++ might be convenient to express ownership and manage object lifetimes, but they are not the only way to express ownership by far. Take for instance Qt, which relies heavily on new-ing up objects still up to this day, as it has its own ownership and object lifetime management system.

kllrnohj 4y ago
Swapping out unique_ptr/shared_ptr for some other smart pointer container doesn't negate what I said. New/delete are still basically deprecated territory. Qt isn't any different here, other than it seems they are behind the curve with make() variants of their pointer containers. So you'd want to make your own of that, and then go back to the world of "new/delete are deprecated"
- BenFrantzDale 4y ago
  You can always create your own “algorithms”. Our codebase has one that creates a new QObject that is a child of an existing one, returning a (raw) pointer to the new child object. That’s a case of not “no raw `new`”, but the next-best thing: isolating raw `new` to the one algorithm that does just that, and letting all other code depend on that.

AtlasBarfed 4y ago

1) I'm always wary of something that is mature that has documented and extensive historical issues being handwaved away with "it's all fixed in this or the next release" 2) in light of that your comment is unintentionally hilarious. C++ became a syntax swamp 15 years ago and it is getting worse every release. I anticipate it getting worse as rust, a hilarious syntax soup in its own right, continues to march forward.