Small Buffer Optimization for string and friends
Tove
tove at fransson.se
Sun Apr 8 07:11:10 PDT 2012
On Sunday, 8 April 2012 at 13:53:07 UTC, H. S. Teoh wrote:
> On Sun, Apr 08, 2012 at 12:56:38AM -0500, Andrei Alexandrescu
> wrote:
> [...]
>> 1. What happened to the new hash project? We need to take that
>> to
>> completion.
> [...]
>
> Sorry, I've been busy at work and haven't had too much free
> time to work
> on it. The current code is available on github:
>
> https://github.com/quickfur/New-AA-implementation
>
> The major outstanding issues are:
>
> - Qualified keys not fully working: the current code has a few
> corner
> cases that don't work with shared/immutable/inout keys. One
> major
> roadblock is how to implement this:
>
> alias someType T;
> inout(T) myFunc(inout(T) arg, ...) {
> int[inout(T)] aa;
> ...
> }
>
> The problem is that inout gets carried over into the AA
> template,
> which breaks because it instantiates into something that has:
>
> struct Slot {
> hash_t hash;
> inout(T) key; // <-- this causes a compile error
> Value value;
> }
>
> Ideally, AA keys should all be stored as immutable inside the
> AA, and
> automatically converted to/from the qualified type the user
> specified.
>
> - Template bloat: the current code uses template member
> functions, and
> will instantiate a new function for every implicit conversion
> of input
> key types. This also depends on IFTI, which has some quirks
> (compiler
> bugs) that make the code ugly (e.g., strings and arrays not
> treated
> equally by the compiler, requiring hacks to make implicit
> conversion
> work). Timon has suggested an alternative way of handling
> implicit
> conversions, which I think is better, but I need to take some
> time to
> actually implement it.
>
> - Static initialization of AA's (AA literals that compile
> directly into
> object code). This should be possible in principle, but I've
> run into
> what may be a CTFE bug that prevents it from working.
>
> - A not-so-major issue is to finish the toHash()
> implementations for all
> native types (currently it works for some common key types,
> but
> coverage is still incomplete). Once this is done, we can
> finally get
> rid of getHash from TypeInfo; UFCS will let us simply write
> x.toHash()
> for pretty much any type x.
>
> Once these issues are resolved, there remains the major task of
> actually
> integrating this code with druntime/dmd. A lot of work is
> expected on
> the dmd end, because of the current amount of hacks in dmd to
> make AA's
> work.
>
>
> T
doesn't this work?
immutable std.traits.Unqual!(inout(T)) key;
More information about the Digitalmars-d
mailing list