www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Passing file handles from functions? (Changed since dmd v0.118)

reply AEon <aeon2001 lycos.de> writes:
Last coding D 3.5 years ago. I wrote functions that would return the 
file handle. But such code no longer compiles under v1.030 (it worked 
under v0.118 though). Could someone please tell me how this may be fixed.

Compiler error:
   ---
   dmd -c -w -version=db_log -O -I. aepar.d
   aepar_file.d(706): Error: identifier 'File' is not defined
   aepar_file.d(706): Error: File is used as a type
   ---

aepar.d:
   ---snip---
   File open_Read_Log( char[] logfile )    // Line 706
   {
     if( ! std.file.exists(logfile) )  exit(1);

     File lg = new File( logfile, FileMode.In );
     return lg;
   }
   ---snip---

Function call from another function:
   ---snip---
   File lg = open_Read_Log( "filename" );
   ---snip---

Thanks.

AEon
Sep 17 2008
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to AEon,


 Last coding D 3.5 years ago. I wrote functions that would return the
 file handle. But such code no longer compiles under v1.030 (it worked
 under v0.118 though). Could someone please tell me how this may be
 fixed.
 



Can I assume that you are importing std.stream ?
Sep 17 2008
parent reply AEon <aeon2001 lycos.de> writes:
BCS wrote:

 Reply to AEon,
 

 Last coding D 3.5 years ago. I wrote functions that would return the
 file handle. But such code no longer compiles under v1.030 (it worked
 under v0.118 though). Could someone please tell me how this may be
 fixed.


 
 Can I assume that you are importing std.stream ?


Yes you can... because "File" works everywhere else.

If that should make a difference, I am importing another module that
itself imports:

import std.c.stdio;
import std.c.stdlib;
import std.stdio;
import std.path;
import std.file;
import std.string;
import std.conv;
import std.date;
import std.stream;

AEon
Sep 17 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
AEon <aeon2001 lycos.de> wrote:

 BCS wrote:

 Reply to AEon,
 

 Last coding D 3.5 years ago. I wrote functions that would return the
 file handle. But such code no longer compiles under v1.030 (it worked
 under v0.118 though). Could someone please tell me how this may be
 fixed.


 
 Can I assume that you are importing std.stream ?


 
 Yes you can... because "File" works everywhere else.
 
 If that should make a difference, I am importing another module that
 itself imports:
 
 import std.c.stdio;
 import std.c.stdlib;
 import std.stdio;
 import std.path;
 import std.file;
 import std.string;
 import std.conv;
 import std.date;
 import std.stream;


From reading other people's code and Phobos sources I came to conclusion 
that, long ago, imports were public by default.  They are not anymore.  
Imports are private by default, this may be your problem.
Sep 17 2008
parent reply BCS <ao pathlink.com> writes:
Reply to Sergey,


 AEon <aeon2001 lycos.de> wrote:
 

 BCS wrote:
 

 Reply to AEon,
 

 Last coding D 3.5 years ago. I wrote functions that would return
 the file handle. But such code no longer compiles under v1.030 (it
 worked under v0.118 though). Could someone please tell me how this
 may be fixed.
 


 Can I assume that you are importing std.stream ?
 


 Yes you can... because "File" works everywhere else.
 
 If that should make a difference, I am importing another module that
 itself imports:
 
 import std.c.stdio;
 import std.c.stdlib;
 import std.stdio;
 import std.path;
 import std.file;
 import std.string;
 import std.conv;
 import std.date;
 import std.stream;


 From reading other people's code and Phobos sources I came to
 conclusion that, long ago, imports were public by default.  They are
 not anymore.  Imports are private by default, this may be your
 problem.
 


