www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD 0.140: Pure magic!

reply Don Clugston <dac nospam.com.au> writes:
Not everyone might realise just how revolutionary DMD 0.140 is for 
template metaprogramming.

I submitted this to pragma's DDL "D Dynamic Libraries", used to 
dynamically link to .obj files. In this example, we want to be able to 
call the function
uint add(uint, uint)
which was defined in test.testmodule.obj.
To do this, we need to know the mangled function name, which depends on 
the module name and the types of the parameters. Then we need to do a 
cast to a function pointer of the right type. But the new templates can 
do all the work for us.

THIS LINE:
----------------
auto add = mymodule.load!(uint, "test.testmodule.add", uint, uint)();
----------------
COMPILES TO:
----------------
uint function(uint a,uint b) add = cast(uint function(uint a,uint b)) 
mymodule.LoadExport("_D4test10testmodule3addFkkZk");
----------------
Full name mangling occurs at compile time.

Source available in the DDL forum at www.dsource.org. The code is not 
too obscure (much better than anything at Boost).

It currently only works for fundamental types and pointers. There's not 
enough compile-time or even run-time type info to do function pointers, 
for example. Some compile-time type info would be real nice...

This would be impossible to do in C++. Even to come close would be a 
nightmare.


PS: This code could also be used in the DLL example in the D docs at 
d/dll.html

The code :
-----------------
    alias void function(void*) MyDLL_Initialize_fp;
	FARPROC fp;
	MyDLL_Initialize_fp mydll_initialize;

	HMODULE h = LoadLibraryA("mydll.dll");

	fp = GetProcAddress(h, "D5mydll16MyDLL_InitializeFPvZv");
	if (fp == null)
	{   printf("error loading symbol MyDLL_Initialize()\n");
	    return 1;
	}

	mydll_initialize = cast(MyDLL_Initialize_fp) fp;
	(*mydll_initialize)(std.gc.getGCHandle());
-----------------

can be replaced with:
-------------
       auto mydll = LoadDModule("mydll.dll");
       auto init  = mydll.GetProc!(void, "mydll.MyDLL_Initialize", void 
*)();
       init(std.gc.getGCHandle());
------------
Nov 30 2005
next sibling parent reply "Matthew" <matthew stlsoft.com> writes:
he he. I came for a little group snoop, and this is the first post I looked
at, and ...


 This would be impossible to do in C++. Even to come close would be a
 nightmare.


... au contraire, mon ami. Can one pronounce "hubris"? <g>

