On Saturday, 4 January 2025 at 15:34:27 UTC, monkyyy wrote:
On Saturday, 4 January 2025 at 13:56:47 UTC, realhet wrote:
Id check that it is a string and not some sort of lazy wrapper
type doing worse of both world things; I usually use `enum
string[]` for mixin-y things when possible, idk what style your
doing and the q{} may have some extra logic.
That style indeed makes no sense on text mode.
Here's what it looks in graphic mode: https://youtu.be/8brvCoMaWyQ
At the end of the video I've tried out 4 versions.
The first one is super fast (--ftime-trace) -> It puts the table
in the global scope, then the mixin just inject a simple
transformation expression on it so the string[][] table is
transformed into a Struct[] in compile time.
But the big difference is that the later 3 versions are putting
data onto the string surface of the mixin. They use the
universal std text() template function to do that. And that is
working extremely slow inside the context of the Compile Time.
When I look at the --ftime-trace, I see text() formatValue()
everywhere. It feels like the CT version of text() does
everything by the limited but safe tools of CT environment,
something like CtRegexpr. It looks like they discover their
parameter signatures every time from zero. They can't remember
that they already compiled text(string[]) formatValue(string),
etc.
Both of those CT things (text, format, regexpr) are awesome but I
guess I should avoid them while using string mixins.
Maybe those 'lazy wrappers' you mentioned can be inside text()?
My wrapper struct named with a chinese character is rellly
simple: struct S{ string[][] rows; } first member is the table
rows with the cells.
q{} always worked perfectly. I have no fear of that.
Also no problems with the new goodies: iq{} and ${} I'm testing
them like crazy, I really like them.
Only the very complex stuff works weird in CT -> text, format...
