Templates and stringof...

Era Scarecrow rtcvb32 at yahoo.com
Sat Aug 4 03:08:32 PDT 2012


On Saturday, 4 August 2012 at 08:53:20 UTC, David Nadlinger wrote:
> How do you determine what the »local level« is? A string 
> mixin isn't something you can »call«, just a compile-time 
> constant string, which can be »evaluated« in a completely 
> different place than it can be constructed. Maybe some 
> heuristic could be used, but it's not worth the trouble, in my 
> opinion.

Mmm I would define it as the first one to call on any templates, 
at least if you plan on mixing stuff at that spot, further 
called/aliased stuff carries over the same information regardless 
how many levels deep it goes. If it began inside a template or 
from another function then I really don't know, probably holds 
the local scope from that level (or none at all).

> Why would it be dirty? String mixins are just compile-time code 
> generation. Also, using template constraints has almost zero 
> benefits if overload resolution is not involved anyway – 
> remember, this is just about the helper function/template 
> generating the string to be mixed in.

Depending on how many asserts I need to add in the string output 
seems a bit much if there may be more for the checks after the 
generation than before, or the ratio of checks in the returned 
string outweigh the actual code you want; Or so I would think. If 
all the checks are static than it won't show up in the 
executable, but if you need to output it out to glance over the 
generated code it would be quite messy to sift through it, 
depending on how complex it got.

But I'm probably wrong.

> As I said, there are almost always ways to achieve what you 
> want without resorting to getting the string representation of 
> an alias parameter. For example:

> ---
> mixin template BitfieldsOn(alias target, <…>) if 
> (isIntegral!(typeof(target))) {
>     mixin({
>         string code;
>         // Generate code using "target" as identifier.
>         return code;
>     }());
> }
>
> mixin BitfieldsOn!(foo, <…>);

  I really don't see how that is an improvement. If the only way 
to use the mixin properly is the full variable location as a 
string (and stringof won't do) than the only acceptable input is 
a string; Since strings won't hold the type information...

  It ends up with a mixin calling another mixin.


More information about the Digitalmars-d mailing list