www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Some Basic Question

reply Jay Kyburz <jay jaykyburz.com> writes:
Hi All,

I'm a hobby programmer and have been playing around with D for a few weeks. I 
usually make little games and have recently started a gui project using DWT. 
Not much gets finished but I have fun solving the problems and making stuff 
happen. 

In the past I've used a bunch of different scripting languages, quite a bit 

neat package where I can simply hit the build button and get an exe. 

D is a little different in that you have to know a little more about what is 
going on when you try and build something. Well, perhaps you don't need to 
know it, but because it's exposed I find myself asking questions. 

Anyhow, I guess thats my question. Is there somewhere I can go and read about 
the fundamentals of the build process?

Examples: What do each of the exe's in bm/bin do? In what order are they run? 
Why have a dm and a dmd folder. When I import a module, how does the build 
process find my source files. What the hell does pragma import do, I've read 
the docs but don't understand how this is different to linking to libs .  
etc... 

If you guys don't know of anywhere this is already documented, do you think 
this list a good place to ask?  Perhaps I could add some of the answers I get 
to the wiki. 

Any help much appreciated.

Jay Kyburz
Aug 14 2006
parent reply Sean Kelly <sean f4.ca> writes:
Jay Kyburz wrote:

 Hi All,
 
 I'm a hobby programmer and have been playing around with D for a few weeks. I 
 usually make little games and have recently started a gui project using DWT. 
 Not much gets finished but I have fun solving the problems and making stuff 
 happen. 
 
 In the past I've used a bunch of different scripting languages, quite a bit 

 neat package where I can simply hit the build button and get an exe. 
 
 D is a little different in that you have to know a little more about what is 
 going on when you try and build something. Well, perhaps you don't need to 
 know it, but because it's exposed I find myself asking questions. 
 
 Anyhow, I guess thats my question. Is there somewhere I can go and read about 
 the fundamentals of the build process?


It may help to know that D is pretty much the same as C in that source 
files are compiled to an intermediate language (ie. object files) and 
then linked to produce an executable application.


 Examples: What do each of the exe's in bm/bin do? In what order are they run? 
 Why have a dm and a dmd folder.


The dm folder contains the Digital Mars C compiler and linker, which is 
used both for linking and also possibly for code generation.  I've got a 
bunch of stuff in dm/bin so I can't come up with a list of default EXEs 
offhand, but 'lib' generates static libraries, 'make' is a make tool, 
'link' is a linker, and I think 'sc' is an alias for 'dmc' which is the 
C compiler.


 When I import a module, how does the build
 process find my source files.


It looks in your include path, which is in dmd/bin/sc.ini as the -I 
portion of the DFLAGS variable.


 What the hell does pragma import do, I've read 
 the docs but don't understand how this is different to linking to libs .  
 etc... 


You shouldn't need to use any pragmas for typical D applications, so 
don't worry about them.  But they are documented here: 
http://www.digitalmars.com/d/pragma.html


 If you guys don't know of anywhere this is already documented, do you think 
 this list a good place to ask?  Perhaps I could add some of the answers I get 
 to the wiki.


This is the best place to ask questions not answered by the wiki.


Sean
Aug 14 2006
parent reply Frank Benoit <keinfarbton nospam.xyz> writes:
 When I import a module, how does the build
 process find my source files.


 
 It looks in your include path, which is in dmd/bin/sc.ini as the -I
 portion of the DFLAGS variable.
 


I always use the 'build' tool from http://www.dsource.org/projects/build
to compile and link an executable in one step. It searches for all files
and calls dmd with the right parameters.
Aug 15 2006
parent reply Jay Kyburz <jay jaykyburz.com> writes:
 I always use the 'build' tool from http://www.dsource.org/projects/build
 to compile and link an executable in one step. It searches for all files
 and calls dmd with the right parameters.


Thanks for those notes Sean and Frank, and yeah, I've been using build.exe 
too, and with no problems. Everything is working fine and happily coding away 
on my little project. 

I guessed a few things that I would like to know for sure though.

Heres another question. I have lots.

I have each of my classes in separate source files. the files are named the 
same as the class.  Is it true that each source files is compiled to a 
separate module? 
That a module needs to import any other module to access its classes?
These modules are the obj files right? 

Where is it getting the name of the modules from? My source files are 
capitalized but from the looks of things module names need to be lowercase. 
Or at least the first letter needs to be. eg. TaskArea class is save in 
TaskArea.d but I need to import taskArea to access the class.  By disabling 
clean I see that this is the name of the generated obj file. How come it 
changes case on me? Should I stick with this naming convention for my 
sources?
 

