pragma wrote:
> John Reimer wrote:
> 
>>
>> Eric... this is great, but I'm wondering how this works for c-based libs.  How do you get the parameter details for the functions?  D based functions are easy since the parameter typs are mangled into the symbol name.  I'm just curious how this will work for C-base libraries.
> 
> 
> In short, it won't.
> 
> Walter was nice enough to give D's symbol mangling some smarts so that function overloading works correctly.  As for C functions, the best that can be done (for a header generator) is to emit a file that simply has them declared as something like this:
> 
>  > extern(C) void* foobar; //TODO: change me (this means you)
> 
> Which is a far cry from what we want, but is just about all you're going to get from the perspective of an .obj or .lib file.  When you get down to it, the DDL suite is really tailored for mostly pure D code and binary data, so it's not a perfect fit here.
> 
> For this case, I think the future will probably hold a special place for something that can parse .c and .h files to generate D symbol files. Its either that or we improve the current batch of .h to .d conversion utils.
> 

I found an article where they did it for C++. http://www.newlc.com/article.php3?id_article=530
The example was using nm from binutils but it requires COFF format and I couldn't manage to convert OMF to COFF. And if I did I am still not sure it would work. I don't know. Take a look. Maybe it will mean something more for you than me.

the difference is C++ has all the identifiers mangled to bake in the types and arguments, whereas in c all we get are function names. Ive got windows COFF code but unfortunately I dont see how this is really going to help for C modules. as eric said all you would produce is a list of function names.

bobef wrote:
> pragma wrote:
> 
>> John Reimer wrote:
>>
>>>
>>> Eric... this is great, but I'm wondering how this works for c-based libs.  How do you get the parameter details for the functions?  D based functions are easy since the parameter typs are mangled into the symbol name.  I'm just curious how this will work for C-base libraries.
>>
>>
>>
>> In short, it won't.
>>
>> Walter was nice enough to give D's symbol mangling some smarts so that function overloading works correctly.  As for C functions, the best that can be done (for a header generator) is to emit a file that simply has them declared as something like this:
>>
>>  > extern(C) void* foobar; //TODO: change me (this means you)
>>
>> Which is a far cry from what we want, but is just about all you're going to get from the perspective of an .obj or .lib file.  When you get down to it, the DDL suite is really tailored for mostly pure D code and binary data, so it's not a perfect fit here.
>>
>> For this case, I think the future will probably hold a special place for something that can parse .c and .h files to generate D symbol files. Its either that or we improve the current batch of .h to .d conversion utils.
>>
> 
> I found an article where they did it for C++. http://www.newlc.com/article.php3?id_article=530
> The example was using nm from binutils but it requires COFF format and I couldn't manage to convert OMF to COFF. And if I did I am still not sure it would work. I don't know. Take a look. Maybe it will mean something more for you than me.

On Sun, 11 Sep 2005 19:09:04 -0700, pragma <EricAnderton@youknowthedrill.yahoo> wrote:

>John Reimer wrote:
>> 
>> Eric... this is great, but I'm wondering how this works for c-based libs.  How do you get the parameter details for the functions?  D based functions are easy since the parameter typs are mangled into the symbol name.  I'm just curious how this will work for C-base libraries.
>
>In short, it won't.
>
>Walter was nice enough to give D's symbol mangling some smarts so that function overloading works correctly.  As for C functions, the best that can be done (for a header generator) is to emit a file that simply has them declared as something like this:
>
> > extern(C) void* foobar; //TODO: change me (this means you)
>
>Which is a far cry from what we want, but is just about all you're going to get from the perspective of an .obj or .lib file.  When you get down to it, the DDL suite is really tailored for mostly pure D code and binary data, so it's not a perfect fit here.
>
>For this case, I think the future will probably hold a special place for something that can parse .c and .h files to generate D symbol files. Its either that or we improve the current batch of .h to .d conversion utils.

Someone should add D support to SWIG.

This will allow us to make D wrappers of C and C++ libraries easily.

  http://www.swig.org/

The Java or C# implementations might provide decent reference.

I just posted an ideal, but related, solution a few minutes ago.

-- 
 kai