www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Wouldn't if be great if ...

reply James Dunne <james.jdunne gmail.com> writes:
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).
Oct 31 2005
next sibling parent Dwight Freeney <dt apt.com> writes:
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.
 

Oct 31 2005
prev sibling next sibling parent clayasaurus <clayasaurus gmail.com> writes:
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).

Oct 31 2005
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"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.
Oct 31 2005
next sibling parent reply James Dunne <james.jdunne gmail.com> writes:
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
Nov 02 2005
next sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"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

 symbol names exist in their own scope, but the original intention of the

 was somehow lost in translation.  The ability to fabricate symbol names

 upon simple naming convention rules is missing from D.  That is what I

 most from the C/C++ world.  Or, can you show me how D's templates could

 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.)
Nov 03 2005
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
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

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."
Nov 03 2005
parent James Dunne <james.jdunne gmail.com> writes:
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.
Nov 03 2005
prev sibling parent reply Dwight Freeney <dt apt.com> writes:
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?
Nov 02 2005
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"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.
Nov 03 2005
parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:
 "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.

Couldn't you use a hash table, and encode the hash in the name, instead of the string itself? That would at least overcome the length problem. The problem is with the linker, right? You'd need to store the hash table, (which might not even be possible with the OBJ formats?) and then combine hash tables when a collision occurs. I'm interested in this, to know whether using a constant array as a template value parameter is even theoretically feasible. It should always be possible to convert a arbitrary-length array of constants (or constant structs) into an arbitrary-length string, so this seems to be a fundamental restriction on template value parameters.
Nov 03 2005
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Don Clugston wrote:
 
 I'm interested in this, to know whether using a constant array as a 
 template value parameter is even theoretically feasible.

Strings are already valid template parameters in C++ and D, though it's just the address that ends up being a part of the signature. Sean
Nov 04 2005
parent reply Don Clugston <dac nospam.com.au> writes:
Sean Kelly wrote:
 Don Clugston wrote:
 
 I'm interested in this, to know whether using a constant array as a 
 template value parameter is even theoretically feasible.

Strings are already valid template parameters in C++ and D, though it's just the address that ends up being a part of the signature. Sean

Does not work for me. Not as a value parameter. -------- template funcA(char [] a) { const int funcA=1; } int main() { return funcA!("does this work")); } ---------- Error: integral type expected for value-parameter, not char[] -------------
Nov 04 2005
parent reply Sean Kelly <sean f4.ca> writes:
Don Clugston wrote:
 Sean Kelly wrote:
 
 Don Clugston wrote:
 I'm interested in this, to know whether using a constant array as a 
 template value parameter is even theoretically feasible.

Strings are already valid template parameters in C++ and D, though it's just the address that ends up being a part of the signature.

Does not work for me. Not as a value parameter.

Hrm... This is how you do it in C++: #include <cstdio> template<char* c> void fn() { printf( "%s\n", c ); } char buf[] = "abc"; int main() { fn<buf>(); } I could have sworn I did this once in D, but this is the closest I can get: import std.c.stdio; template fn(alias c) { void fn() { printf( "%.*s\n", c ); } } char[] buf = "abc"; void main() { fn!(buf)(); } I just remembered something doing this however. Template parameters must have external linkage to avoid violating the one definition rule... and const values are static. Sean
Nov 04 2005
parent reply Don Clugston <dac nospam.com.au> writes:
Sean Kelly wrote:
 Don Clugston wrote:
 
 Sean Kelly wrote:

 Don Clugston wrote:

 I'm interested in this, to know whether using a constant array as a 
 template value parameter is even theoretically feasible.

Strings are already valid template parameters in C++ and D, though it's just the address that ends up being a part of the signature.

Does not work for me. Not as a value parameter.

Hrm... This is how you do it in C++: #include <cstdio> template<char* c> void fn() { printf( "%s\n", c ); } char buf[] = "abc"; int main() { fn<buf>(); } I could have sworn I did this once in D, but this is the closest I can get: import std.c.stdio; template fn(alias c) { void fn() { printf( "%.*s\n", c ); } } char[] buf = "abc"; void main() { fn!(buf)(); } I just remembered something doing this however. Template parameters must have external linkage to avoid violating the one definition rule... and const values are static. Sean

