4 ms·

> But for other programs, where aborting on allocation failure is not acceptable Sure but that seems like the edge case not the general case? Nearly any deskto

> But for other programs, where aborting on allocation failure is not acceptable Sure but that seems like the edge case not the general case? Nearly any desktop or mobile app or game won't have any such constraints, for example. And you've also got overcommit to deal with on those platforms, so it's not like your allocation failure will actually happen at malloc time either. So outside of embedded, which tends to have a variety of constraints, what even pretends to handle allocation failures across the entire program?

ape4 6y ago
You can supply your own allocator for the STL
- gmueckl 6y ago
  Not really. You can supply alloctors to contai ers, but it becomes iffy for strings. Custom allocator support for std::function was removed in C++17. And there is no way that I am aware of to use custom allocators for the std::shared_ptr refcounters.
  - kllrnohj 6y ago
    There is, allocate_shared takes an allocator: https://en.cppreference.com/w/cpp/memory/shared_ptr/allocate_shared https://en.cppreference.com/w/cpp/memory/shared_ptr/allocate... I'm not entirely sure why you'd want a custom allocator for shared_ptr, though.
    - gmueckl 6y ago
      It is quite common in certain contexts to allow the user of a library to provide their own custom allocator. And this would be kind of pointless if some allocations circumvent that, wouldn't it? The deeper rationale is that some systems like to assign fixed memory pools to subsystems. These may be reset or destroyed at certain points in the applications life cycle and the general expectation is that this frees all memory used by said subsystem. If you still want to use the STL in that context, you need to provide custom allocators for everything that potentially allocates.
      - kllrnohj 6y ago
        But by doing that you'd be breaking the safety (and functionality) of shared_ptr as you'd end up with potentially dangling references (similarly weak pointers are broken). Which then raises the question of why are you using shared_ptr in the first place? You could use a custom allocator just for auditing that all outstanding references were released, I suppose, but actually releasing the memory anyway is just adding bugs. Which can be a fair risk to take, it just seems like shared_ptr is then not the thing you want to indicate appropriate "running with scissors" behavior.
        gmueckl 6y ago
        As long as you can guarantee that no shared_ptr lives longer than its backing memory pool, it's perfectly fine. The same goes for every other kind of pointer wrapper you could dream up. At least you can write a replacement for shared_ptr. The same is not true for std::function. This is the only named type a capturing lambda converts to according to the language standard and it's an STL type with complex behind the scenes behavior.
        kllrnohj 6y ago
        You can write your own std::function, too, nor is it the only STL type that can take a capturing lambda (std::packaged_task for example). A capturing lambda is just a class with an operator(). It's complicated to do what std::function does, but fully possible. In fact, custom std::function replacements have better lambda support than std::function itself. Such as unique_function in https://github.com/Naios/function2 https://github.com/Naios/function2 which can handle non-copyable lambdas.
rockwotj 6y ago
> So outside of embedded, which tends to have a variety of constraints, what even pretends to handle allocation failures across the entire program? Don't embedded platforms mostly use something other than STL anyway?
- jcelerier 6y ago
  What do you call "embedded platforms" ? Car dashboards in 2020 run Qt on QNX for instance.

ape4 6y ago

You can supply your own allocator for the STL

gmueckl 6y ago
Not really. You can supply alloctors to contai ers, but it becomes iffy for strings. Custom allocator support for std::function was removed in C++17. And there is no way that I am aware of to use custom allocators for the std::shared_ptr refcounters.
- kllrnohj 6y ago
  There is, allocate_shared takes an allocator: https://en.cppreference.com/w/cpp/memory/shared_ptr/allocate_shared https://en.cppreference.com/w/cpp/memory/shared_ptr/allocate... I'm not entirely sure why you'd want a custom allocator for shared_ptr, though.
  - gmueckl 6y ago
    It is quite common in certain contexts to allow the user of a library to provide their own custom allocator. And this would be kind of pointless if some allocations circumvent that, wouldn't it? The deeper rationale is that some systems like to assign fixed memory pools to subsystems. These may be reset or destroyed at certain points in the applications life cycle and the general expectation is that this frees all memory used by said subsystem. If you still want to use the STL in that context, you need to provide custom allocators for everything that potentially allocates.
    - kllrnohj 6y ago
      But by doing that you'd be breaking the safety (and functionality) of shared_ptr as you'd end up with potentially dangling references (similarly weak pointers are broken). Which then raises the question of why are you using shared_ptr in the first place? You could use a custom allocator just for auditing that all outstanding references were released, I suppose, but actually releasing the memory anyway is just adding bugs. Which can be a fair risk to take, it just seems like shared_ptr is then not the thing you want to indicate appropriate "running with scissors" behavior.
      - gmueckl 6y ago
        As long as you can guarantee that no shared_ptr lives longer than its backing memory pool, it's perfectly fine. The same goes for every other kind of pointer wrapper you could dream up. At least you can write a replacement for shared_ptr. The same is not true for std::function. This is the only named type a capturing lambda converts to according to the language standard and it's an STL type with complex behind the scenes behavior.
        kllrnohj 6y ago
        You can write your own std::function, too, nor is it the only STL type that can take a capturing lambda (std::packaged_task for example). A capturing lambda is just a class with an operator(). It's complicated to do what std::function does, but fully possible. In fact, custom std::function replacements have better lambda support than std::function itself. Such as unique_function in https://github.com/Naios/function2 https://github.com/Naios/function2 which can handle non-copyable lambdas.

rockwotj 6y ago

> So outside of embedded, which tends to have a variety of constraints, what even pretends to handle allocation failures across the entire program? Don't embedded platforms mostly use something other than STL anyway?

jcelerier 6y ago
What do you call "embedded platforms" ? Car dashboards in 2020 run Qt on QNX for instance.