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 
of Basic and Pascal and a bit of C#. Most of these have been presented in a 
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 
 of Basic and Pascal and a bit of C#. Most of these have been presented in a 
 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.

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? 

 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
   {
    ...
   }

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