In 0.15.1 it seems the preferred practise for array list is to use the non managed version, which takes an allocator only for operations that need it rather than require it for initialization and keep it around.
Should we expect the same treatment for the Queue HashMap and PriorityQueue?
edit: Queue is not in the std lib I meant hashmap
AFAIK yes, though there seems to be some holdup given other managed containers haven’t even be deprecated yet. I recall some discussion about that, specifically HashMap I think, but don’t remember the result.
iirc there is no Queue type in zig std only std.PriorityQueue.
Closest to Queue is recently added std.Deque which adopts allocless api.
iirc there is no
Queuetype in zig
Of course, sorry, I was thinking HashMap.
I think Queue wouldn’t make sense since array list can trivially be used as one.
The reason for my original question is I’m moving some of my own data structures into a library and thinking should I move to the same pattern as the new array list.
Probably it is use case dependent to some degree.
Maybe you confusing it with a stack? ArrayList can be used as stack but not as a queue. If it could Deque wouldn’t be accepted in std since Deque can emulate Queue
Welcom to Ziggit @justinhj!
I think every data structure should adopt the unmanaged version, yes. It never made sense to me that “the short one does more”, my intuition tells me that the two-word type should be extended by the three-word type, rather than the other way around.
PriorityQueue is kind of an edge case, but I hope that at least HashMapManaged stays in the language. Just empirically it seems like I get a lot of use out of the allocating version of that data structure, and would just end up writing little custom wrappers for it, which I have to extend each time I realize I need another function from the namespace.
A rule like “no data structure in the standard library will have a managed variant” strikes me as overly purist, although the managed version should never be the baseline. But if that’s what we end up going with? Eh, I could live with it.
Maybe you confusing it with a stack?
No, I implement queue as a circular buffer using array list as the backing store.
edit: Perhaps I am in fact making a case for Queue should be in the std library.
There used to be a fifo namespace, with a LinearFifo type, it was just removed in 0.15. The release notes say it was removed due to being “poorly designed”, which, I kind of see what they mean? Mostly not.
I ended up vendoring it in a project which uses both the static and dynamic flavors of queue. I think of the old implementation as flexible, rather than overly generic, and was baffled to read that most of the real-world use cases were replaceable with Io.Reader and Io.Writer. That may be the case, but I’m using it for message queues, and had never considered deploying it for the purpose that quote implies. I believe that people were, just never occurred to me personally.
Anyway, the notes end with:
[T]here will likely be room for a general-purpose, reusable ring buffer implementation in the standard library, however, first ask yourself if what you really need is
std.Io.Readerorstd.Io.Writer.
And in the meantime, it’s easy enough to retrieve the file from older tags in the Zig repo and just use it.
fwiw, a deque did make a return to std recently oops, already shared above
Agreed. I already wrote my own Queue.
Nice to see Deque is in master. I will replace my Queue code with this when it’s released. I’m assuming using Deque from one end has no disadvantages compared to a Queue apart from its a bit more general than needed.