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 

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 

 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 

 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

 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

 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


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.)
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

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."
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

 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;


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


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!
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