container stuff

Jerry Quinn jlquinn at optonline.net
Tue May 25 22:40:33 PDT 2010


Andrei Alexandrescu Wrote:

> On 05/25/2010 06:04 PM, Steven Schveighoffer wrote:
> > On Tue, 25 May 2010 18:27:32 -0400, Andrei Alexandrescu
> > <SeeWebsiteForEmail at erdani.org> wrote:
> >
> >> I've uploaded a work in progress on the container design here:
> >>
> >> http://erdani.com/d/phobos/std_container.html
> >>
> >> It's deceptively simple - the entire design is a nomenclature, really.
> >> Any given container may choose to implement whichever primitives it
> >> can, if (and only if) it can satisfy the requirements. Beyond that,
> >> each container can define its own primitives.
> >>
> >> There are a bunch of "soft" primitives. Those are meant to put a stop
> >> to the iterator invalidation problems experienced in the STL. The
> >> container implementor may alias softXyz to xyz if she knows the
> >> operation won't mess the ranges currently iterating the container
> >> (which is the case for most node-based containers). I haven't yet
> >> discussed subtler cases in which a range starts with a removed element
> >> etc., but I plan to.

softXXX might be better named safeXXX or stableXXX.  The names might be more suggestive of preserving iteration.

The doc isn't quite clear whether make is a member function or
standalone.  I assume it's standalone, but that's worth firming up.

> > I don't like insertInstead, can we make it replace?
> 
> replace was the original name. insertInstead is consistent with the 
> other two, so we have (softI|i)nsert[Before|After|Instead].

I second the request for the name "replace".  Despite the consistency, I think replace is clear to programmers as well as being more familiar and comfortable.  Also, the operation really isn't "insert instead", it's "delete then insert instead".  So there is lack of symmetry because it removes elements while the other does not.

Another  issue I see is that opIndex and its brethren takes KeyType, but for something like vector, this should be size_t..  I don't think you want ElementType to be tuple!(size_t, ElementType) in this case.  

Related to this, do you intend removal of a single element to use remove(range) or removeKey?

Finally, opSlice(begin, end) is not there.  Was this intentional or overlooked?

Jerry



More information about the Digitalmars-d mailing list