View mode: basic / threaded / horizontal-split · Log in · Help
April 30, 2004
d symbol information (the things c gets from headers)
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
April 30, 2004
Re: d symbol information (the things c gets from headers)
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
April 30, 2004
Re: d symbol information (the things c gets from headers)
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
April 30, 2004
Re: d symbol information (the things c gets from headers)
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
Top | Discussion index | About this forum | D home