-
Notifications
You must be signed in to change notification settings - Fork 2
Description
I'm seeking help from open source contributors regarding allocator support for a custom forward_list STL implementation.
My Problem
While implementing my own version of forward_list, I forgot to add allocator support. As a result, all memory management is currently done using direct new and delete operations. I only realized this issue after I had already implemented several methods, including merge. Now, I understand that omitting the use of an allocator is a significant problem for a generic container, and refactoring is needed to correct this.
Problem Explanation
In STL containers, allocators abstract how memory for elements is managed (allocated, constructed, destroyed, and deallocated). Instead of calling new and delete directly, containers are expected to use an allocator type so users can customize memory management. Omitting an allocator means your container cannot benefit from custom memory policies (e.g., memory pools, debugging, tracking, or specialized hardware).
For example, standard std::forward_list is templated to accept an allocator type. All allocation and deallocation for nodes or elements are done through the allocator interface. This is critical for writing generic, robust, and efficient containers.
Helpful Resources
- C++ reference: Allocators
- STL Allocators: Why and How
- Allocator-aware container construction
- Allocator implementation example (Stack Overflow)
Request
I'd appreciate explanations, suggestions, or code contributions for integrating allocator support into this project, and insights into refactoring the code to use allocators instead of direct new/delete operations.
Thank you!