hi all,

I am new to do D, but have some experience with C/Java/Oberon systems.

if you want to use a lib from c, you have the header files and use the symbol information therein to link against that.
in java for instance, you have the class file which has the meta information built into the intermediate representation, so the linker information can deduce the linkage information right out of the .class fie.
in oberon you have symbol lists that are only needed for compiling, like binary header files.

how does d, which abandonds header files too, does linking, for instance, if you have a d shared object:

foo.d:

class World {

void hello( ) {
	printf( "hello from 'foo'\n" );
}
}

you compile that to a shared object file.

then you have
bar.d

import foo;

int main( char[][] args ) {
   World w = new World( );
   w.hello( );
}



how does the compilation model look like?
how do you embed the information into elf? (using dwarf2/3)?
do you require source distributions?

thaks
-- Jakob

Jakob Praher wrote:

> hi all,
> 
> I am new to do D, but have some experience with C/Java/Oberon systems.
> 
> if you want to use a lib from c, you have the header files and use the symbol information therein to link against that.
> in java for instance, you have the class file which has the meta information built into the intermediate representation, so the linker information can deduce the linkage information right out of the .class fie.
> in oberon you have symbol lists that are only needed for compiling, like binary header files.
> 
> how does d, which abandonds header files too, does linking, for instance, if you have a d shared object:
> 
> how does the compilation model look like?
> how do you embed the information into elf? (using dwarf2/3)?
> do you require source distributions?

Sort of.  D uses the actual source file to import.  The difference is that, when you import, D doesn't actually care about the definitions, just the declarations, so you can leave that all out.  The result looks like a header file:

For instance, you might distribute a foo.d that looks like this:

    class World {
        void hello();
    }

The compilation model used in current compilers is pretty much identical to the C model, though there is nothing in the spec that would prevent someone from coming up with a different one.

 -- andy

Andy Friesen wrote:
> For instance, you might distribute a foo.d that looks like this:
> 
>     class World {
>         void hello();
>     }

And I'd just like to add that you'd only expose public citizens of the module.. for instance the module:

------------------------------
module foo;

private import std.stream;

class World {
public:
  void hello() {
    stdout.writeString("Hello");
    _world();
  }
private:
  void _world() {
    stdout.writeString(" world.\n");
  }
}
------------------------------

Would be distributed looking like:

------------------------------
module foo;

class World {
  void hello();
}
------------------------------

-C. Sauls
-Invironz

Andy Friesen wrote:
> Jakob Praher wrote:
> 
>> hi all,
>>
>> I am new to do D, but have some experience with C/Java/Oberon systems.
>>
>> if you want to use a lib from c, you have the header files and use the symbol information therein to link against that.
>> in java for instance, you have the class file which has the meta information built into the intermediate representation, so the linker information can deduce the linkage information right out of the .class fie.
>> in oberon you have symbol lists that are only needed for compiling, like binary header files.
>>
>> how does d, which abandonds header files too, does linking, for instance, if you have a d shared object:
>>
>> how does the compilation model look like?
>> how do you embed the information into elf? (using dwarf2/3)?
>> do you require source distributions?
> 
> 
> Sort of.  D uses the actual source file to import.  The difference is that, when you import, D doesn't actually care about the definitions, just the declarations, so you can leave that all out.  The result looks like a header file:
> 
> For instance, you might distribute a foo.d that looks like this:
> 
>     class World {
>         void hello();
>     }
> 
> The compilation model used in current compilers is pretty much identical to the C model, though there is nothing in the spec that would prevent someone from coming up with a different one.

thanks for the info.

would be interesting to distribute the declarations in dwarf2/3 format. in a special section, or as a separate file. And if this binary information is not there, the compiler searches for d source files.

-- Jakob