That is true. The change was not to far from v1.000
Sep 17 2008
parent reply AEon <aeon2001 lycos.de> writes:
BCS wrote:

 Reply to Sergey,
 

 AEon <aeon2001 lycos.de> wrote:


 BCS wrote:


 Reply to AEon,


 Last coding D 3.5 years ago. I wrote functions that would return
 the file handle. But such code no longer compiles under v1.030 (it
 worked under v0.118 though). Could someone please tell me how this
 may be fixed.


 Can I assume that you are importing std.stream ?


 Yes you can... because "File" works everywhere else.

 If that should make a difference, I am importing another module that
 itself imports:

 import std.c.stdio;
 import std.c.stdlib;
 import std.stdio;
 import std.path;
 import std.file;
 import std.string;
 import std.conv;
 import std.date;
 import std.stream;


 From reading other people's code and Phobos sources I came to
 conclusion that, long ago, imports were public by default.  They are
 not anymore.  Imports are private by default, this may be your
 problem.


 
 That is true. The change was not to far from v1.000


Pardon my ignorance, this is only day 3 of me reading up on D again, but 
would that mean I have to place the "same" list of library imports into 
every module I use, instead of defining such a list in one "central" 
module, that is then imported by all the other modules?

To the aepar_file.d module I just added an explicit "import std.stream", 
even though aepar_global.d already imports that libarary:

     module aepar_file;
     import aepar_global;     // Global Variables, Libs etc.

     import std.stream;       // File, open(), close(), ...

And the compiler no longer shows the warning. IT WORKS! :). Thanks.


So my "style guide" question?

Should I refrain from using a global library include module 
(aepar_global.d), to instead include the libs on a per module basis, 
including only those libs the functions actually need? Or is there some 
other way?
Sep 18 2008
parent reply Lars Kyllingstad <public kyllingen.NOSPAMnet> writes:
AEon wrote:

 Pardon my ignorance, this is only day 3 of me reading up on D again, but 
 would that mean I have to place the "same" list of library imports into 
 every module I use, instead of defining such a list in one "central" 
 module, that is then imported by all the other modules?
 
 [...]
 
 So my "style guide" question?
 
 Should I refrain from using a global library include module 
 (aepar_global.d), to instead include the libs on a per module basis, 
 including only those libs the functions actually need? Or is there some 
 other way?


If you use the *same* imports in every module, perhaps it makes sense to 
create a module that imports them all. To do this, you use the 'public 
import' statement, i.e. in aepar_global.d you write

   public import std.c.stdio;
   public import std.c.stdlib;
   ...

However, most of the time this is not true, at least not in my 
experience. I think it's better to keep the namespace clean and tidy by 
using only the imports one actually needs in each module. Private 
imports are the default, as Sergey pointed out.

-Lars
Sep 18 2008
parent reply AEon <aeon2001 lycos.de> writes:
Lars Kyllingstad wrote:


 AEon wrote:

 Pardon my ignorance, this is only day 3 of me reading up on D again, 
 but would that mean I have to place the "same" list of library imports 
 into every module I use, instead of defining such a list in one 
 "central" module, that is then imported by all the other modules?

 [...]

 So my "style guide" question?

 Should I refrain from using a global library include module 
 (aepar_global.d), to instead include the libs on a per module basis, 
 including only those libs the functions actually need? Or is there 
 some other way?


 
 If you use the *same* imports in every module, perhaps it makes sense to 
 create a module that imports them all. To do this, you use the 'public 
 import' statement, i.e. in aepar_global.d you write
 
   public import std.c.stdio;
   public import std.c.stdlib;
   ...
 
 However, most of the time this is not true, at least not in my 
 experience. I think it's better to keep the namespace clean and tidy by 
 using only the imports one actually needs in each module. Private 
 imports are the default, as Sergey pointed out.
 
 -Lars


Ah... I have noted how "messed up" my namespace was. Back then I ported 
the parser code (AEstats) directly from ANSI C and v0.118 seems to have 
been tolerant enough to let me use "import" pretty much the way I was 
using "include" under C. You are right, I also prefer to have things as 
clearly implemented as possible.

What surpised me, after removing the global import of libs, was that my 
modules did not seem to need any of the libs... I find that a bit strange.