Also, how does the dot syntax work?

I've downloaded and using TinyXML. I've dropped the sources in a folder 
called TinyXML. To access this i need to import tinyxml.tinyxml not 
TinyXML.tinlyxml. So the dot syntax is used to find objs in subfolders? And 
it also requires lowercase?

But then what is with std.stdio? I don't see an std folder? Is this a special 
case?

When i import dwt.all for GUI, it seems to be compiling all of it it every 
time I build. Do I really need to recompile all of dwt every time i build? 


I'd better stop there. I starting to sound like I don't know anything. 

If you guys are kind enough to answer these questions I'll post some more 
about linking to libs. :)

I'll also google around and see if i can't find some good info about c's 
build process. 

Thanks guys!
Aug 15 2006
next sibling parent Frank Benoit <keinfarbton nospam.xyz> writes:
 I have each of my classes in separate source files. the files are named the 
 same as the class.  Is it true that each source files is compiled to a 
 separate module? 


Every source file is a module. Each module (=src file) is compile to a
object file.


 That a module needs to import any other module to access its classes?


Yes.


 These modules are the obj files right? 


No, its the source files.


 Where is it getting the name of the modules from? 


The path the source file is located in, has to match the
module-statement in the source file.

e.g.

module mypackage.mymod;
map to the file
mypackage/mymod.d


 My source files are
 capitalized but from the looks of things module names need to be lowercase.



The case is important, but you can name the modules/files like you want.


 Or at least the first letter needs to be. eg. TaskArea class is save in 
 TaskArea.d but I need to import taskArea to access the class.  By disabling 
 clean I see that this is the name of the generated obj file. How come it 
 changes case on me? Should I stick with this naming convention for my 
 sources?


You really do not need the mapping 1 module == 1 class.
You can put 3 classes into one module if you want. The module name and
the class name are independent. They can be equal, but doesn't have to.
They have different scopes.


 Also, how does the dot syntax work?


If you mymodule contains the class 'MyClass' then:
mypackage		=> qualifies the package
mypackage.mymodule	=> qualifies the module, needed to import
mypackage.mymodule.MyClass => is the full qualified name of the class
MyClass.

The dot syntax is only unique if a file mymodule.d is found in a
mypackage directory. If not it could also mean a module 'MyClass' in the
directory mypackage/mymodule or it can mean a inner class MyClass in the
class 'mymodule' in the module 'mypackage' :)


 I've downloaded and using TinyXML. I've dropped the sources in a folder 
 called TinyXML. To access this i need to import tinyxml.tinyxml not 
 TinyXML.tinlyxml. So the dot syntax is used to find objs in subfolders? And 
 it also requires lowercase?


If you work on windows, its possible the case sensitivity is affected
from the file system. I don't know. I work on linux.
You have to make sure, the module statements of the tinyxml modules
match the directory structure, and the root of this structure is one of
the compiler include paths (option -I). I don't know the TinyXML so I
cannot help further.


 But then what is with std.stdio? I don't see an std folder? Is this a special 
 case?


look into the dmd/source/phobos folder. This directory is also listed in
sc.ini, that is the cause, the compiler looks there.


 
 When i import dwt.all for GUI, it seems to be compiling all of it it every 
 time I build. Do I really need to recompile all of dwt every time i build? 


compiling is made in several steps. If you import a module, it is parsed
to extract all definitions. Only if you compile the whole semantic
parsing is done. Well, I think that is the way it works :)
Aug 15 2006
prev sibling next sibling parent reply Derek Parnell <derek psyc.ward> writes:
On Tue, 15 Aug 2006 21:10:47 +1000, Jay Kyburz wrote:


 I always use the 'build' tool from http://www.dsource.org/projects/build
 to compile and link an executable in one step. It searches for all files
 and calls dmd with the right parameters.


 
 Thanks for those notes Sean and Frank, and yeah, I've been using build.exe 
 too, and with no problems. Everything is working fine and happily coding away 
 on my little project. 


Glad its been useful for you.


 I guessed a few things that I would like to know for sure though.
 
 Heres another question. I have lots.
 
 I have each of my classes in separate source files. the files are named the 
 same as the class.  Is it true that each source files is compiled to a 
 separate module? 


Yes. A source file *is* a module. The resulting .obj file is the module in
'object' form and can be linked in with other modules to form the
executable.


 That a module needs to import any other module to access its classes?


