On Tuesday, 19 May 2020 at 20:51:01 UTC, Luis wrote:
So, I'm writing my own implementation of sparse sets, and I
take as reference emsi_containers for allocator usage. I saw
that they have disabled postblit operator... But i don't
understand exactly why. In special, when they implement
InputRange over the containers, but having disabled postblit,
make nearly useless (at least as I see on this old post
https://forum.dlang.org/thread/n1sutu$1ugm$1...@digitalmars.com?page=1 )
Taking a look to std.container.array, I see that it have
postblit disabled, but here the range interface isn't
implemented. Instead it's recommended to do a slice, where
apply range algorithms.
In the source for the EMSI containers, they provide opSlice that
returns an internal Range type. And not all of the containers
implement InputRange. SList does, but HashSet does not.
I should take this way (ie. forgot to implement front and
popFront)? I actually have postblit disabled and implemented
InputForward, but as I say, this make it useless as range. I
need, like std.container.array, to use slice for do a foreach
or any range algorithm.
As a general rule of thumb, containers *should not* be used as
InputRanges. And that includes ForwardRange, BidirectionalRange,
and RandomAccessRange (each range interface builds upon the one
before--simply implementing `save` does not make a ForwardRange
unless the type also has the InputRange interface).
Input ranges are intended to be consumed. At the end of an
iteration, they should be empty. The convention is to obtain a
range by slicing the container. So your containers should
implement opSlice and return an anonymous range type just like
std.container.array, containers.hashset, containers.slist, etc.
do. Then iteration becomes:
foreach(elem; container[]) {
}
// The range has been consumed, but the container still holds all
the elements.