I've just completed an intial version of just such a library, called
dl_call(), and we're currently having a discussion within the editorial 
panel of "The C++ Source" (http://www.artima.com/cppsource/index.html) on my 
idea of doing a series of articles describing proposing this to the C++ 
standards committee, and the ensuing acceptance/rejection.

(For anyone that's downloaded STLSoft 1.8.9, please ignore the nascent form
of dl_call() in the WinSTL sub-project. The full version is considerably
more full featured. It'll be part of the PlatformSTL sub-project, once I've
ported the code to support UNIX as well as Windows.)


Notwithstanding my slight bubble-pricking above, I don't doubt for a second 
that D's got a lot more welly in it since last I played in anger, and am 
looking forward to playing with it in a big way next year.

Cheers

Matthew
Nov 30 2005
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Matthew wrote:

 he he. I came for a little group snoop, and this is the first post I looked
 at, and ...
 

This would be impossible to do in C++. Even to come close would be a
nightmare.


 
 ... au contraire, mon ami. Can one pronounce "hubris"? <g>
 
 I've just completed an intial version of just such a library, called
 dl_call(),


I'm impressed, and rather intrigued - how do you parse a C++ string at 
compile time? And convert the string length to a text integer? I'd 
really like to see the code.

Certainly, it would have been a nightmare for *me* to do it in C++. 
Doing it in D was very straightforward (two nights work).

Hmmm, I'll have to try a bit harder.

and we're currently having a discussion within the editorial

 panel of "The C++ Source" (http://www.artima.com/cppsource/index.html) on my 
 idea of doing a series of articles describing proposing this to the C++ 
 standards committee, and the ensuing acceptance/rejection.


I'll look out for that.

 
 Notwithstanding my slight bubble-pricking above, I don't doubt for a second 
 that D's got a lot more welly in it since last I played in anger, and am 
 looking forward to playing with it in a big way next year.


Definitely. I look forward to seeing the results, too.
Nov 30 2005
next sibling parent pragma <pragma_member pathlink.com> writes:
In article <dmke9m$ott$1 digitaldaemon.com>, Don Clugston says...

Matthew wrote:

 he he. I came for a little group snoop, and this is the first post I looked
 at, and ...
 

This would be impossible to do in C++. Even to come close would be a
nightmare.


 
 ... au contraire, mon ami. Can one pronounce "hubris"? <g>
 
 I've just completed an intial version of just such a library, called
 dl_call(),


I'm impressed, and rather intrigued - how do you parse a C++ string at 
compile time? And convert the string length to a text integer? I'd 
really like to see the code.

Certainly, it would have been a nightmare for *me* to do it in C++. 
Doing it in D was very straightforward (two nights work).

Hmmm, I'll have to try a bit harder.


Don, here's something I've given some thought: are you familiar with XSLT/XPATH
2.0?

As XSL is a *template* language, it is most directly supported by the support
that XPATH brings to the table.  The 2.0 specification, especially for strings,
is the bare-minimum needed to do nearly any kind of parsing or processing one
could imagine (although some productions take some serious coding to work).

http://www.w3schools.com/xpath/xpath_functions.asp#string

Maybe the string portion of the spec (described at URL above) might point you in
the right direction for a more comprehensive/complete compile-time facility.  I
think slicing already covers most of these, leaving case-switching,
search-and-replace, and the like; I think these all boil down into combinations
of compare-and-slice and concat.  

Some kind of easy iteration (recursive template that takes args like for-each)
would be a huge plus too.

The really, really hard part?  The second argument to tokenize() is a
regular-expression.  Teach D how to do that at compile-time, and there's not
much left.


- EricAnderton at yahoo
Nov 30 2005
prev sibling parent Sean Kelly <sean f4.ca> writes:
Don Clugston wrote:

 Matthew wrote:

 he he. I came for a little group snoop, and this is the first post I 
 looked
 at, and ...


 This would be impossible to do in C++. Even to come close would be a
 nightmare.


 ... au contraire, mon ami. Can one pronounce "hubris"? <g>

 I've just completed an intial version of just such a library, called
 dl_call(),


 
 I'm impressed, and rather intrigued - how do you parse a C++ string at 
 compile time? And convert the string length to a text integer? I'd 
 really like to see the code.


Same here.  I think it would be possible to cobble something bearable 
together using a combination of macro and template language, but the 
result would look a lot more like input for Spirit than pure string 
manipulation.  The real nasty part here is that I don't think there's 
any way to split strings at compile-time in C++, so everything would 
likely have to be assembled from common substrings (perhaps even one per 
letter).


Sean
Nov 30 2005
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Matthew" <matthew stlsoft.com> wrote in message
news:dmk89b$jhi$1 digitaldaemon.com...

 This would be impossible to do in C++. Even to come close would be a
 nightmare.


 ... au contraire, mon ami. Can one pronounce "hubris"? <g>

 I've just completed an intial version of just such a library, called
 dl_call(), and we're currently having a discussion within the editorial
 panel of "The C++ Source" (http://www.artima.com/cppsource/index.html) on


my

 idea of doing a series of articles describing proposing this to the C++
 standards committee, and the ensuing acceptance/rejection.


A comparitive review would be fun. Want to go for it?
Nov 30 2005
prev sibling next sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Don Clugston wrote:

 Not everyone might realise just how revolutionary DMD 0.140 is for 
 template metaprogramming.
 
 I submitted this to pragma's DDL "D Dynamic Libraries", used to 
 dynamically link to .obj files. In this example, we want to be able to 
 call the function
 uint add(uint, uint)
 which was defined in test.testmodule.obj.
 To do this, we need to know the mangled function name, which depends on 
 the module name and the types of the parameters. Then we need to do a 
 cast to a function pointer of the right type. But the new templates can 
 do all the work for us.
 
 THIS LINE:
 ----------------
 auto add = mymodule.load!(uint, "test.testmodule.add", uint, uint)();
 ----------------
 COMPILES TO:
 ----------------
 uint function(uint a,uint b) add = cast(uint function(uint a,uint b)) 
 mymodule.LoadExport("_D4test10testmodule3addFkkZk");
 ----------------
 Full name mangling occurs at compile time.
 
 Source available in the DDL forum at www.dsource.org. The code is not 
 too obscure (much better than anything at Boost).


Not too obsure? The code is looking great and very understandable.


 
 It currently only works for fundamental types and pointers. There's not 
 enough compile-time or even run-time type info to do function pointers, 
 for example. Some compile-time type info would be real nice...
 
 This would be impossible to do in C++. Even to come close would be a 
 nightmare.
 
 
 PS: This code could also be used in the DLL example in the D docs at 
 d/dll.html
 


...
Nov 30 2005
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Don Clugston" <dac nospam.com.au> wrote in message
news:dmk465$fq3$1 digitaldaemon.com...

 THIS LINE:
 ----------------
 auto add = mymodule.load!(uint, "test.testmodule.add", uint, uint)();
 ----------------
 COMPILES TO:
 ----------------
 uint function(uint a,uint b) add = cast(uint function(uint a,uint b))
 mymodule.LoadExport("_D4test10testmodule3addFkkZk");
 ----------------
 Full name mangling occurs at compile time.


This is pretty incredible. I had no idea this could be done <g>.


 It currently only works for fundamental types and pointers. There's not
 enough compile-time or even run-time type info to do function pointers,
 for example. Some compile-time type info would be real nice...


What's missing from function pointers? Note that the name demangler
(std.demangle) can demangle function pointers, so the information must be
complete.
Nov 30 2005
parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:

 "Don Clugston" <dac nospam.com.au> wrote in message
 news:dmk465$fq3$1 digitaldaemon.com...
 

THIS LINE:
----------------
auto add = mymodule.load!(uint, "test.testmodule.add", uint, uint)();
----------------
COMPILES TO:
----------------
uint function(uint a,uint b) add = cast(uint function(uint a,uint b))
mymodule.LoadExport("_D4test10testmodule3addFkkZk");
----------------
Full name mangling occurs at compile time.


 
 This is pretty incredible. I had no idea this could be done <g>.


And it's not even ugly. That's a very primitive use of template string 
value parameters. Despite Matthew's comment, I do think we're crossing 
into unexplored territory.


It currently only works for fundamental types and pointers. There's not
enough compile-time or even run-time type info to do function pointers,
for example. Some compile-time type info would be real nice...


 
 What's missing from function pointers? Note that the name demangler
 (std.demangle) can demangle function pointers, so the information must be
 complete.


All the mangling information is present in a mangled string, but I don't 
know any way to find out what the function arguments are.
Suppose T is a function pointer type.

R function (P1, P2, P3)

What are R, P1, P2, P3 ? You can work out what R is, using
is(T R : function)
which gives you the type of the return value.
In C++, you can find out what P1, P2, P3 are, by using implicit template 
instantiation. But in D, I don't even know how I can work out how many 
parameters there are. (Maybe there is, and I've just missed it).

Even the runtime typeinfo structure seems to be incomplete.
Example:

writefln(typeid(int *), "  ", typeid(int function(char *, creal)));

prints:
int *    int()*

yet from std.demangle, it looks as though even inout vs out parameters 
are distinguished in the mangled name.

Musing...

Now, a simple-to-implement way of doing this, and ensuring that all 
presnt and future types are covered, would be to include a 
__mangletypeof() function or property, valid for any type, which 
converts a type to a const char[], using exactly the same mangling 
algorithm which is used by the linker for individual types.
So that std.demangle(__mangletypeof(int)) would return "int".

Note: if there was some kind of __demangletypeof() as well, we would 
have well-supported typelists by the backdoor -- mangle the types, 
perform string manipulations on them, and demangle when you're done. But 
perhaps this is all far, far too much rope...

Could also be done from a library, if we had implicit function template 
instantiation. But I'm guessing that's not coming any time soon.
Dec 01 2005
next sibling parent JT <JT_member pathlink.com> writes:
In article <dmmhfc$2m8p$1 digitaldaemon.com>, Don Clugston says...

Walter Bright wrote:

 "Don Clugston" <dac nospam.com.au> wrote in message
 news:dmk465$fq3$1 digitaldaemon.com...
 

THIS LINE:
----------------
auto add = mymodule.load!(uint, "test.testmodule.add", uint, uint)();
----------------
COMPILES TO:
----------------
uint function(uint a,uint b) add = cast(uint function(uint a,uint b))
mymodule.LoadExport("_D4test10testmodule3addFkkZk");
----------------
Full name mangling occurs at compile time.


 
 This is pretty incredible. I had no idea this could be done <g>.


And it's not even ugly. That's a very primitive use of template string 
value parameters. Despite Matthew's comment, I do think we're crossing 
into unexplored territory.


It currently only works for fundamental types and pointers. There's not
enough compile-time or even run-time type info to do function pointers,
for example. Some compile-time type info would be real nice...


 
 What's missing from function pointers? Note that the name demangler
 (std.demangle) can demangle function pointers, so the information must be
 complete.


All the mangling information is present in a mangled string, but I don't 
know any way to find out what the function arguments are.
Suppose T is a function pointer type.

R function (P1, P2, P3)

What are R, P1, P2, P3 ? You can work out what R is, using
is(T R : function)
which gives you the type of the return value.
In C++, you can find out what P1, P2, P3 are, by using implicit template 
instantiation. But in D, I don't even know how I can work out how many 
parameters there are. (Maybe there is, and I've just missed it).

Even the runtime typeinfo structure seems to be incomplete.
Example:

writefln(typeid(int *), "  ", typeid(int function(char *, creal)));

prints:
int *    int()*

yet from std.demangle, it looks as though even inout vs out parameters 
are distinguished in the mangled name.

Musing...

Now, a simple-to-implement way of doing this, and ensuring that all 
presnt and future types are covered, would be to include a 
__mangletypeof() function or property, valid for any type, which 
converts a type to a const char[], using exactly the same mangling 
algorithm which is used by the linker for individual types.
So that std.demangle(__mangletypeof(int)) would return "int".

Note: if there was some kind of __demangletypeof() as well, we would 
have well-supported typelists by the backdoor -- mangle the types, 
perform string manipulations on them, and demangle when you're done. But 
perhaps this is all far, far too much rope...

Could also be done from a library, if we had implicit function template 
instantiation. But I'm guessing that's not coming any time soon.


Yes, I feel like walter gave me a christmas present. Ive been wanting this from
c++ for ages. We have something pretty awesome here. As far as Im concerned
anyone whos not using D is missing out...
Dec 01 2005
prev sibling next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Don Clugston" <dac nospam.com.au> wrote in message
news:dmmhfc$2m8p$1 digitaldaemon.com...

 Walter Bright wrote:

 What's missing from function pointers? Note that the name demangler
 (std.demangle) can demangle function pointers, so the information must




be

 complete.


 All the mangling information is present in a mangled string, but I don't
 know any way to find out what the function arguments are.
 Suppose T is a function pointer type.

 R function (P1, P2, P3)

 What are R, P1, P2, P3 ? You can work out what R is, using
 is(T R : function)
 which gives you the type of the return value.
 In C++, you can find out what P1, P2, P3 are, by using implicit template
 instantiation. But in D, I don't even know how I can work out how many
 parameters there are. (Maybe there is, and I've just missed it).


Ok, I see what the problem is now. I don't have a solution at the moment.


 Even the runtime typeinfo structure seems to be incomplete.
 Example:

 writefln(typeid(int *), "  ", typeid(int function(char *, creal)));

 prints:
 int *    int()*

 yet from std.demangle, it looks as though even inout vs out parameters
 are distinguished in the mangled name.

 Musing...

 Now, a simple-to-implement way of doing this, and ensuring that all
 presnt and future types are covered, would be to include a
 __mangletypeof() function or property, valid for any type, which
 converts a type to a const char[], using exactly the same mangling
 algorithm which is used by the linker for individual types.
 So that std.demangle(__mangletypeof(int)) would return "int".


That's a good idea. The mangletypeof, however, should probably be a method
of TypeInfo. The nice thing about making this a standard method is that code
will be inured against mangling changes. Or do you mean it should be a
compile-time function?


 Note: if there was some kind of __demangletypeof() as well, we would
 have well-supported typelists by the backdoor -- mangle the types,
 perform string manipulations on them, and demangle when you're done. But
 perhaps this is all far, far too much rope...





 Could also be done from a library, if we had implicit function template
 instantiation. But I'm guessing that's not coming any time soon.


It would if I'd only stop doing other stuff <g>.
Dec 01 2005
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:

 "Don Clugston" <dac nospam.com.au> wrote in message

Now, a simple-to-implement way of doing this, and ensuring that all
presnt and future types are covered, would be to include a
__mangletypeof() function or property, valid for any type, which
converts a type to a const char[], using exactly the same mangling
algorithm which is used by the linker for individual types.
So that std.demangle(__mangletypeof(int)) would return "int".


 
 
 That's a good idea. The mangletypeof, however, should probably be a method
 of TypeInfo. The nice thing about making this a standard method is that code
 will be inured against mangling changes. Or do you mean it should be a
 compile-time function?


The idealist in me says: A compile-time function, analagous to typeof(), 
would be a whole lot more fun :) And I don't think it would often be 
required at runtime. There is the "enough rope" issue, though. It is a 
feature that is a bit too nasty to be easily accessable.

It would be ideal if const char [] typeof(T).mangletypeof (and 
typeof(T).name) were accessable at compile-time, but I don't see how 
that could work, unless parts of typeinfo became a template. Gets tricky.

The pragmatist in me says: A runtime function would probably be adequate 
for almost all applications, and implicit function templates could be 
used for the remainder, when they become available.


Could also be done from a library, if we had implicit function template
instantiation. But I'm guessing that's not coming any time soon.


 
 It would if I'd only stop doing other stuff <g>.


Aha! Sounds like it's not a post-1.0 feature, then? (whatever 1.0 means 
:-) ). But it's all good.
Dec 01 2005
parent reply "Kris" <fu bar.com> writes:
This is great stuff.

If there were an "official" way to try out features, knowing fully that they 
are liable to change over time, I think it might help in such cases.

For example, if such things were symbolically marked in a manner akin to 
"deprecated", then the compiler would toss out an appropriate message: 
"using speculative feature x". Can't help but wonder if that might "permit" 
some more experimental aspects?

- Kris


"Don Clugston" <dac nospam.com.au> wrote in message 
news:dmmn7h$2rhm$1 digitaldaemon.com...

 Walter Bright wrote:

 "Don Clugston" <dac nospam.com.au> wrote in message

Now, a simple-to-implement way of doing this, and ensuring that all
presnt and future types are covered, would be to include a
__mangletypeof() function or property, valid for any type, which
converts a type to a const char[], using exactly the same mangling
algorithm which is used by the linker for individual types.
So that std.demangle(__mangletypeof(int)) would return "int".



 That's a good idea. The mangletypeof, however, should probably be a 
 method
 of TypeInfo. The nice thing about making this a standard method is that 
 code
 will be inured against mangling changes. Or do you mean it should be a
 compile-time function?


 The idealist in me says: A compile-time function, analagous to typeof(), 
 would be a whole lot more fun :) And I don't think it would often be 
 required at runtime. There is the "enough rope" issue, though. It is a 
 feature that is a bit too nasty to be easily accessable.

 It would be ideal if const char [] typeof(T).mangletypeof (and 
 typeof(T).name) were accessable at compile-time, but I don't see how that 
 could work, unless parts of typeinfo became a template. Gets tricky.

 The pragmatist in me says: A runtime function would probably be adequate 
 for almost all applications, and implicit function templates could be used 
 for the remainder, when they become available.


Could also be done from a library, if we had implicit function template
instantiation. But I'm guessing that's not coming any time soon.


 It would if I'd only stop doing other stuff <g>.


 Aha! Sounds like it's not a post-1.0 feature, then? (whatever 1.0 means 
 :-) ). But it's all good.
