The *ONE* feature I miss from C++ (and C)'s preprocessor is the ability to fabricate names of symbols from macros using the token-pasting operator #.  If D had a feature to support this sort of thing cleanly, it would be killer - especially within templates!!  Alas, I resort to home-brewn D code generators tied into the build process =P.

Also, I'm not sure how this would stack up to the power of the above suggestion, but this would also be cool:

Implicitly define (from the compiler) a functioninfo structure for functions, just like classes have a classinfo structure.  Yes, it'd be a bit more work, but could be accomplished through a property-like syntax.  Just say "functionname.functioninfo" and you could have member fields like "char[] name", "Box[] arguments", etc.  So in order to programmatically grab the name of a function, just call 'myFunction.functioninfo.name".

I suppose this is similar to a reflection mechanism, but not quite all the way since not all D constructs inherit from Object (i.e. basic types, structs).

Yeah I miss this quite a lot. Ive been trying to work around it with mixins but its just not the same.


James Dunne wrote:
> The *ONE* feature I miss from C++ (and C)'s preprocessor is the ability to fabricate names of symbols from macros using the token-pasting operator #.  If D had a feature to support this sort of thing cleanly, it would be killer - especially within templates!!  Alas, I resort to home-brewn D code generators tied into the build process =P.
> 

agreed. I too would have a use for this.

James Dunne wrote:
> The *ONE* feature I miss from C++ (and C)'s preprocessor is the ability to fabricate names of symbols from macros using the token-pasting operator #.  If D had a feature to support this sort of thing cleanly, it would be killer - especially within templates!!  Alas, I resort to home-brewn D code generators tied into the build process =P.
> 
> Also, I'm not sure how this would stack up to the power of the above suggestion, but this would also be cool:
> 
> Implicitly define (from the compiler) a functioninfo structure for functions, just like classes have a classinfo structure.  Yes, it'd be a bit more work, but could be accomplished through a property-like syntax.  Just say "functionname.functioninfo" and you could have member fields like "char[] name", "Box[] arguments", etc.  So in order to programmatically grab the name of a function, just call 'myFunction.functioninfo.name".
> 
> I suppose this is similar to a reflection mechanism, but not quite all the way since not all D constructs inherit from Object (i.e. basic types, structs).

"James Dunne" <james.jdunne@gmail.com> wrote in message news:dk5ql8$1k7f$1@digitaldaemon.com...
> The *ONE* feature I miss from C++ (and C)'s preprocessor is the ability to fabricate names of symbols from macros using the token-pasting operator #.  If D had a feature to support this sort of thing cleanly, it would be killer - especially within templates!!  Alas, I resort to home-brewn D code generators tied into the build process =P.

The problem with it is one could then not separate the lexical pass from the rest of the compilation process.

But I'm not sure why it's necessary, as names within templates are unique because they exist in a separate scope. The preprocessor thing is needed for C/C++ because of their poor scoping rules resulting in conflicting names.

In article <dk6mok$27gg$1@digitaldaemon.com>, Walter Bright says...
>
>
>"James Dunne" <james.jdunne@gmail.com> wrote in message news:dk5ql8$1k7f$1@digitaldaemon.com...
>> The *ONE* feature I miss from C++ (and C)'s preprocessor is the ability to fabricate names of symbols from macros using the token-pasting operator #.  If D had a feature to support this sort of thing cleanly, it would be killer - especially within templates!!  Alas, I resort to home-brewn D code generators tied into the build process =P.
>
>The problem with it is one could then not separate the lexical pass from the rest of the compilation process.
>

I'll give this issue some serious thought... I don't want to rush a "dumb" answer just to get an answer out ;)

>But I'm not sure why it's necessary, as names within templates are unique because they exist in a separate scope. The preprocessor thing is needed for C/C++ because of their poor scoping rules resulting in conflicting names.
>

Instead of trying to generalize my intentions for this feature "proposal", let me describe my specific situation:

In this mathematical model I'm creating (same one I noted before in the proposal to initialize doubles to SNaNs instead of QNaNs), I need to interface to VB through a set of extern (Windows) C functions.  This model has many properties to be able to be changed from the VB interface, and so I have to expose A LOT of C functions (a get and set function per each property) in order to get this functionality.

Naturally, I'd like it to be readable on the VB interface side, so I created a simple naming convention:  Get_PrettyVariableName and Set_PrettyVariableName. Of course, the internal variables in the model have much less friendly names, like 'h', 't', etc.  So I needed to create a mapping of 'pretty' external names to the 'ugly' internal names.

