• JS (29/29) Jul 29 2013 Here is a optimal generic string joiner that maximizes compiler
• JS (14/43) Jul 29 2013 BTW, one can wrap the template to remove the mixin in #6 but this

"JS" <js.mdnq gmail.com> writes:

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.

"JS" <js.mdnq gmail.com> writes:

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.


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