View mode: basic / threaded / horizontal-split · Log in · Help
October 31, 2005
Wouldn't if be great if ...
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).
October 31, 2005
Re: Wouldn't if be great if ...
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.
>
October 31, 2005
Re: Wouldn't if be great if ...
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).
November 01, 2005
Re: Wouldn't if be great if ...
"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.
November 03, 2005
Re: Wouldn't if be great if ...
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
November 03, 2005
Re: Wouldn't if be great if ...
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?
November 03, 2005
Re: Wouldn't if be great if ...
"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.)
November 03, 2005
Re: Wouldn't if be great if ...
"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.
November 03, 2005
Re: Wouldn't if be great if ...
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."
November 03, 2005
Re: Wouldn't if be great if ...
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.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home