queue container?

J Arrizza cppgent0 at gmail.com
Sat Oct 29 09:02:51 PDT 2011


On Fri, Oct 28, 2011 at 6:55 PM, Steven Schveighoffer
<schveiguy at yahoo.com>wrote:

> Using an array of any type as a queue is going to be awkward.
>
Yes. The call is messy and of course I could wrap it in my own class to
make the calling syntax cleaner. My application is not performance critical
in any way.


> I'd recommend using a linked list or a deque.  Both are available via
> dcollections, though using dcollections' deque as a queue is equivalent to
> using an array because of the implementation.  SList is not suited for a
> queue, since you cannot have O(1) addition on one end and O(1) removal on
> the other.
>

I'd like to use only Phobos because it's guaranteed to be there as part of
D, while dcollections may or may not persist, and may or may not be merged
into Phobos. For example, if Phobos comes out with a more comprehensive
std.collections, then dcollections becomes redundant. If it is merged into
Phobos, then fine.

When Jacob's central repository is put in place and the D community accepts
it ( as did the Perl community for CPAN), and dcollections is in there,
then I'll use it.

> It's also quite trivial to roll your own linked list-based queue.
Yes.  I've gone down this route before in C++. I write my own and then a
new version of the std.container comes out. The end result is a lot of busy
work converting from my queue implementation to the standard one. Sometimes
I'm even forced to convert because of name clashes. Then it's worse. It's
busy work under pressure.

There's also the backing out of little changes that have creeped into mine
that make it incompatible with the new standard one.  Boost went this
route, so did MFC and so have I. I wrote my own String and what-have-you,
all for expediency. Eventually incompatibilities and conversions start to
creep in, until one day, I've painted myself into a tight little corner.

Enough reminiscing. My preference is to have a clear policy that Phobos is
the one and only (nicely comprehensive) standard library and there is a
central repository for all the remaining esoteric and rare a la CPAN, gems,
PyPI, etc.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111029/d1d7de6f/attachment.html>


More information about the Digitalmars-d mailing list