On 06/11/14 14:40, monarch_dodra via Digitalmars-d-learn wrote:
> For example, you should avoid "countUntil" and "takeExactly" when dealing
> with strings, since these are not O(1) operations, and don't actually return
> string slices. EG:
> string s = "someGGGreatVariableName".slicer().front;
> Error: cannot implicitly convert expression
> (slicer("someGGGreatVariableName").front()) of type Result to string
That's a problem with D's string handling. For both examples and rarely
called code, i always prefer correctness over performance. Of course if
that code ends up being perf significant it could be further optimized by
adding a specialization for D strings...
> That's why the splitter code uses the more verbose "r.length - r.find!pred".
... but that's the wrong approach. You end up writing a string-specific
(or -aware) special version for practically every algorithm...
If, instead, you create a string-specific 'countUntil' that returns
a type that holds both the byte and code-point counts and implicitly
converts to the latter, then you can have a 'takeExactly' overload
that uses the extra info to avoid the unnecessary decoding and is able
to directly return slices. The overhead is minimal; one extra integer
that's passed around, and often completely eliminated by function inlining.
But now you don't need to write a string-specific version of every
algorithm. (Of course this description is slightly oversimplified)
There is a reason why I never use D's std lib.
artur
