www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Understanding import

reply jicman <jicman_member pathlink.com> writes:
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é
Mar 02 2006
parent reply Derek Parnell <derek psych.ward> writes:
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
Mar 02 2006
parent jicman <jicman_member pathlink.com> writes:
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
Mar 03 2006