On 05.06.2012 1:16, Roman D. Boiko wrote:
On Monday, 4 June 2012 at 21:07:02 UTC, Roman D. Boiko wrote:
For example, one by
one would allow ignoring key encoding (and thus using multiple
encodings
simultaneously just as easily as single).
It's just as easy with the whole thing. Treat it as bytes ;)
Except when equivalent keys in different encodings should be treated
as equal.
I believe that once encoidng is established your compiler tool should
use the best code for that encoding. And that means templates, tailored
per encoding in my book.
If anything I plan to use Tries on strings without decoding codepoint,
just using length of it (as first stage, might need some tweak).
>> But now I can see that my counter-example is only partially
valid - walklength could be used instead of length (more expensive,
though), and dchars everywhere.
Another counter-example is searching for strings with specified prefix.
One-by-one fits better here. I didn't understand whether such use cases
are supported at both API and implementation levels.
They are not... *yawn*. Okay, I'll make it support InputRange of
typeof(Key.init[0]) along with specific key type iff key type is
RandomAccessRange :) It will not work however with SetAsSlot and MapAsSlot.
And before you run away with that horrible idea of ever decoding UTF in
lexer... Just don't do that. Trust me, it's not as small a price as it
seems at first. At least keep it only at prototype stage as it
simplifies things.
--
Dmitry Olshansky