Question: Will dmd make it pretty clear when it needs some library 
included? I.e. the compiler shows a warning / error?

Because that way I could minimize the libs to include on a per module basis.


Thanx for everyone being pacient with me, alas all the examples I have 
been reading are all in one module, not distributed into many modules as 
part of a project.

AEon
Sep 18 2008
parent reply Lars Kyllingstad <public kyllingen.NOSPAMnet> writes:
AEon wrote:

 Lars Kyllingstad wrote:
 

 AEon wrote:

 Pardon my ignorance, this is only day 3 of me reading up on D again, 
 but would that mean I have to place the "same" list of library 
 imports into every module I use, instead of defining such a list in 
 one "central" module, that is then imported by all the other modules?

 [...]

 So my "style guide" question?

 Should I refrain from using a global library include module 
 (aepar_global.d), to instead include the libs on a per module basis, 
 including only those libs the functions actually need? Or is there 
 some other way?


 If you use the *same* imports in every module, perhaps it makes sense 
 to create a module that imports them all. To do this, you use the 
 'public import' statement, i.e. in aepar_global.d you write

   public import std.c.stdio;
   public import std.c.stdlib;
   ...

 However, most of the time this is not true, at least not in my 
 experience. I think it's better to keep the namespace clean and tidy 
 by using only the imports one actually needs in each module. Private 
 imports are the default, as Sergey pointed out.

 -Lars


 
 Ah... I have noted how "messed up" my namespace was. Back then I ported 
 the parser code (AEstats) directly from ANSI C and v0.118 seems to have 
 been tolerant enough to let me use "import" pretty much the way I was 
 using "include" under C. You are right, I also prefer to have things as 
 clearly implemented as possible.
 
 What surpised me, after removing the global import of libs, was that my 
 modules did not seem to need any of the libs... I find that a bit strange.


This is why D's import is much better than C's #include.


 Question: Will dmd make it pretty clear when it needs some library 
 included? I.e. the compiler shows a warning / error?


Sure, if you try to use a function/class/whatever that hasn't been 
imported, the compiler will emit an error. (It will not, however, tell 
you which module you should import to make it work.)

-Lars
Sep 18 2008
parent AEon <aeon2001 lycos.de> writes:
Lars Kyllingstad wrote:

 AEon wrote:

 Question: Will dmd make it pretty clear when it needs some library 
 included? I.e. the compiler shows a warning / error?


 
 Sure, if you try to use a function/class/whatever that hasn't been 
 imported, the compiler will emit an error. (It will not, however, tell 
 you which module you should import to make it work.)


Ah... right... the compiler was still stuck with the high priority 
errors, my modules are now showing all the errors due to missing libs. 
Easter egg hunt :)

Luckily, I copy/pasted all of the docs from digital mars into one word 
file, letting me search what libs contain what functions.
(Just noted the http://www.digitalmars.com/d/1.0/phobos/std_c_stdio.html 
search works as well).

Thanx...

AEon
Sep 18 2008
prev sibling parent BCS <ao pathlink.com> writes:
Reply to AEon,


 Last coding D 3.5 years ago. I wrote functions that would return the
 file handle. But such code no longer compiles under v1.030 (it worked
 under v0.118 though). Could someone please tell me how this may be
 fixed.
 
 Compiler error:
 ---
 dmd -c -w -version=db_log -O -I. aepar.d
 aepar_file.d(706): Error: identifier 'File' is not defined
 aepar_file.d(706): Error: File is used as a type
 ---
 aepar.d:
 ---snip---
 File open_Read_Log( char[] logfile )    // Line 706
 {
 if( ! std.file.exists(logfile) )  exit(1);
 File lg = new File( logfile, FileMode.In );
 return lg;
 }
 ---snip---
 Function call from another function:
 ---snip---
 File lg = open_Read_Log( "filename" );
 ---snip---
 Thanks.
 
 AEon
 


One option (the first error makes me think it's not the case) is that there 
is another File in scope. Try "std.stream.File"
Sep 17 2008