3 ms·

You can supply your own allocator for the STL

by ape4 6y ago

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.

You can supply your own allocator for the STL

by ape4 6y ago

You can supply your own allocator for the STL

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.