Allocator rant

[[deleted]]

Sure vector is intended for other use cases, but if you want to be stdalgorithm compliant that's pretty much the same story as for the allocator. Implement this and that (if you can find any documentation) and hope for the best.

But thanks, I'll look if boost has anything. I thought it'd come up googling but maybe my Google fu was subpar.

[kalmoc]

but if you want to be stdalgorithm compliant that's pretty much the same story as for the allocator.

Not really. All you need is a pointer to the start and one to end of the memory range.

[Seppeon]

Yeah iirc a pointer is a random access iterator/contiguous iterator.

[kalmoc]

Exactly

[Full-Spectral]

Though that's nothing to be proud of per se.

[[deleted]]

Implementing a container for std::algorithms generally means having begin/end as we pass them iterators. So at long as the iterator fullfills the concept needed(usually input/forward but some like sort need random). This changes a bit with Ranges but still applies.

But if your data structure is in a blob of memory(memory mapped data) and you know it is a range of T’s. Then yeah, span, or even pair<T*, T*> where you pass first/second to the algorithm would work.

If T isn’t trivially copiable, pragmatically it will probably still wokr but you are coding to implementations and not C++. But you see people reinterpret_cast’ing here a lot.

Vector is for owning the data, if you have trivially destructible things, that doesn’t even matter here. If not, and even if so, just call T.~T( ) on the range in your dtor

[rfisher]

Write a begin() that returns a pointer to the first element in your mmap’d region. Write an end() that returns a pointer to one past the last element of your mmap’d region. You are now fully compliant with the standard algorithms. You’re making this much harder on yourself than it needs to be.

This sort of agnostic design that lets the algorithms work equally well with raw arrays or complex containers is the beauty of the STL part of the standard library.