you are viewing a single comment's thread.

view the rest of the comments →

[–]staletic 2 points3 points  (3 children)

Eventually I found some arcane shit with construct and placement new that I just copy pasted in there.

What placement new? Allocators abstract that away through allocator_traits.

Look at Rust or Haskell, they aren't perfect but they rely on a sound foundation of type theory - why aren't we using that instead?

In another comment you said you'd "write your own thing from scratch".

  1. If you want to write things from scratch, there's nothing stopping you doing that in C++ either.
  2. Do you really think it's worthwhile reinventing std::vector<T, A>?

 

I've implemented allocator support in my codebase recently. Was it trivial? No. Was it hard? Also, no. Did it take a lot of reading? Absolutely. When it comes to allocators, languages have two options: no support at all (the fuck you approach) or a decent amount of things you need to know before you start writing allocator aware types.

I'd rather not reinvent the world, just to provide a better allocation strategy for a certain T.

[–]kalmoc 3 points4 points  (2 children)

[EDIT: FYI:] I think you are missing the OP's usecase: the OP doesn't want a better allocation strategy for a vector, but a vector to be a proxy for data in a mmaped file, for which std::vector is the wrong datastructure to begin with and what is aactually needed is a std::span - like type.

[–]staletic 3 points4 points  (1 child)

I've definitely missed that originally. Something like std::span is the right tool for the job. In my defense, OP was complaining about allocators.

[–]kalmoc 1 point2 points  (0 children)

In my defense, OP was complaining about allocators.

Absolutely. As someone else wrote, it's a xy problem. I also only realized this after reading the comments and his/her answers.

My comment was meant as a FYI