Thread overview
C macros vs D can't do the right thing
Jun 03, 2017
Russel Winder
Jun 03, 2017
ketmar
Jun 03, 2017
Nicholas Wilson
Jun 03, 2017
Jacob Carlborg
Jun 03, 2017
ketmar
Jun 03, 2017
David Nadlinger
Jun 03, 2017
Jacob Carlborg
Jun 04, 2017
Jonathan M Davis
Jun 03, 2017
David Nadlinger
June 03, 2017
A stripped down problem to avoid fluff. The C macro:

    #define FLOB(t) (sizeof(t))

Can be used in another macro:

    #define THINGY(a, b) (_THING(a, FLOB(b)))

We can use this as in:

    THINGY(10, __u32)

Now the D Way says use functions not macros. except that

    size_t FLOB(T)(auto ref T t) { return t.sizeof; }

which is the result of DStep doesn't allow passing a type name as t.

Is this a problem in D or a problem in DStep?

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

June 03, 2017
Russel Winder wrote:

> Now the D Way says...
..use templates! ;-)

it is not really possible to guess what macro author means (to do that, dstep should be able to actually *understand* the code), so it tries to do what is used more often.

that is, it's dstep failed guess.
June 03, 2017
On Saturday, 3 June 2017 at 13:17:46 UTC, Russel Winder wrote:
> A stripped down problem to avoid fluff. The C macro:
>
>     #define FLOB(t) (sizeof(t))
>
> Can be used in another macro:
>
>     #define THINGY(a, b) (_THING(a, FLOB(b)))
>
> We can use this as in:
>
>     THINGY(10, __u32)
>
> Now the D Way says use functions not macros. except that
>
>     size_t FLOB(T)(auto ref T t) { return t.sizeof; }
>
> which is the result of DStep doesn't allow passing a type name as t.
>
> Is this a problem in D or a problem in DStep?

I think an alias template parameter will work here as aliases take anything(types, literals, symbols).
June 03, 2017
On Saturday, 3 June 2017 at 13:17:46 UTC, Russel Winder wrote:
> Is this a problem in D or a problem in DStep?

It's a limitation of DStep – for that use case, it would need to transform one of the macro arguments into a template argument rather than a runtime function parameter.

If you need to make the code work as-is, I suppose you could create some aliases like `enum u32 = __u32.init;` and pass these instead of the types – using runtime values just to convey their type.

 — David
June 03, 2017
On 2017-06-03 16:03, Nicholas Wilson wrote:

> I think an alias template parameter will work here as aliases take
> anything(types, literals, symbols).

No, it doesn't work for types:

void foo(alias a)() {}

void main()
{
    foo!(int)();
}

Results in:

Error: template instance foo!int does not match template declaration foo(alias a)()

Perhaps using the variadic template with a constraint on one element trick will work. Ugly, but I think that will work.

-- 
/Jacob Carlborg
June 03, 2017
Jacob Carlborg wrote:

> Perhaps using the variadic template with a constraint on one element trick will work. Ugly, but I think that will work.

yeah. that's what Phobos does, for example.
June 03, 2017
On Saturday, 3 June 2017 at 14:19:00 UTC, Jacob Carlborg wrote:
> Perhaps using the variadic template with a constraint on one element trick will work. Ugly, but I think that will work.

We could also finally fix the frontend to get around this. At DConf 2015, Walter officially agreed that this is a bug that needs fixing. ;)

 — David
June 03, 2017
On 2017-06-03 16:22, David Nadlinger wrote:

> We could also finally fix the frontend to get around this. At DConf
> 2015, Walter officially agreed that this is a bug that needs fixing. ;)

That would be nice.

-- 
/Jacob Carlborg
June 04, 2017
On Saturday, June 03, 2017 14:22:11 David Nadlinger via Digitalmars-d-learn wrote:
> On Saturday, 3 June 2017 at 14:19:00 UTC, Jacob Carlborg wrote:
> > Perhaps using the variadic template with a constraint on one element trick will work. Ugly, but I think that will work.
>
> We could also finally fix the frontend to get around this. At DConf 2015, Walter officially agreed that this is a bug that needs fixing. ;)

He did agree, but AFAIK, no one has ever actually done the work, and I suspect that unless Walter gets frustrated over the problem himself, he won't get around to fixing it himself, but I don't know. I also have no idea how easy or hard the implementation would be. It really should be fixed at some point though, since it's clearly causing problems and consistently forcing us to have workarounds in the standard library.

- Jonathan M Davis