std.container & ranges
Steven Schveighoffer
schveiguy at yahoo.com
Thu Nov 3 11:37:27 PDT 2011
On Thu, 03 Nov 2011 14:08:31 -0400, Dmitry Olshansky
<dmitry.olsh at gmail.com> wrote:
> On 03.11.2011 21:13, Steven Schveighoffer wrote:
>>
>> dcollections stipulates that all ranges/cursors can be verified in
>> O(lgn) time or better to belong to a specific container. In some cases,
>> this adds an extra word to the range/cursor, and in others, it's easy to
>> determine or the owner-reference was already needed. Since everything is
>> a class, the fallback is to just stick an owner class instance in the
>> range.
>>
>> This stipulation is necessary to allow safe slicing.
>>
>
> Seems reasonable, I'd expect checks to go away in release, right(?).
For the moment, no. I am not sure whether this is the right decision or
not, because once you get beyond arrays, when to do bounds checks becomes
fuzzy.
For example, imagine you have this:
auto ts = new TreeSet!int(1, 3, 5, 7, 9);
What does this mean?
auto r = ts[2..4];
Note that a range type for a treeset has a pointer to a begin and end node
for the container. For arrays, not doing a bounds check is simply less
code. For a RBTree, you still have to look for the specific node, even if
you are in release mode.
Another example:
auto ts2 = ts.dup; // duplicate the treeset
auto c1 = ts2.elemAt(3); // get the node for 3 in ts2
auto r2 = ts[c1..ts.end];
Here I can say, we can skip the belongs check (which is an O(lgn) walk up
the tree).
But I'm still doing it in release mode. I'm not sure what's best. Should
I just do the least work possible, or should I make it consistent with
ts[2..4]?
-Steve
More information about the Digitalmars-d-learn
mailing list