Dec 01 2005
parent Sean Kelly <sean f4.ca> writes:
Kris wrote:

 This is great stuff.
 
 If there were an "official" way to try out features, knowing fully that they 
 are liable to change over time, I think it might help in such cases.
 
 For example, if such things were symbolically marked in a manner akin to 
 "deprecated", then the compiler would toss out an appropriate message: 
 "using speculative feature x". Can't help but wonder if that might "permit" 
 some more experimental aspects?


Something like that could be useful.  It would even prevent the need for 
new namespaces for library updates to differentiate between standard and 
proposed features (I'm thinking of std::tr1 in C++ here).


Sean
Dec 01 2005
prev sibling parent John Reimer <terminal.node gmail.com> writes:
Walter Bright wrote:


Musing...

Now, a simple-to-implement way of doing this, and ensuring that all
presnt and future types are covered, would be to include a
__mangletypeof() function or property, valid for any type, which
converts a type to a const char[], using exactly the same mangling
algorithm which is used by the linker for individual types.
So that std.demangle(__mangletypeof(int)) would return "int".


 
 
 That's a good idea. The mangletypeof, however, should probably be a method
 of TypeInfo. The nice thing about making this a standard method is that code
 will be inured against mangling changes. Or do you mean it should be a
 compile-time function?
 


Definitely compile-time... at least for the purposes I'm thinking of.
Dec 01 2005
prev sibling next sibling parent reply BCS <BCS_member pathlink.com> writes:
In article <dmmhfc$2m8p$1 digitaldaemon.com>, Don Clugston says...


..


All the mangling information is present in a mangled string, but I don't 
know any way to find out what the function arguments are.
Suppose T is a function pointer type.

R function (P1, P2, P3)

What are R, P1, P2, P3 ? You can work out what R is, using
is(T R : function)
which gives you the type of the return value.
In C++, you can find out what P1, P2, P3 are, by using implicit template 
instantiation. But in D, I don't even know how I can work out how many 
parameters there are. (Maybe there is, and I've just missed it).



Another similar problem comes up with function pointers to overloaded functions,
e.g. you can't tell witch function is being used without knowing the type. 

DMD currently just picks one of the function. (For an example see
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/5671 )



 Dec 01 2005



  parent  Kramer <Kramer_member pathlink.com>  writes:


In article <dmn9vf$i7r$1 digitaldaemon.com>, BCS says...

In article <dmmhfc$2m8p$1 digitaldaemon.com>, Don Clugston says...


..


All the mangling information is present in a mangled string, but I don't 
know any way to find out what the function arguments are.
Suppose T is a function pointer type.

R function (P1, P2, P3)

What are R, P1, P2, P3 ? You can work out what R is, using
is(T R : function)
which gives you the type of the return value.
In C++, you can find out what P1, P2, P3 are, by using implicit template 
instantiation. But in D, I don't even know how I can work out how many 
parameters there are. (Maybe there is, and I've just missed it).



Another similar problem comes up with function pointers to overloaded functions,
e.g. you can't tell witch function is being used without knowing the type. 

DMD currently just picks one of the function. (For an example see
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/5671 )


Does anyone know of plans for including reflection in the language?  It seems
like there's a lot of pieces and groudwork for it already, but maybe having a
standard library that uses these pieces would be beneficial for D and would
round out that feature in a consistent api; or maybe those other pieces just
need to be filled out more.

-Kramer



 Dec 01 2005



prev sibling  parent reply John Reimer <terminal.node gmail.com>  writes:


Don Clugston wrote:
<snip>


 Musing...
 
 Now, a simple-to-implement way of doing this, and ensuring that all 
 presnt and future types are covered, would be to include a 
 __mangletypeof() function or property, valid for any type, which 
 converts a type to a const char[], using exactly the same mangling 
 algorithm which is used by the linker for individual types.
 So that std.demangle(__mangletypeof(int)) would return "int".
 
 Note: if there was some kind of __demangletypeof() as well, we would 
 have well-supported typelists by the backdoor -- mangle the types, 
 perform string manipulations on them, and demangle when you're done. But 
 perhaps this is all far, far too much rope...
 
 Could also be done from a library, if we had implicit function template 
 instantiation. But I'm guessing that's not coming any time soon.
 


This would be just beautiful and, I think, would be a solution to the 
problem I gave in the d.learn group (see Symbol to char[]).  This idea 
is better because it is much more generalized.

-JJR



 Dec 01 2005



  parent reply Don Clugston <dac nospam.com.au>  writes:


John Reimer wrote:

 Don Clugston wrote:
 <snip>
 

 Musing...

 Now, a simple-to-implement way of doing this, and ensuring that all 
 presnt and future types are covered, would be to include a 
 __mangletypeof() function or property, valid for any type, which 
 converts a type to a const char[], using exactly the same mangling 
 algorithm which is used by the linker for individual types.
 So that std.demangle(__mangletypeof(int)) would return "int".

 Note: if there was some kind of __demangletypeof() as well, we would 
 have well-supported typelists by the backdoor -- mangle the types, 
 perform string manipulations on them, and demangle when you're done. 
 But perhaps this is all far, far too much rope...


 
 This would be just beautiful and, I think, would be a solution to the 
 problem I gave in the d.learn group (see Symbol to char[]).  This idea 
 is better because it is much more generalized.
 
 -JJR


Having thought about it a little more, I think that this would provide 
almost all of the compile-time type info you could want. Since we can 
now do string parsing at compile time, I think everything else could be 
extracted from the mangled string via a compile-time library.
A nice feature of using the name mangling is that it's a simple, fully 
general way of unifying type information.
By presenting members (of modules, templates, classes and structs, maybe 
even functions) as an array of constant char [] identifiers and char [] 
mangled typenames, you could have *full* compile-time reflection.

I suspect this would be by far the easiest way of implementing it, too.
Although walking the syntax tree before compilation is complete sounds 
perilous. Could it ever be done safely? (I wonder if any other languages 
have done it successfully?)



 Dec 02 2005



 next sibling parent  pragma <pragma_member pathlink.com>  writes:


In article <dmovhp$ecm$1 digitaldaemon.com>, Don Clugston says...

John Reimer wrote:

 Don Clugston wrote:
 <snip>
 

 Musing...

 Now, a simple-to-implement way of doing this, and ensuring that all 
 presnt and future types are covered, would be to include a 
 __mangletypeof() function or property, valid for any type, which 
 converts a type to a const char[], using exactly the same mangling 
 algorithm which is used by the linker for individual types.
 So that std.demangle(__mangletypeof(int)) would return "int".

 Note: if there was some kind of __demangletypeof() as well, we would 
 have well-supported typelists by the backdoor -- mangle the types, 
 perform string manipulations on them, and demangle when you're done. 
 But perhaps this is all far, far too much rope...


 
 This would be just beautiful and, I think, would be a solution to the 
 problem I gave in the d.learn group (see Symbol to char[]).  This idea 
 is better because it is much more generalized.
 
 -JJR


Having thought about it a little more, I think that this would provide 
almost all of the compile-time type info you could want. Since we can 
now do string parsing at compile time, I think everything else could be 
extracted from the mangled string via a compile-time library.
A nice feature of using the name mangling is that it's a simple, fully 
general way of unifying type information.
By presenting members (of modules, templates, classes and structs, maybe 
even functions) as an array of constant char [] identifiers and char [] 
mangled typenames, you could have *full* compile-time reflection.

I suspect this would be by far the easiest way of implementing it, too.
Although walking the syntax tree before compilation is complete sounds 
perilous. Could it ever be done safely? (I wonder if any other languages 
have done it successfully?)


Well, you know me, if it gets us closer to a good reflection system, it gets my
vote.  One question though: how will this help with type discovery at runtime...
or will it?

- EricAnderton at yahoo



 Dec 02 2005



prev sibling  parent  Bruno Medeiros <daiphoenixNO SPAMlycos.com>  writes:


Don Clugston wrote:

 By presenting members (of modules, templates, classes and structs, maybe 
 even functions) as an array of constant char [] identifiers and char [] 
 mangled typenames, you could have *full* compile-time reflection.
 


Compile-time reflection was something I was thinking about too, as it 
would be very useful. For instance one could make a generic Serialize 
mixin template that would save any class/struct to a certain media (like 
a file, or stream).
However, from what I understand from your example above, that method 
would only give "read-only" reflection as you would only have available 
the member's names/signature, and, at least for fields (and virtual 
functions too, I think?), that would not be enough to access it (you 
would need offset info, right?).


 I suspect this would be by far the easiest way of implementing it, too.
 Although walking the syntax tree before compilation is complete sounds 
 perilous. Could it ever be done safely? (I wonder if any other languages 
 have done it successfully?)


Sounds perilous? Why? And I wouldn't call it "walking the syntax-tree", 
it's not that permissive.


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



 Dec 03 2005