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).
