Hi all!

I've been lurking this forum for a little while -- and I'm really interested in D. I love C/C++, but I want something a little more modern -- but I don't want to do the whole 'VM' C# and Java -- and I really don't like how they force OO for everything...

Anyway, the thing that usually gets me with new languages etc. is linking in all the extra tools I want to use (DLL's, .a's, .lib's etc.)

Can there be something as simple as 'importlib (<type>) "<filename>"' in the
code? Say:

importlib (dll) "alleg40.dll";
importlib (a) "libusb.a";

I know the "extern (C) <function>" already exists.. but you have to do this for every function in the library... I wish I could just have an 'importlib' that would grab all the function names and parameters (and a nice IDE could pick it up for code completion) :)

Maybe this is a pipe dream, or maybe it already is implemented and I haven't found it yet... but I loved how in VB you could just 'check a box' and magically you could use the library in your code, and it would link on compile. (Maybe this would be a job of a nice IDE?)

Anyway, I'm watching the D project very closely! Keep up the good work!

- Jeremy

"Jeremy" <Jeremy_member@pathlink.com> wrote in message news:du03ir$2u1d$1@digitaldaemon.com...
> Can there be something as simple as 'importlib (<type>) "<filename>"' in
> the
> code? Say:
>
> importlib (dll) "alleg40.dll";
> importlib (a) "libusb.a";

Well, it's not _quite_ what you want, but it's better than nothing:

pragma(lib, "libusb.a");

This will tell the linker to link in the library, but you'll still have to define all the function signatures yourself.

And with DLLs, you can use implib to generate a .def file which can be passed on the command line to tell the linker where to find the functions, but again, you have to define all the function signatures.

Some people have been working on "auto-loading" symbols from static / dynamic libraries, but it's not part of the language yet.  I think a D object / library standard that had auto-loading of symbols would be great.

In article <du03ss$2ugm$1@digitaldaemon.com>, Jarrett Billingsley says...
>
>"Jeremy" <Jeremy_member@pathlink.com> wrote in message news:du03ir$2u1d$1@digitaldaemon.com...
>> Can there be something as simple as 'importlib (<type>) "<filename>"' in
>> the
>> code? Say:
>>
>> importlib (dll) "alleg40.dll";
>> importlib (a) "libusb.a";
>
>Well, it's not _quite_ what you want, but it's better than nothing:
>
>pragma(lib, "libusb.a");
>
>This will tell the linker to link in the library, but you'll still have to define all the function signatures yourself.
>
>And with DLLs, you can use implib to generate a .def file which can be passed on the command line to tell the linker where to find the functions, but again, you have to define all the function signatures.
>
>Some people have been working on "auto-loading" symbols from static / dynamic libraries, but it's not part of the language yet.  I think a D object / library standard that had auto-loading of symbols would be great.
>
>

I really hope "auto-loading" gets into the standard. It seems like there is alot of "fluff" when including/importing libraries... there are many steps/programs to do essentially one thing -- reference external (pre-compiled) code. We have 'implib', 'linkdef', 'pragma', 'extern' (for *every* function you want to use),'import'... and you still have to add the library filenames to the command line during compilation (unless you use pragma as Jarrett pointed out...).

Merge all that functionality into one keyword -- for example, you shouldn't have to tell the compiler anything more than 'I want to use this external source'. One line would tell the compiler you want to link/import a file, and that all symbols are to be loaded from that library that are referenced in the program. You might want to deprecate the current 'import', 'extern' and 'pragma' (pragma probably has other uses?) for an all-in-one 'reference' keyword that would work something like:

reference "alleg40.dll"
reference "gameclasses.d"
reference "libusb.a"
reference "phobos.lib"

The library type could be extracted by the file extension. That just looks awesome :) You have to agree... :) It must be possible -- and I think that would put D far ahead of the competition... imagine getting a new library -- want to install it? Copy hotstuff.xxx to the directory and say 'reference "hotstuff.xxx"' in your Game.d and that's it. Want to compile it? Just say 'dmd Game.d', that's it (assuming the libraries are in the same directory... -I otherwise etc etc.) -- If it isn't a recognizable library, throw a compiler error...

Jeremy

"Jeremy" <Jeremy_member@pathlink.com> wrote in message news:du0gvn$98o$1@digitaldaemon.com...
> Merge all that functionality into one keyword -- for example, you
> shouldn't have
> to tell the compiler anything more than 'I want to use this external
> source'.
> One line would tell the compiler you want to link/import a file, and that
> all
> symbols are to be loaded from that library that are referenced in the
> program.
> You might want to deprecate the current 'import', 'extern' and 'pragma'
> (pragma
> probably has other uses?) for an all-in-one 'reference' keyword that would
> work
> something like:
>
> reference "alleg40.dll"
> reference "gameclasses.d"
> reference "libusb.a"
> reference "phobos.lib"
>
> The library type could be extracted by the file extension. That just looks awesome :) You have to agree... :)

That would be great.  Although, why not just keep import?

import std.string;
import "alleg40.dll";

