Understanding import...

so I have this module:

// my module DAE.d
module DAE;
class Class0
{
..
}
class Class1
{
..
}
class Class2
{
..
}
class Class3
{
..
}
class Class4
{
..
}
class Class5
{
..
}

and this program

// test.d
private import DAE;

int main(char[][] args)
{
Class1 ini = new Class1();
ini.blah = 1;
writefln(ini.blah);
return(1);
}

When test.d is compiled, though I only used the Class1 instance and not any others, will the executable be bloaded by the extra ClassX, or would compiler know not to include the rest of the ClassX instances?  What I am trying to figure out is if I should declare some of these classes in the main programs which use these other classes instead of the libraries.

Any ideas?

thanks.

josé

On Thu, 2 Mar 2006 20:41:39 +0000 (UTC), jicman wrote:

> Understanding import...
> 
> so I have this module:
> 
> // my module DAE.d
> module DAE;
> class Class0
> {
> ..
> }
> class Class1
> {
> ..
> }
> class Class2
> {
> ..
> }
> class Class3
> {
> ..
> }
> class Class4
> {
> ..
> }
> class Class5
> {
> ..
> }
> 
> and this program
> 
> // test.d
> private import DAE;
> 
> int main(char[][] args)
> {
> Class1 ini = new Class1();
> ini.blah = 1;
> writefln(ini.blah);
> return(1);
> }
> 
> When test.d is compiled, though I only used the Class1 instance and not any others, will the executable be bloaded by the extra ClassX, or would compiler know not to include the rest of the ClassX instances?  What I am trying to figure out is if I should declare some of these classes in the main programs which use these other classes instead of the libraries.
> 
> Any ideas?

I believe that the linker inserts *all* the generated code for a module when you reference *any* element in that module. And so, if you want fine-grained linker inclusions, then use the minimum number of classes per module that will still keep your application working.

Personally, I prefer one class per module except where an application will always require all the classes in a module.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
3/03/2006 11:37:07 AM

Gracias, Derek. (That's thanks in Spanish. ;-))

Derek Parnell says...
>
>On Thu, 2 Mar 2006 20:41:39 +0000 (UTC), jicman wrote:
>
>> Understanding import...
>> 
>> so I have this module:
>> 
>> // my module DAE.d
>> module DAE;
>> class Class0
>> {
>> ..
>> }
>> class Class1
>> {
>> ..
>> }
>> class Class2
>> {
>> ..
>> }
>> class Class3
>> {
>> ..
>> }
>> class Class4
>> {
>> ..
>> }
>> class Class5
>> {
>> ..
>> }
>> 
>> and this program
>> 
>> // test.d
>> private import DAE;
>> 
>> int main(char[][] args)
>> {
>> Class1 ini = new Class1();
>> ini.blah = 1;
>> writefln(ini.blah);
>> return(1);
>> }
>> 
>> When test.d is compiled, though I only used the Class1 instance and not any others, will the executable be bloaded by the extra ClassX, or would compiler know not to include the rest of the ClassX instances?  What I am trying to figure out is if I should declare some of these classes in the main programs which use these other classes instead of the libraries.
>> 
>> Any ideas?
>
>I believe that the linker inserts *all* the generated code for a module when you reference *any* element in that module. And so, if you want fine-grained linker inclusions, then use the minimum number of classes per module that will still keep your application working.
>
>Personally, I prefer one class per module except where an application will always require all the classes in a module.
>
>-- 
>Derek
>(skype: derek.j.parnell)
>Melbourne, Australia
>"Down with mediocracy!"
>3/03/2006 11:37:07 AM