Yes.


 These modules are the obj files right? 


See above.
 

 Where is it getting the name of the modules from? 


If your source file does *not* have a module statement in it, then the
module name is the same as the source file minus the '.d' suffix. Otherwise
the module name is what you've declared in the module statement.

In nearly every case, the best practice is to have a module statement that
is exactly the same as your source file name. It saves headaches later on. 


 My source files are 
 capitalized but from the looks of things module names need to be lowercase. 


They don't absolutely need to be lowercase, but the recommended standard is
to make module names (and thus file names) all lowercase.


 Or at least the first letter needs to be. eg. TaskArea class is save in 
 TaskArea.d but I need to import taskArea to access the class.  By disabling 
 clean I see that this is the name of the generated obj file. How come it 
 changes case on me? Should I stick with this naming convention for my 
 sources?


No, I suggest you use a different naming convention. I would have your
class name start with a Capital letter and have your source file name all
lowercase. And if you stick to one class per file, have your filename
different to the class by adding a suffix or prefix. For example,

  module foo_m;
  class Foo
  {
   ...
  }

You can have multiple classes in a single file. One would typically do that
if those classes needed direct access to each other's internals without
having to go through member functions. Everything in a module has access to
everything else in the same module (if in scope of course).


 
 Also, how does the dot syntax work?


If the module name is "foo.bar", it implies that the source file is to be
found in "foo\bar.d". Note that module names are *not* relative to the
current folder or the folder of the file importing the module. They are
relative to an entry in the 'Import List' of folder names. This list is
defined in dmd\bin\sc.ini and can be added to by the -I switch (dmd only).

My Build utility analyzes the source files to discover what the right
Import List should be and automatically adds them to the list before it
compiles the souirces.


 I've downloaded and using TinyXML. I've dropped the sources in a folder 
 called TinyXML. To access this i need to import tinyxml.tinyxml not 
 TinyXML.tinlyxml. So the dot syntax is used to find objs in subfolders? And 
 it also requires lowercase?


This is why one should stick to lowercase file names as they are portable
across systems.


 But then what is with std.stdio? I don't see an std folder? Is this a special 
 case?


No it is not special. "std.stdio" is a module found in "std\stdio.d". This
is relative to an entry in the Import List. The default Import List is
usually "c:\dmd\src\phobos" and can be found in sc.ini as 

 DFLAGS="-I% P%\..\src\phobos"

 

 When i import dwt.all for GUI, it seems to be compiling all of it it every 
 time I build. Do I really need to recompile all of dwt every time i build? 


Probably not, but its so fast it doesn't hurt.  Also, there are some
remaining limitations with templates and -release mode that is often fixed
by doing a full compile.


-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
Aug 15 2006
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Derek Parnell wrote:


 No, I suggest you use a different naming convention. I would have your
 class name start with a Capital letter and have your source file name all
 lowercase. And if you stick to one class per file, have your filename
 different to the class by adding a suffix or prefix. For example,
 
   module foo_m;
   class Foo
   {
    ...
   }


Can I ask you, what is your reason for naming a source file differently 
than the class? Does it have something to do with importing magic?
Aug 15 2006
next sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Lutger wrote:

 Derek Parnell wrote:
 

 No, I suggest you use a different naming convention. I would have your
 class name start with a Capital letter and have your source file name all
 lowercase. And if you stick to one class per file, have your filename
 different to the class by adding a suffix or prefix. For example,

   module foo_m;
   class Foo
   {
    ...
   }


 
 
 Can I ask you, what is your reason for naming a source file differently 
 than the class? Does it have something to do with importing magic?


The name of the source file and the name of the class are completely 
orthogonal. They have nothing to do with each other. They may be the 
same or different as you wish. This is not Java: A source file can 
contain zero classes or as many classes as you like.

That said, it is convention to name source files and modules completely 
lower-case, and to start class names with a capital. However, the 
language does not actually enforce either of these. If nothing else, it 
is a /very bad/ idea to ever name the source file and the module 
different things, even if they just differ in capitalization.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org
Aug 15 2006
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Kirk McDonald wrote:

 Lutger wrote:

 Derek Parnell wrote:


 No, I suggest you use a different naming convention. I would have your
 class name start with a Capital letter and have your source file name 
 all
 lowercase. And if you stick to one class per file, have your filename
 different to the class by adding a suffix or prefix. For example,

   module foo_m;
   class Foo
   {
    ...
   }



 Can I ask you, what is your reason for naming a source file 
 differently than the class? Does it have something to do with 
 importing magic?


 
 The name of the source file and the name of the class are completely 
 orthogonal. They have nothing to do with each other. They may be the 
 same or different as you wish. This is not Java: A source file can 
 contain zero classes or as many classes as you like.
 
 That said, it is convention to name source files and modules completely 
 lower-case, and to start class names with a capital. However, the 
 language does not actually enforce either of these. If nothing else, it 
 is a /very bad/ idea to ever name the source file and the module 
 different things, even if they just differ in capitalization.
 


