Generic string join
JS
js.mdnq at gmail.com
Mon Jul 29 04:41:03 PDT 2013
On Monday, 29 July 2013 at 09:01:36 UTC, JS wrote:
> Here is a optimal generic string joiner that maximizes compiler
> optimization, allows for a variable number of arguments that
> can be strings or arrays of strings.
>
> http://dpaste.dzfl.pl/0a021e1f
>
> Drawbacks:
> 1. Static if explosion
> 2. Not elegant
> 3. Only works with RT strings or RT string arrays, would be
> nice to work with chars and possibly others.
> 4. Does not have the ability to use book ends
> delimitation... not difficult to do but just more bloat-code.
> 5. Would be nice to allow apply a lambda to each "element".
> Again, not hard but requires all those special cases to deal
> with proper delimitation due to the recursion required.
> 6. Requires a mixin statement... this is not pretty at all.
> One can't wrap the mixin in a normal function call because it
> defeats the purpose of optimization(CT strings will be passed
> as variables and not optimized by the CT).
> etc...
>
> While I have some code to flatten such arrays before
> delimitation, which would probably make it much easier, which
> is the way I started, the code was going to turn out to be the
> same in the end as the flattener, so I just modified the
> code(basically use string concatenation instead of tuple
> concatenation).
>
>
> Anyways, maybe someone has a good idea how to improve the code
> to achieve the same results. Note in in the test, every
> possible 3-combination is tried, which I think is good enough
> to prove the validity of the code.
BTW, one can wrap the template to remove the mixin in #6 but this
is not very satisfactory as it has a much higher performance hit
for CT joining.
template t(T...)
{
string t(string d, T args)
{
return mixin(tJoin!(",", args));
}
}
mixin(tJoin!(",", "a", "b")) is just 4 instructions max. Using t
is about 10-15 times that(although I'm not sure if inlining will
solve that).
More information about the Digitalmars-d-learn
mailing list