void func( alias T )(){
    Stdout.formatln( "member {} {} {}",
        T.offsetof,
        T.stringof,
        typeof(T).stringof );
}

class MyClass{
    uint data1;
    long data2;
    void reg(){
        func!(data1);
        func!(data2);
    }
}

With this mechanism, a template function can access the type, value and
external-scope name of the argument. But each call or func makes a new
instance of this template function.
Using such template function massively (like little text preprocessor
makros in C), will generate big binaries. Is that true?
Is there a better way?

Frank Benoit wrote:
> external-scope name of the argument. But each call or func makes a new
> instance of this template function.

The compiler should only instance each template once per type per compilation unit.  The linker should be able to remove duplicates across multiple compilation units.

--Steve

"Stephen Waits" <steve@waits.net> wrote in message news:f2al0r$1rjp$1@digitalmars.com...
> Frank Benoit wrote:
>> external-scope name of the argument. But each call or func makes a new instance of this template function.
>
> The compiler should only instance each template once per type per compilation unit.  The linker should be able to remove duplicates across multiple compilation units.
>
> --Steve

Right.  It'd end up not being any more bloated than defining several overloads of the function for various types.

Stephen Waits schrieb:
> The compiler should only instance each template once per type per compilation unit.  The linker should be able to remove duplicates across multiple compilation units.

Ok, 'should' is said twice :)

If i have this program:

void regMember( alias T )(){
   // use T.offsetof
   // use T.stringof
}

class MyClass {
    bool     data1;
    bool     data2;
    bool     data3;
    bool     data4;
    public void describe(){
        regMember!(data1);
        regMember!(data2);
        regMember!(data3);
        regMember!(data4);
    }

}
void main(){
}

compiled with:
dmd -c -g refl.d

and then doing this:
obj2asm refl.o | gvim -

This show 4 different functions containing "regMember" in their name, and four different function calls, matching exactly those 4 different functions.

The function name differ in the "data1" "data2" .. identifier. This is not a surprise, because the template argument is not simply a "T", it is "alias T", which enables me to get the external-scope names.

So i am not sure, if a different type instance in the template argument, does not also enforce a complete new template instance.

How can i check this?

Frank Benoit wrote:
> 
> Ok, 'should' is said twice :)

Intentionally so, because I don't know if Walter's compiler and linker behave this way.

Note that the compiler needn't do anything here - this may be completely handled by the linker.  In fact that's probably the smarter way to do it (DRY, etc.).

Can you look at a map file?  Your answer lies therein.

--Steve

Stephen Waits schrieb:
> Frank Benoit wrote:
>>
>> Ok, 'should' is said twice :)
> 
> Intentionally so, because I don't know if Walter's compiler and linker behave this way.
> 
> Note that the compiler needn't do anything here - this may be completely handled by the linker.  In fact that's probably the smarter way to do it (DRY, etc.).
> 
> Can you look at a map file?  Your answer lies therein.
> 
> --Steve

doing a objdump yields 4 functions with 4 different addresses.

An other approach can be this:

regMemberImpl( T )( inout T t, uint offset, char[] name ){
}
char[] rm( char[] name ){
    return "regMemberImpl( "~name~", "~name~".offsetof, \""~name~"\" );";
}

class MyClass{
    bool data1;
    void func(){
        mixin( rm( "data1" ));
    }
}

This avoids the template alias argument and is the first time, i see an advantage in using this text mixin :)

Frank Benoit wrote:
>> Can you look at a map file?  Your answer lies therein.
> 
> doing a objdump yields 4 functions with 4 different addresses.

Not sure what objdump does, but you need to see what's in the actual application/exe, not a single compilation unit.  We want to know what the linker outputs, not the compiler.  Maybe that's what you're looking at?  I'm not sure..

A linker map file will tell you.

That said, I wouldn't be surprised if the linker isn't stripping though - it's not a trivial task.

--Steve

Stephen Waits wrote:
> That said, I wouldn't be surprised if the linker isn't stripping though - it's not a trivial task.

s/stripping/stripping duplicate template instances/

--Steve

Stephen Waits schrieb:
> Frank Benoit wrote:
>>> Can you look at a map file?  Your answer lies therein.
>>
>> doing a objdump yields 4 functions with 4 different addresses.
> 
> Not sure what objdump does, but you need to see what's in the actual application/exe, not a single compilation unit.  We want to know what the linker outputs, not the compiler.  Maybe that's what you're looking at?  I'm not sure..
> 
> A linker map file will tell you.
> 
> That said, I wouldn't be surprised if the linker isn't stripping though - it's not a trivial task.
> 
> --Steve

i did use the objdump on the binary. So i /think/ this tells me, it did
not strip those duplicates.
But i really think they are not duplicates, they only would be, if the
alias argument is always exactly the same variable.

"Frank Benoit" <keinfarbton@googlemail.com> wrote in message news:f2ata2$2a7t$1@digitalmars.com...
>
> i did use the objdump on the binary. So i /think/ this tells me, it did
> not strip those duplicates.
> But i really think they are not duplicates, they only would be, if the
> alias argument is always exactly the same variable.

You're right; I was wrong in my last reply, I didn't see that it was an alias parameter.  A unique template instance will be created for each symbol you use as the alias parameter, as you've said.