I've noticed that unfortunatly, it can create quite a mess. I'm coming 
from C++, I don't know how Java handles it. Does it enforce it that hard?

Maybe I've misunderstood it, I thought Derek Parnell meant the following:

     module foo.bar; // corresponds to foo/bar.d
     class Bar // don't do this, use a different name
     {
         ...
     }
To avoid names such foo.bar.Bar, "if you stick to one class per file." 
This is something different than naming source file and module different.
Aug 15 2006
parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Lutger wrote:

 Kirk McDonald wrote:
 

 Lutger wrote:


 Derek Parnell wrote:


 No, I suggest you use a different naming convention. I would have your
 class name start with a Capital letter and have your source file 
 name all
 lowercase. And if you stick to one class per file, have your filename
 different to the class by adding a suffix or prefix. For example,

   module foo_m;
   class Foo
   {
    ...
   }




 Can I ask you, what is your reason for naming a source file 
 differently than the class? Does it have something to do with 
 importing magic?



 The name of the source file and the name of the class are completely 
 orthogonal. They have nothing to do with each other. They may be the 
 same or different as you wish. This is not Java: A source file can 
 contain zero classes or as many classes as you like.

 That said, it is convention to name source files and modules 
 completely lower-case, and to start class names with a capital. 
 However, the language does not actually enforce either of these. If 
 nothing else, it is a /very bad/ idea to ever name the source file and 
 the module different things, even if they just differ in capitalization.


 
 I've noticed that unfortunatly, it can create quite a mess. I'm coming 
 from C++, I don't know how Java handles it. Does it enforce it that hard?


Java mandates that each source file contain a single class with the same 
name as the file. Java is more strictly object-oriented than C++ or D, 
and can't have anything outside of a class.


 
 Maybe I've misunderstood it, I thought Derek Parnell meant the following:
 
     module foo.bar; // corresponds to foo/bar.d
     class Bar // don't do this, use a different name
     {
         ...
     }
 To avoid names such foo.bar.Bar, "if you stick to one class per file." 
 This is something different than naming source file and module different.


Well, that's fine. I see nothing wrong with that.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org
Aug 15 2006
prev sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Wed, 16 Aug 2006 00:31:47 +0200, Lutger wrote:


 Derek Parnell wrote:
 

 No, I suggest you use a different naming convention. I would have your
 class name start with a Capital letter and have your source file name all
 lowercase. And if you stick to one class per file, have your filename
 different to the class by adding a suffix or prefix. For example,
 
   module foo_m;
   class Foo
   {
    ...
   }


 
 Can I ask you, what is your reason for naming a source file differently 
 than the class? Does it have something to do with importing magic?


It is a personal POV of course, but I do it to avoid source code looking
like its hard to read. In other words, the references would look like ...

  auto x = new  foo_m.Foo;

rather than
  auto x = new Foo.Foo;

The duplication of symbols can get confusing after a while.

In Build, the class called 'Source' is contained in the module 'source.d'
and this makes a lot of code look strange. Especially when using static
members of the class.

  foreach(Source s; source.Source.AllFiles) ...


But each to their own.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
16/08/2006 10:18:56 AM
Aug 15 2006
parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Derek Parnell wrote:

 On Wed, 16 Aug 2006 00:31:47 +0200, Lutger wrote:
 

 Derek Parnell wrote:


 No, I suggest you use a different naming convention. I would have your
 class name start with a Capital letter and have your source file name all
 lowercase. And if you stick to one class per file, have your filename
 different to the class by adding a suffix or prefix. For example,

   module foo_m;
   class Foo
   {
    ...
   }


 Can I ask you, what is your reason for naming a source file differently 
 than the class? Does it have something to do with importing magic?


 
 It is a personal POV of course, but I do it to avoid source code looking
 like its hard to read. In other words, the references would look like ...
 
   auto x = new  foo_m.Foo;
 
 rather than
   auto x = new Foo.Foo;
 
 The duplication of symbols can get confusing after a while.
 
 In Build, the class called 'Source' is contained in the module 'source.d'
 and this makes a lot of code look strange. Especially when using static
 members of the class.
 
   foreach(Source s; source.Source.AllFiles) ...
 
 
 But each to their own.
 


