Support for span subviews
jdumas opened this issue · comments
Hi,
Would you consider adding subviews (first/last/subspan) to CorradeArrayView.h for STL compatibility?
Hi, the functionality is already there, and I'd admit it offers even broader possibilities than STL: https://doc.magnum.graphics/corrade/classCorrade_1_1Containers_1_1ArrayView.html#Containers-ArrayView-usage-slicing
Or ... you mean like under the exact same name as in STL span?
Yes exactly. Using the same name as the STL would allow for easier drop-in replacement!
That's not among this project goals, sorry. Naming is hard, API design is hard, and aiming for STL compatibility would force me to repeat their past mistakes (such as allowing to implicitly create a span from an initializer list just to crash on a dangling pointer on the very next line) and limit what I can do -- these classes were made exactly because I felt something different, lighter-weight and possibly better could be made if I didn't have to follow the STL design. Here's an older article explaining the background for this decision: https://blog.magnum.graphics/backstage/array-view-implementations/
If you want a STL span implementation without having to use C++20, there's plenty of other projects such as https://github.com/martinmoene/span-lite .
Yeah I'm currently using span-lite at the moment. But it's including tons of headers, such as <memory>, which I'd like to avoid ... I'm glad you have an implementation that is more lightweight, but looks like I'll have to update my code then.
That's the problem with STL, unfortunately, even if the implementation wouldn't need to use any smart pointers, <memory> has for some reason the definition of std::addressof() which I suppose they need for something. It's always a tradeoff between how much extra cruft you include from the STL vs how much of that you implement yourself (or don't use at all...). After struggling for years with whether it's fine to include <memory> just for a PIMPL or if it's better to do a manual new / delete to save on compile times I realized it's easier for me to just not depend on STL on anything and only provide compatibility conversion for users that need that... and ended up here :)
Lately I even went as far as implementing my own std::move() and std::forward() because, with all heavier headers gone, <utility> started showing up high on the build profiler output.
I feel the pain. I'd like to be at a point where <utility> is becoming a bottleneck...
I didn't see any PIMPL class in Corrade though. I'm surprised you don't need one? But anyway, I guess I'll close this issue for now.
PIMPL is the Pointer :) No custom deleter support, no shared_ptr equivalent, as simple as possible to cover exactly this case.
I'm looking for a pimpl implementation which has value semantic (can be copied/moved around). Your Pointer class unfortunately can't be copied =)
Ah, that would be a whole other thing. Here I have a policy that if a class needs to allocate something on a copy, then it should be move-only instead ... except for strings. So far that goes fine, Pointer is movable. But also I have a crazy specific use case where I can afford such restrictions, general-purpose code often can't.