SeeWebsiteForEmail at erdani.org
Wed May 26 08:00:39 PDT 2010
On 05/26/2010 01:45 AM, Don wrote:
> 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?
Renamed to "stable".
More information about the Digitalmars-d