In C, this is simple to do with the pre-processor - just make a macro defining both the Get and Set methods, given a pretty name, an ugly name, and the type of the variable and then call that macro repeatedly for each property I want to expose.  However, in D I have no way of fabricating these 'pretty' function names so I resorted to writing a D code generator (written in D of course ;)) which reads the mapping of the pretty names to ugly names from a simple CSV file and generates the function bodies.  This tool is executed automatically from my compile.bat script.

By now, I hope you understand my meaning.  You are correct in that template symbol names exist in their own scope, but the original intention of the my post was somehow lost in translation.  The ability to fabricate symbol names based upon simple naming convention rules is missing from D.  That is what I miss the most from the C/C++ world.  Or, can you show me how D's templates could solve my problem, if possible?

Regards,
James Dunne

Walter Bright wrote:
> 
> The problem with it is one could then not separate the lexical pass from the
> rest of the compilation process.
> 
> But I'm not sure why it's necessary, as names within templates are unique
> because they exist in a separate scope. The preprocessor thing is needed for
> C/C++ because of their poor scoping rules resulting in conflicting names.
> 
> 

Yeah thats what I was afraid of. This feature would be extremely usefull for constructing object properties with given names from a macro or a template. But I would be extremely happy if mixins actually had a scope when you supply a name, yet is able to access the outer scope.

for example

mixin Code!(a)	Value1;
mixin Code!(b)	Value2;

But This could cause name conflicts since the Value# scope is optional. I love the mixin behavior but what would be nice is some way to create them with their own scopes BUT allow them access to the 'this' pointer of the containing scope without a pointer. I realize this is sort of ridiculous breaks the concept of the mixin scoping but it would resolve most of the issues where I need to assemble an identifier with a macro, as I could just declare one such as Value1 in the example. Im not requesting this as a feature but giving it as an example where I am still finding D not as 'fullfilling' as C++. Of course I am still new to D and I am learning new things every day, I may be missing something. Its a fantastic language, Im just missing some of these tools.

Also is there any way to send a string constant into a template or mixin?

"James Dunne" <james.jdunne@gmail.com> wrote in message news:dkbsia$127l$1@digitaldaemon.com...
> By now, I hope you understand my meaning.  You are correct in that
template
> symbol names exist in their own scope, but the original intention of the
my post
> was somehow lost in translation.  The ability to fabricate symbol names
based
> upon simple naming convention rules is missing from D.  That is what I
miss the
> most from the C/C++ world.  Or, can you show me how D's templates could
solve my
> problem, if possible?

Thanks for clarifying it for me. I think the only way to do what you propose is the solution you're already using - a D program to generate D code. It's not a bad solution, I often resort to such. Take a look at the D front end code, a couple of the source files are generated by other programs! (Often the C preprocessor is inadequate for the task, too.)

"Dwight Freeney" <dt@apt.com> wrote in message news:dkcakt$1e1l$1@digitaldaemon.com...
> Also is there any way to send a string constant into a template or mixin?

That's a bit problematical as the string constant would have to be encoded into the template instantiated name.

James Dunne wrote:
> In article <dk6mok$27gg$1@digitaldaemon.com>, Walter Bright says...
> 
>>
>>"James Dunne" <james.jdunne@gmail.com> wrote in message
>>news:dk5ql8$1k7f$1@digitaldaemon.com...
>>
>>>The *ONE* feature I miss from C++ (and C)'s preprocessor is the ability
>>>to fabricate names of symbols from macros using the token-pasting
>>>operator #.  If D had a feature to support this sort of thing cleanly,
>>>it would be killer - especially within templates!!  Alas, I resort to
>>>home-brewn D code generators tied into the build process =P.
>>
>>The problem with it is one could then not separate the lexical pass from the
>>rest of the compilation process.
>>
> 
> 
> I'll give this issue some serious thought... I don't want to rush a "dumb"
> answer just to get an answer out ;)
> 
> 
>>But I'm not sure why it's necessary, as names within templates are unique
>>because they exist in a separate scope. The preprocessor thing is needed for
>>C/C++ because of their poor scoping rules resulting in conflicting names.
>>
> 
> 
> Instead of trying to generalize my intentions for this feature "proposal", let
> me describe my specific situation:
> 
> In this mathematical model I'm creating (same one I noted before in the proposal
> to initialize doubles to SNaNs instead of QNaNs), I need to interface to VB
> through a set of extern (Windows) C functions.  This model has many properties
> to be able to be changed from the VB interface, and so I have to expose A LOT of
> C functions (a get and set function per each property) in order to get this
> functionality.
> 
> Naturally, I'd like it to be readable on the VB interface side, so I created a
> simple naming convention:  Get_PrettyVariableName and Set_PrettyVariableName.
> Of course, the internal variables in the model have much less friendly names,
> like 'h', 't', etc.  So I needed to create a mapping of 'pretty' external names
> to the 'ugly' internal names.
> 
> In C, this is simple to do with the pre-processor - just make a macro defining
> both the Get and Set methods, given a pretty name, an ugly name, and the type of
> the variable and then call that macro repeatedly for each property I want to
> expose.  However, in D I have no way of fabricating these 'pretty' function
> names so I resorted to writing a D code generator (written in D of course ;))
> which reads the mapping of the pretty names to ugly names from a simple CSV file
> and generates the function bodies.  This tool is executed automatically from my
> compile.bat script.
> 
> By now, I hope you understand my meaning.  You are correct in that template
> symbol names exist in their own scope, but the original intention of the my post
> was somehow lost in translation.  The ability to fabricate symbol names based
> upon simple naming convention rules is missing from D.  That is what I miss the
> most from the C/C++ world.  Or, can you show me how D's templates could solve my
> problem, if possible?
> 
> Regards,
> James Dunne
Hum..., if that is a C preprocessor feature, why don't you just use the C preprocessor on the D file? Should work ok, unless I'm missing something.

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