Why do you access Source above in two different ways, in the same line? 
with base name "Source" and later with FQN "source.Source"?

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Aug 17 2006
parent Derek Parnell <derek psyc.ward> writes:
On Thu, 17 Aug 2006 12:04:50 +0100, Bruno Medeiros wrote:



   foreach(Source s; source.Source.AllFiles) ...




 

 Why do you access Source above in two different ways, in the same line? 
 with base name "Source" and later with FQN "source.Source"?


Because I mis-quoted myself. ;-)

   foreach(source.Source s; source.Source.AllFiles) ...

There, is that better sir?

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
Aug 17 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Jay Kyburz wrote:

 
 I have each of my classes in separate source files. the files are named the 
 same as the class.  Is it true that each source files is compiled to a 
 separate module? 


Source files and modules are effectively the same thing.  I think you 
could technically have two separate files with the same module name to 
split up large modules, but I consider that more of a hacker trick than 
anything.


 That a module needs to import any other module to access its classes?


Yes.


 These modules are the obj files right? 


Yup.


 Where is it getting the name of the modules from?


If no module name is supplied then it is assumed to be the same as the 
file name.  And in general, it is a bad idea to use a different file 
name from what you want the module name to be, because import statements 
reference the file name, not the module name (confusing, huh?).  If you 
want your module to be semantically grouped with other modules, you can 
specify a package name as a part of the module name. ie.

     // filename should be 'mymodule.d'
     module mymodule;

     // file should be 'mypackage\subgroup\mymodule.d'
     module mypackage.subgroup.mymodule;

In the latter case, you'd add the directory the 'mypackage' directory 
lives in into your include path.  Importing it would be:

     import mypackage.subgroup.mymodule;


 My source files are
 capitalized but from the looks of things module names need to be lowercase. 
 Or at least the first letter needs to be. eg. TaskArea class is save in 
 TaskArea.d but I need to import taskArea to access the class.  By disabling 
 clean I see that this is the name of the generated obj file. How come it 
 changes case on me? Should I stick with this naming convention for my 
 sources?


That's a matter of opinion.  According to the D style guide, module 
names should be lowercase.  But this is just a convention, and not 
everyone uses it.  Mango, for example, uses CamelCase module names 
similar to Java.  Whatever you choose, however, the capitalization of 
the module name, file name, and import statement should all be the same.


 Also, how does the dot syntax work?


See above.  Each dotted segment refers to a subdirectory name, with the 
last bit referring to a file name.  This directory chain is expected to 
hang off of one of the directories in your include path (whych can be 
set at compile time by adding a '-Ipathname' in addition to modifying 
sc.ini).


 I've downloaded and using TinyXML. I've dropped the sources in a folder 
 called TinyXML. To access this i need to import tinyxml.tinyxml not 
 TinyXML.tinlyxml. So the dot syntax is used to find objs in subfolders? And 
 it also requires lowercase?


Case shouldn't matter on Windows, but as above, the capitalization used 
in your import statement should match the capitalization of the path 
name.  I'm not sure why the capitalized form isn't working, though I've 
never tried to capitalized the path portion of the name.


 But then what is with std.stdio? I don't see an std folder? Is this a special 
 case?


The std folder is in dmd\src\phobos, which should be the first directory 
in your include path listed in dmd\bin\sc.ini.


 When i import dwt.all for GUI, it seems to be compiling all of it it every 
 time I build. Do I really need to recompile all of dwt every time i build?


Assuming you're using Build, it should build an object file for each .d 
file needed for the application if the object file doesn't already exist 
and put that file in the same directory as the .d file it corresponds 
to.  You can tell Build to get rid of the object files when it's done 
with them (thus forcing them to be re-built each time) by adding a 
'-clean' switch at the command-line, but it isn't required.


Sean
Aug 15 2006
parent Jay Kyburz <jay jaykyburz.com> writes:
On Wed, 16 Aug 2006 01:39:18 +1000, Sean Kelly wrote
(in article <ebsprc$2cmn$1 digitaldaemon.com>):


Thanks again guys.. This stuff is all great.  I never expected such a good 
response.
Aug 15 2006