As I already posted to this ng, I found that is possible to do it with alias parameters. You wrap the constant inside a template (so basically you are doing the name mangling manually). In contrast to the C++ version, it's completely evaluated at compile time (you're not recieving a pointer to a static string, you're recieving the string literal itself). {{ Now, use static if on the contents of the string literal. Suppose that string is a definition of a regular expression. You can compile a lexer, just like Boost::Spirit, except that since you're using a string there are absolutely no syntax restrictions.... Use a mixin and get access to local variables in the function that called the template... you have a primitive compiler compiler... I have to stop, my mind is starting to explode. }} But anyway, this is how you can do strings. ------------------------------ template fn(alias c) { void fn() { printf( c!() ~ \n ); // look mum, no % } } template buf() { const char[] buf = "abc"; } int main() { fn!(buf)(); return 0; }
Nov 09 2005
parent reply Sean Kelly <sean f4.ca> writes:
Don Clugston wrote:
 
 As I already posted to this ng, I found that is possible to do it with 
 alias parameters.

Oops, I missed that post.
 But anyway, this is how you can do strings.
 ------------------------------
 
 template fn(alias c)
 {
    void fn()
    {
       printf( c!() ~ \n );   // look mum, no %
    }
 }
 
 template buf()
 {
    const char[] buf = "abc";
 }
 
 int main()
 {
    fn!(buf)();
    return 0;
 }

So an alias to a template is evaluated at compile-time? Makes sense I suppose, though it wouldn't have occurred to me right off. I feel like we're tricking the compielr by doing this, but it works so I won't complain :) I suppose doing something like Spirit would require writing a compile-time regexp parser? Probably a lot less awkward than it would be in C++. Sean
Nov 09 2005
parent Don Clugston <dac nospam.com.au> writes:
Sean Kelly wrote:
 Don Clugston wrote:
 
 As I already posted to this ng, I found that is possible to do it with 
 alias parameters.

Oops, I missed that post.
 But anyway, this is how you can do strings.
 ------------------------------

 template fn(alias c)
 {
    void fn()
    {
       printf( c!() ~ \n );   // look mum, no %
    }
 }

 template buf()
 {
    const char[] buf = "abc";
 }

 int main()
 {
    fn!(buf)();
    return 0;
 }

So an alias to a template is evaluated at compile-time? Makes sense I suppose, though it wouldn't have occurred to me right off. I feel like we're tricking the compielr by doing this, but it works so I won't complain :)

I think it's no different to template template parameters in C++. The important difference, though, is that any compile-time constant can be in a D template. I suppose doing something like Spirit would require writing
 a compile-time regexp parser?  Probably a lot less awkward than it would 
 be in C++.

Yes, I think so. Since Spirit is kind of a "flagship product" of C++ templates, it would be great to have a "proof of concept" to show that such a thing is possible in D. When I started looking a D a few months ago, I thought that D templates were a lot less powerful than C++, because they don't yet have implicit instantiation; but that D had enough other appealing features to compensate for that deficiency. It was a shock to discover that rather, D templates are fundamentally much more powerful than C++ templates. (This is not the impression you get from the docs. I'd like to construct some convincing examples).
Nov 09 2005
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Don Clugston" <dac nospam.com.au> wrote in message
news:dkf3i5$viu$1 digitaldaemon.com...
 Couldn't you use a hash table, and encode the hash in the name, instead
 of the string itself? That would at least overcome the length problem.
 The problem is with the linker, right?
 You'd need to store the hash table, (which might not even be possible
 with the OBJ formats?) and then combine hash tables when a collision

 I'm interested in this, to know whether using a constant array as a
 template value parameter is even theoretically feasible.
 It should always be possible to convert a arbitrary-length array of
 constants (or constant structs) into an arbitrary-length string, so
 this seems to be a fundamental restriction on template value parameters.

One could convert the string to a hex representation and encode that into the identifier, but then one runs into the problem that the object file format can't deal with identifiers longer than a thousand characters or so. And yes, it does happen!
Nov 05 2005
parent xs0 <xs0 xs0.com> writes:
Walter Bright wrote:
 "Don Clugston" <dac nospam.com.au> wrote in message
 news:dkf3i5$viu$1 digitaldaemon.com...
 
Couldn't you use a hash table, and encode the hash in the name, instead
of the string itself? That would at least overcome the length problem.
The problem is with the linker, right?
You'd need to store the hash table, (which might not even be possible
with the OBJ formats?) and then combine hash tables when a collision

occurs.
I'm interested in this, to know whether using a constant array as a
template value parameter is even theoretically feasible.
It should always be possible to convert a arbitrary-length array of
constants (or constant structs) into an arbitrary-length string, so
this seems to be a fundamental restriction on template value parameters.

One could convert the string to a hex representation and encode that into the identifier, but then one runs into the problem that the object file format can't deal with identifiers longer than a thousand characters or so. And yes, it does happen!

What about something silly like - convert all arrays into some canonical hex string form - concatenate them using some separator - calculate a hash like MD5 or whatever of the entire thing and use that? guaranteed not to exceed 32 characters, and practically guaranteed to be unique, unless someone really really really tries to break it :) xs0
Nov 07 2005