Bruno Medeiros wrote:
> James Dunne wrote:
> 
>> In article <dk6mok$27gg$1@digitaldaemon.com>, Walter Bright says...
>>
>>>
>>> "James Dunne" <james.jdunne@gmail.com> wrote in message
>>> news:dk5ql8$1k7f$1@digitaldaemon.com...
>>>
>>>> The *ONE* feature I miss from C++ (and C)'s preprocessor is the ability
>>>> to fabricate names of symbols from macros using the token-pasting
>>>> operator #.  If D had a feature to support this sort of thing cleanly,
>>>> it would be killer - especially within templates!!  Alas, I resort to
>>>> home-brewn D code generators tied into the build process =P.
>>>
>>>
>>> The problem with it is one could then not separate the lexical pass from the
>>> rest of the compilation process.
>>>
>>
>>
>> I'll give this issue some serious thought... I don't want to rush a "dumb"
>> answer just to get an answer out ;)
>>
>>
>>> But I'm not sure why it's necessary, as names within templates are unique
>>> because they exist in a separate scope. The preprocessor thing is needed for
>>> C/C++ because of their poor scoping rules resulting in conflicting names.
>>>
>>
>>
>> Instead of trying to generalize my intentions for this feature "proposal", let
>> me describe my specific situation:
>>
>> In this mathematical model I'm creating (same one I noted before in the proposal
>> to initialize doubles to SNaNs instead of QNaNs), I need to interface to VB
>> through a set of extern (Windows) C functions.  This model has many properties
>> to be able to be changed from the VB interface, and so I have to expose A LOT of
>> C functions (a get and set function per each property) in order to get this
>> functionality.
>>
>> Naturally, I'd like it to be readable on the VB interface side, so I created a
>> simple naming convention:  Get_PrettyVariableName and Set_PrettyVariableName.
>> Of course, the internal variables in the model have much less friendly names,
>> like 'h', 't', etc.  So I needed to create a mapping of 'pretty' external names
>> to the 'ugly' internal names.
>>
>> In C, this is simple to do with the pre-processor - just make a macro defining
>> both the Get and Set methods, given a pretty name, an ugly name, and the type of
>> the variable and then call that macro repeatedly for each property I want to
>> expose.  However, in D I have no way of fabricating these 'pretty' function
>> names so I resorted to writing a D code generator (written in D of course ;))
>> which reads the mapping of the pretty names to ugly names from a simple CSV file
>> and generates the function bodies.  This tool is executed automatically from my
>> compile.bat script.
>>
>> By now, I hope you understand my meaning.  You are correct in that template
>> symbol names exist in their own scope, but the original intention of the my post
>> was somehow lost in translation.  The ability to fabricate symbol names based
>> upon simple naming convention rules is missing from D.  That is what I miss the
>> most from the C/C++ world.  Or, can you show me how D's templates could solve my
>> problem, if possible?
>>
>> Regards,
>> James Dunne
> 
> Hum..., if that is a C preprocessor feature, why don't you just use the C preprocessor on the D file? Should work ok, unless I'm missing something.
> 

That is possible and I have tried that, but the output the macros generate don't contain newline characters so everything is thrown on one line.  I prefer my code-generator for now.