Comment #0 by remi.thebault — 2016-12-28T15:20:28Z
Use case:
- efficiently map a dchar to some unicode properties not supported in std.uni
example of workflow:
- in a separate program:
1. build a AA of the required mapping
2. build a std.uni.Trie out of this AA (e.g. using std.uni.codepointTrie)
3. store the trie entry tables in a generated D module
- in the application/library code:
4. rebuild the Trie from the entry tables.
Steps 1 to 3 are already supported by std.uni, though not documented (I had to dive into std.uni code to understand how it must be done).
Step 4 is currently not directly feasible as the Trie ctor that take the entry tables is private.
I could workaround by copying the following 'TrieEntry' struct and 'asTrie' function in my own code (which still happen to call the private ctor, but both dmd and ldc seem to accept it somehow)
struct TrieEntry(T...)
{
size_t[] offsets;
size_t[] sizes;
size_t[] data;
}
@safe pure nothrow auto asTrie(T...)(in TrieEntry!T e)
{
return const(CodepointTrie!T)(e.offsets, e.sizes, e.data);
}
Comment #1 by remi.thebault — 2017-01-08T09:57:57Z
In addition, it should be supported to store the table for both 32 bits and 64 bits.
Currently the Trie.store method outputs D code for the running architecture only.
64 bits code output cannot compile in 32 bits.
32 bits code output will compile in 64 bits, but will likely give false results.
And what about endianness?
Comment #2 by robert.schadek — 2024-12-01T16:29:08Z