www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - import syntax

reply Karl Bochert <Karl_member pathlink.com> writes:
Is there some reason why the syntax is 
import std.c.stdio
Rather than 
import std\c\stdio

The dot syntax prevents the use of relative paths to modules ( I'm guessing -- I
haven't actually tried 'import ......foo;' )

Are relative paths considered bad for imports?
Is this just an unfortunate side-effect of a syntax that has other advantages?

I guess the work-around is to use the -I compiler switch which seems like a
terrible approach to me, moving information that should be in the source to the
makefile.
Jul 03 2006
next sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Karl Bochert wrote:
 Is there some reason why the syntax is 
 import std.c.stdio
 Rather than 
 import std\c\stdio
 
 The dot syntax prevents the use of relative paths to modules ( I'm guessing --
I
 haven't actually tried 'import ......foo;' )
 
 Are relative paths considered bad for imports?
 Is this just an unfortunate side-effect of a syntax that has other advantages?
 
 I guess the work-around is to use the -I compiler switch which seems like a
 terrible approach to me, moving information that should be in the source to the
 makefile.
 

Except that I haven't touched a makefile in ages. Check out the Build utility: http://www.dsource.org/projects/build All I usually ever run anymore is one of 'build debug', 'build doc', or 'build release'. As to the use of the dot in imports, the reason is simple: you are /not/ importing a path, but rather a module which may or may not belong to a package. For example, so I have a module 'array' in package 'utils'. Say that I have package 'utils' stored with some other code in the subdirectory 'lib'. My module 'array' has declared itself 'module utils.array;' ... so I can only import it as 'import utils.array;'. The location of that package in the filesystem is meaningless to my program, only the relative location of the modules within their packages (if any) has any meaning. However, the compiler needs to know where to look for packages and modules, so I need to pass '-Ilib' on the command line, or in my Build Response File. -- Chris Nicholson-Sauls
Jul 03 2006
prev sibling next sibling parent BCS <BCS pathlink.com> writes:
Karl Bochert wrote:
 Is there some reason why the syntax is 
 import std.c.stdio
 Rather than 
 import std\c\stdio
 
 The dot syntax prevents the use of relative paths to modules ( I'm guessing --
I
 haven't actually tried 'import ......foo;' )
 
 Are relative paths considered bad for imports?
 Is this just an unfortunate side-effect of a syntax that has other advantages?
 
 I guess the work-around is to use the -I compiler switch which seems like a
 terrible approach to me, moving information that should be in the source to the
 makefile.
 

actually the better solution is to run DMD with its current directory set to the root. If that is more than one location, in all likelihood, all but one of the roots are librarys and thus should be pointed to by -I anyway
Jul 03 2006
prev sibling parent Mike Parker <aldacron71 yahoo.com> writes:
Karl Bochert wrote:
ges?
 
 I guess the work-around is to use the -I compiler switch which seems like a
 terrible approach to me, moving information that should be in the source to the
 makefile.

It's not a work-around. It's the way the system is intended to work. This is more flexible than hard coding relative paths in your code. You are telling the compiler to look for a module which resides in a 'package' on the import path. Don't think of it as a directory tree. mypackage.mymodule means that 'mymodule' belongs to a package named 'mypackage'. The fact that the compiler looks for a directory named 'mypackage' and a file named 'mymodule' are a consequence of the file system. I have three common import locations on my system: the default location that DMD defines in sc.ini (it is where phobos resides); a common directory where I have all third-party packates that I use (C:\dev\D\import is what I've called it); in every project I start I keep all of the source in 'src' directory with subdirs matching package names. When compiling, I pass -IC:\dev\D\import and -Isrc to the compiler (these options are set in a Build response file since I use Build and not DMD directly). I assume you come from a C or C++ background. You're in D land now. import statements are not the same as #include directives. Realizing that will help you to understand the difference.
Jul 03 2006