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