reflection based on my experience so far on compile-time meta-programming in D as a novice user: the problems
mingwu at gmail.com
Tue Sep 15 01:44:25 UTC 2020
On Tuesday, 15 September 2020 at 00:41:12 UTC, H. S. Teoh wrote:
> If you already have these declarations, what's the purpose of
> "generating" them? Just curious if there is a reason for this,
> or this is just some arbitrary decision?
The is the same usage pattern to call hundreds of such TA_xxx
-- check the input params
-- calculate TA_xxx_lookback
-- call the raw C func
-- zero out the lookback area
-- return status
> I don't understand this phobia of string mixins -- they were
> included in D
I'm not phobia to string mixins; I'm saying that because Steven
provide one such solution already (see summary 3 below), and pure
string mixins solution is no different from C's macros solution
(or use a Python script to output strings as generated D code).
> I'd say, the way I'd do it is to slurp the entire argument list
> into a single variadic parameter, and handle the breakdown of
> the parameter groups manually
I saw you method.
That's what I want to avoid, as the discussion with Paul earlier,
> So now, what do with do with the arguments we received?
> According to the above linked page, we have a list of start/end
> indices, which I assume should come in pairs? (Correct me if
> I'm wrong.) At first I thought the number of pairs must match
> the number of input arrays, but apparently I'm wrong, based on
> your examples above?
to use a single variadic parameter and *then* break them down,
you need extra assumptions on the different groups of actual
(1) we do NOT have so much assumptions on these groups of params,
neither on each individual type, or the total number of them in
each of the groups.
(2) even if we do have some assumptions, this kind of breakdown
(a kind of simple parsing) code is fragile to maintain.
That's why I also asked Paul, is there any D Marker type I can
use: i.e. split the single variadic parameter based on some
> bool TA(string funcName, Float, Args...)(Args args)
> if (is(Float == float) || is(Float == double))
> enum nPairs = NumPairs!Args;
> enum arraysStart = 2*nPairs;
As said, we don't have such assumptions to calculate the
arraysStart index; let's just assume we have some other ways to
calculate, this breakdown code is going to be more complex than
you are showing in your solution.
So far, I've got 4 solutions:
1) my C-macros based solution,
#define MA_INS int MA_optInTimePeriod, TA_MAType optInMAType
#define MA_OUTS outMA
DECL_TA_FUNC(TA_MA, MA_INS, MA_OUTS, (MA_optInTimePeriod-1))
Note: the input parameters are *logically* grouped, no need the
breakdown parsing logic.
2) Paul's solution based on the same logical grouping idea as
mine, but use D-template:
which I quoted to started this thread in general.
3) Steven's solution based on D string mixin
4) your solution based on breakdown single variadic parameter.
I'm wondering if Paul, Steven, and you have time each to summit a
proper working PR, and we ask the forum users to vote which one
is most readable, and maintainable; and which one is most
More information about the Digitalmars-d