On 03/24/2018 12:37 PM, Manu wrote:
I understand table generation, that is the standard approach. It's
Huh? Then I guess I don't understand why you implied that the
alternative to CTFE was manually regenerating and copy-pasting tables:
>> On 3/23/2018 11:09 AM, Manu wrote:
>>> Like, in this particular project, being able to generate all tables at
>>> compile time is the thing that distinguishes the D code from the C++
>>> code; it's the *whole point*... If I have to continue to generate
>>> tables offline and paste big tables of data in the source code (and
>>> then re-generate them manually when I change something);
I'm not sure why I seem to have to defend the idea that it's a *great
thing* that D (in theory; according to the advertising brochure) does
away with these requirements.
No need to defend it, we're all sold on it already. To clarify: I wasn't
saying "no need for CTFE", I was saying: "If you *have* to work around
an unfortunate CTFE limitation, like the missing x^^y, then it's not
hard to do so *without* all that manual work you suggested".
> made awkward by the fact that build systems are hard,
The decent ones aren't. (And if you happen to be stuck with MSBuild,
well, then my sincere condolences. I periodically use Unity3D and I wish
soooo much it wasn't tied to MSBuild...or CLR for that matter, but I
digress...frequently ;))
Frankly, if a buildsystem makes doing XYZ (ex: "executing a CLI command
upon build") harder than it would be in a shellscript, then the given
buildsystem sucks and you may as well replace it with a plain old script.
> and a user of a lib with such build requirement inherits that baggage
> into their project.
Meh, its about half an ounce of baggage for the user. (But again, yes,
CTFE is still better...at least when it doesn't slow down their build
too much). And its zero-baggage if the generated files aren't dependent
on the user's code, though I see now (below) that's not the case for
your project.
It just occurred to me too that it's not even that simple. The
instantiation sites (which are in user code) dictate what tables need
to be emit. It's not feasible to generate all possible tables...
there's a combinatorial explosion of possible inputs. I instantiate
only what tables the user needs on demand. It's impossible to
pre-generate 'all' tables; there's no such quantity.
I guess that does complicate it somewhat (and again, to be clear, being
able to just do CTFE would obviously be far better than this) but FWIW,
that still might not be difficult to overcome, depending on the exact
nature of the problem: Whatever inputs are necessary for table
generation, let the user specify them as cmdline args to your generator
tool. Again, not ideal, but a perfectly feasible workaround in a pinch,
and doesn't require abandoning all the *other* benefits of D.