And yes, pragma does have other uses (it's a general-purpose compiler directive statement).

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:du0hji$a2a$1@digitaldaemon.com...
> import "alleg40.dll";

There is a problem with this.

Unless the library (static or dynamic) uses some kind of known name mangling, D won't be able to deduce the function signatures.

For example, I know a lot of C-compatible libraries use C name mangling, which is just

name@8

Or something, where 8 is the number of bytes passed into the function.  No indication of return type, param types, etc.

It could only really be done with D libraries, and by then, you might as well create your own D library format.  Which would still be cool.

In article <du0hnt$a5d$1@digitaldaemon.com>, Jarrett Billingsley says...
>
>"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:du0hji$a2a$1@digitaldaemon.com...
>> import "alleg40.dll";
>
>There is a problem with this.

I was worried somebody would say that :~(

>
>Unless the library (static or dynamic) uses some kind of known name mangling, D won't be able to deduce the function signatures.
>
>For example, I know a lot of C-compatible libraries use C name mangling, which is just
>
>name@8
>
>Or something, where 8 is the number of bytes passed into the function.  No indication of return type, param types, etc.

Hrm.. so how are those libraries referenced? I assume these are the cases where the library comes with a .h file that has the correct symbol names?

Hrm.. maybe that 'reference' keyword would work something like:

reference <library file> [, symbol defintion file]

if the second argument is missing ('symbol definition file') -- the compiler will try to automatically extract symbol information and compile -- complaining if there are undefined references (maybe the compiler can pick up symbol names by these undefined references like "linkdef" does?)

if the second argument exists, then it will use that to grab more information about the library (like a .h file would for C libraries -- isn't this what current .def's do?)

I would like to help program this functionality if it would become part of the standard :) I don't know where to begin, but I'm pretty good with C/C++ :-D

>
>It could only really be done with D libraries, and by then, you might as well create your own D library format.  Which would still be cool.
>

Yes yes :)

Jeremy

Jeremy wrote:
> I would like to help program this functionality if it would become part of the standard :) I don't know where to begin, but I'm pretty good with C/C++ :-D
> 
> 
>>It could only really be done with D libraries, and by then, you might as well create your own D library format.  Which would still be cool.
>>
> 
> 
> Yes yes :)
> 
> Jeremy

Have you seen http://trac.dsource.org/projects/ddl ??

BA

In article <du0lff$dh0$1@digitaldaemon.com>, Brad Anderson says...
>
>Jeremy wrote:
>> I would like to help program this functionality if it would become part of the standard :) I don't know where to begin, but I'm pretty good with C/C++ :-D
>> 
>> 
>>>It could only really be done with D libraries, and by then, you might as well create your own D library format.  Which would still be cool.
>>>
>> 
>> 
>> Yes yes :)
>> 
>> Jeremy
>
>Have you seen http://trac.dsource.org/projects/ddl ??
>
>BA

Interesting... is this the answer to all my questions? :-D Many of the pages explaining more about DDL are not complete :( But if I assume correctly... this tool will take in almost any library .DLL, .o, .a, .lib and make a .DDL out of it? I'll have to look more into this when its not 12:30am :) Why isn't slick stuff like this packaged with the compiler?

Jeremy

Jeremy wrote:
> In article <du0lff$dh0$1@digitaldaemon.com>, Brad Anderson says...
>> Jeremy wrote:
>>> I would like to help program this functionality if it would become part of the
>>> standard :) I don't know where to begin, but I'm pretty good with C/C++ :-D
>>>
>>>
>>>> It could only really be done with D libraries, and by then, you might as well create your own D library format.  Which would still be cool. 
>>>>
>>>
>>> Yes yes :)
>>>
>>> Jeremy
>> Have you seen http://trac.dsource.org/projects/ddl ??
>>
>> BA
> 
> Interesting... is this the answer to all my questions? :-D Many of the pages
> explaining more about DDL are not complete :( But if I assume correctly... this
> tool will take in almost any library .DLL, .o, .a, .lib and make a .DDL out of
> it? I'll have to look more into this when its not 12:30am :) Why isn't slick
> stuff like this packaged with the compiler?
> 
> Jeremy

DDL is a *relatively* new project, so it is still in beta, plus I'm sure Walter has not had time to grok what Eric is doing with it.

"Jeremy" <Jeremy_member@pathlink.com> wrote in message news:du0gvn$98o$1@digitaldaemon.com...
> reference "alleg40.dll"
> reference "gameclasses.d"
> reference "libusb.a"
> reference "phobos.lib"
>
> The library type could be extracted by the file extension. That just looks
> awesome :) You have to agree... :) It must be possible -- and I think that
> would
> put D far ahead of the competition... imagine getting a new library --
> want to
> install it? Copy hotstuff.xxx to the directory and say 'reference
> "hotstuff.xxx"' in your Game.d and that's it. Want to compile it? Just say
> 'dmd
> Game.d', that's it (assuming the libraries are in the same directory... -I
> otherwise etc etc.) -- If it isn't a recognizable library, throw a
> compiler
> error...

The problem with referencing dll's is that you could only reference functions that accepted and returned basic types. No classes, no enums, no structs, no typedefs.