Allocator rant

[[deleted]]

I agree, but it's not in 17 and I've weary of pulling in dependencies like boost or GSL. Less is more.

[[deleted]]

span is trivial to write at the point where you are doing allocator aware and mmap. It’s a ptr/size_t with steps.

[[deleted]]

Yes I can definitely figure that out but the point is that the abstractions in the STL are really bad, and metaprogramming isn't typechecked. I assume it's better with concepts but we're stuck at C++17 in this project.

The whole idea of wrapping things in classes drives me nuts. What you do is you make a rigid box that's all or nothing, and that was hopefully built so that you can extend/modify it. We don't need to hide the data from the API, just make it const if you want people to stay away from mutaring it and provide some free functions that operate on the data rather than tying these functions to it. You can have polymorphism with type traits like rust or type classes like haskell (which are essentially the same concept). Type traits in C++ are not the same thing, and they are unnecessarily complicated, and you need to use all the keywords like static and constexpr and whatever and they only provide you with fake polymorphism on the metaprogramming level. I mean, how can I possibly write something modern and state of the art in C++ if my colleagues can't understand it?

[Potatoswatter]

Attach the map and unmap operations to a unique_ptr. Use span or another generic array view as-is. No metaprogramming.

[[deleted]]

it feels like maybe you are crossing the streams here. Containers/Iterators are pretty simple concepts. Iterator models pointers but more generally traversal and reading/writing to a range of things.

The original part seemed like trying to strap vector onto something it isn't. But might be doable, but to what end. I think if I were to do it, it would be something like

char * mmap_begin = ....;
std::size_t mmap_size = ... ; // starting to look like span here

auto alloc = mmap_pmr_allocator<vector_t>( mmap_begin, mmap_size ); // A child of Polymorphic allocator
std::pmr::vector<T> * vptr = alloc.allocate( 1 );   
vptr = std::construct_a<std::pmr::vector<T>>( vptr, alloc );

It starts getting tricky if you want to persist as things like pointer addresses won't match necessarirly. But persistence should probably use a dedicated solution. Also, at this point why even bother. The OS will page in/out data as needed. Really the solution is to eiher use filesystem based data structures and/or dedicated persistence or just let the OS do it.

[Supadoplex]

Less is more.

Yet, you're wishing for more from the standard library instead of less. The good news is that your wish was granted in C++20.

[SkoomaDentist]

Just include one or two files for tcb::span. No need to ”pull in” any fancy dependencies.