It's quite feasible that this could be entirely performed at compile time (b eneficial for code size, not execution time) Vendor-specific name mangling could even be done, if the name mangling policy was specified as a template parameter in the testModule declaration.

Potentially even more interesting, if you define

uint function(uint a, uint b) addfunc;

as a static member (which is probably what you want anyway), then
I believe it is currently feasible to write

testModule.getExport!(addfunc)("add");

(I just discovered that a static variable can be a alias template parameter).

If we could persuade Walter to add a compiler intrinsic function __nameof() or __stringize() or similar, which converted an indentifer name to a const char [],
it could even become

uint function (uint a, uint b) add;
:
testModule.getExport!(add);

which is looking rather clean.

Is any of this of interest to you? If so, I might start playing with name mangling as a practical application of my recent metaprogramming experiments.

Is any of this of interest to you? If so, I might start playing with name mangling as a practical application of my recent metaprogramming experiments.

I couldn't agree more that the current mode is deficient: I would love a metaprogramming or reflection facility (an intrinsic func like you mentioned) to handle name-mangling at compile time.

So I say: go forth and hack something together, and I thank you for lending a hand!

Right now the project doesn't have name-mangling support so anything would be an improvement. The existing demangler in this project should provide enough of a rosetta stone for you to devise a mangling process.

Just keep in mind that one thing that may prove difficult is incorporating the complete module namespace into the mangled symbol. DDL may be able to deduce this in the future, but for now, the current mode is explicit matching of symbols only.

At worst, we're back to composing a run-time parser to generate mangled symbols from raw text, which has been on my drawing board for some time now. Please, don't be offended if such a thing crops up anyway: having this capability at runtime may prove useful as well._________________-- !Eric.t.Anderton at gmail

OK, heres what I have so far. I wanted to avoid the triple specification of variable declaration, cast, and mangled name.
Unfortunately it seems that auto doesn't work with function pointers; would like to able to write

auto addFunc = loadFunc!(uint, "add", uint, uint);

so I wasn't completely successful. It only works with basic types and pointers; but that should be enough to play with.

(Yes, the names are stupid, it started off as just name mangling code, then I made a half-hearted attempt to eliminate the cast as well).
It might at least give you an idea of how user code might look.
-Enjoy!

Don, your skills with tempalates are amazing. I never would have thought this to be possible.

That bit with the mangleGroup!() is interesting: is that a workaround for a lack of a way to parse strings a compile-time? Seems to me that if you had template code that could split a string along the '.' characters in the identifier, that you could use namespaces of arbitrary complexity.

Once I get back to coding on DDL, your code will be in the repository. In the meantime, I'll add you to the list of contributors on the Wiki._________________-- !Eric.t.Anderton at gmail

It wasn't, until a few days ago. DMD 0.140 was an [i]awesome[/i] release. Totally leaves C++ templates for dead. What's amazing to me, is just how simple the code looks - no hacks!

[quote]
That bit with the mangleGroup!() is interesting: is that a workaround for a lack of a way to parse strings a compile-time? Seems to me that if you had template code that could split a string along the '.' characters in the identifier, that you could use namespaces of arbitrary complexity. [/quote]

No, it's pure laziness on my part. Plus I was exploring templates a bit more. In DMD 0.139, we got str[n] evaluated at compile time, so a string split function is eminently feasible. I just haven't done it yet. I didn't even get time to rename mangleGroup() into something more sensible. It could be removed entirely, so that if auto was fixed up, we could have:

writefln("add: 42+69 = ?d",addFunc(42,69));
helloWorld();
[/code]
Then if the loaded modules are stored in a global singleton, which has an AA mapping namespaces to the loaded files, the ultimate user code could be something like:

In DMD 0.139, we got str[n] evaluated at compile time, so a string split function is eminently feasible. I just haven't done it yet. I didn't even get time to rename mangleGroup() into something more sensible. It could be removed entirely[...]

Then if the loaded modules are stored in a global singleton, which has an AA mapping namespaces to the loaded files, the ultimate user code could be something like:

You've got the option "Disable BBCode in this post" checked, so your post is not being formated with the [code][/code] and [quote][/quote].

Nice work, though! Recently I was working on a problem similar to this and couldn't figure out a solution. Your examples above along with the 0.140 template improvements have fixed that for me. Thanks!

which is maybe not superior, but is interesting because (a) it requires much less duplication in the mangling code (you would not need overloads for each set of parameters), and (b) allows you to specify the calling convention seperately for each function (although this could be done easily enough).

Decisions, decisions...
Walter is giving us a *lot* of rope. Beautiful rope, too. Elvish, I think.
Anyway, these changes should just drop in, it just removes the caveats from the existing code.

which is maybe not superior, but is interesting because (a) it requires much less duplication in the mangling code (you would not need overloads for each set of parameters), and (b) allows you to specify the calling convention seperately for each function (although this could be done easily enough).

I like the new form that you propose as it would appear to eliminate the need for separate methods for fields and functions: is this still the case? At the very least, I can do away with the zillion or so template overloads to accomodate up to n function parameters.

Anyway its way more clear as it now reads "Get me a symbol of this type with this name". Great stuff.

Now if only mangleof() accepted a name as a parameter, we'd be set. In the meantime, I have you to thank Don. _________________-- !Eric.t.Anderton at gmail