On Wednesday, 9 August 2017 at 02:11:13 UTC, Johnson Jones wrote:
I like to create code that automates much of the manual labor
that we, as programmers, are generally forced to do. D
generally makes much of this work automatable. For example, I
have created the following code which makes loading dlls
similar to libs:
[...]
Yes, this is essentially what people are doing right now, see
e.g. [1] where all of the dynamic loading components are
generated from the declarations used for linking.
But this got me thinking that we don't even need to have to
specify the function in D, hell, they already exist in the lib
and we are just duplicating work.
What if, at compile time, D could get all the functions and
their type information and build a class for them for us? We
could then just write something like
struct DLLImports
{
@("DLLImport") string libgdk = "libgdk-3-0.dll";
}
and have some ctfe meta functions extract all the function from
libgdk and insert them in to the struct.
There are two problems with this, one easy and one
hard/impossible(which would be easy if people were intelligent
enough to have foresight):
There's a third one: This is not what object code is for, you'd
have to write code for every object code format, because they're
inherently platform specific.
1. Get the dll function by name from the dll at compile time.
This would probably require manually reading the dll file and
scanning for the function.
And you'd have to demangle all the symbol names for anything
that's not C mangled. Such as D. Or C++.
2. Get the type information to build a declaration. This is
probably impossible since dll's do not contain the type
information about their parameters and return type(or do
they?). If they did, it would be easy. I would suggest that all
dll's generated by D include this information somewhere and an
easy way to extract it for future programmers so such things
could be implemented.
Again, this is not what object code is for:
If you want to bind to anything that was written in D, you're
going to have the declarations, anyway (either in .d or .di
files), so you wouldn't need the information in the object code.
If it's not written in D, it's not going to be in the object
code, anyway.
Alternatively, maybe a master database could be queried for
such information by using the function names and dll name? I
don't know if D has network capabilities at compile time though.
D doesn't have arbitrary I/O at compile time.
[1]
https://github.com/Calrama/llvm-d/blob/master/source/llvm/functions/load.d#L124
