Add an array container that would store only a pointer to the elements and a size
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
No files, tests, or entry points are named in the issue. Start by reviewing the existing Boost.Container containers and their allocator conventions, then define the proposed pointer-and-size semantics, ownership behavior, and container name; done means an agreed design and corresponding implementation plan.
Written by the indexing model from the issue text.
Description
This proposed array container type would store a pointer to the allocated memory, and the number of elements that allocated memory contains. The allocator type would be provided as a template parameter, and the default allocator would allocate the memory on the heap.
Currently, using the standard library, it is possible to replicate this functionality in two ways but they both have their drawbacks, which makes them painful to use.
The first solution is to use std::vector. The problem with this solution is that std::vector stores an additional capacity member field, which serves no purpose. Also, it can allocate more elements than requested anticipating that additional elements will get pushed to it. This means that always some memory is going to be wasted when using std::vector instead of the proposed array. There is also the problem of intentionality with this solution. We are not being intentional when using std::vector instead of the proposed array, because to the reader of the code it is not clear whether we will ever push something else to the std::vector (std::vector has a lot of additional functionality which serves no purpose in this case) while it would be clear that we will not be pushing anything to the proposed array because it does not have such functionality.
The second solution is to use std::unique_ptr. The problem with this solution is that std::unique_ptr only stores a pointer and does not store the size. That means that the size would have to be stored in a separate variable and that makes this solution really inconvenient and painful to use. Imagine a function that accepts a std::span, so when calling this function we would always need to construct the span from a std::unique_ptr and the size variable that is stored separately. While with the proposed array, we could just pass it to the function. There is also the additional problem that there is no standard way to use the allocators with std::unique_ptr, there is no allocator support for std::unique_ptr. That means that this solution does not even fully replicate the functionality of the proposed array.
boost does not already provide such a container. The name of this proposed array container type should still be decided.
- Dominant language
- C++
- Stars
- 127
- Forks
- 126
- Avg merge
- 18h 53m
- Merged PRs (30d)
- 1
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from boostorg/container
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 3/5 1-2 days Newbie friendliness 42/100
-
Difficulty 3/5 1-2 days Newbie friendliness 64/100
-
Difficulty 4/5 3-5 days Newbie friendliness 38/100
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
All issues in boostorg/container
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
AXERA-TECH/ax-llm#77 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
games-on-whales/wolf#509 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
bug-unconfirmed
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
NVIDIA/cuda-samples#453 ·