nospam at nospam.com
Tue May 25 23:45:03 PDT 2010
Andrei Alexandrescu wrote:
> I've uploaded a work in progress on the container design here:
> 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.
Looks great to me. A couple of comments:
> 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.
The softXXX primitives are listed as having the same complexity as the
non-soft primitives. Should it be explicitly stated that non-soft should
always be at least as fast as soft? (So that if you don't need the soft
guarantee, you should always use the non-soft primitive?)
Also, I agree with Jerry that something like "stable" would be more
intuitive than "soft". I guess it's not exactly the same meaning as
stableSort, but it's pretty close. A problem with the name "soft" is
that it's a harder, stronger guarantee! It seems to be a concept of a
"tame" removal as opposed to reckless, "savage" removal?
> So, this is it really: the containers specification is a collection of
> capabilities. A given container picks the ones it can support
> meaningfully, and user code has the specification as semantic and
> complexity guarantees.
> This design is quite far removed from Steve's, which makes the
> integration with dcollection tenuous. But at a minimum, maybe we can
> work out something in which Steve offers, with credit, implementation
> for this design and also offers dcollections as a separate library.
More information about the Digitalmars-d