Thread overview | |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
September 17, 2008 Passing file handles from functions? (Changed since dmd v0.118) | ||||
---|---|---|---|---|
| ||||
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 |
September 18, 2008 Re: Passing file handles from functions? (Changed since dmd v0.118) | ||||
---|---|---|---|---|
| ||||
Posted in reply to AEon | 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 ?
|
September 18, 2008 Re: Passing file handles from functions? (Changed since dmd v0.118) | ||||
---|---|---|---|---|
| ||||
Posted in reply to BCS | 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
|
September 18, 2008 Re: Passing file handles from functions? (Changed since dmd v0.118) | ||||
---|---|---|---|---|
| ||||
Posted in reply to AEon | 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.
|
September 18, 2008 Re: Passing file handles from functions? (Changed since dmd v0.118) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sergey Gromov | 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
|
September 18, 2008 Re: Passing file handles from functions? (Changed since dmd v0.118) | ||||
---|---|---|---|---|
| ||||
Posted in reply to AEon | 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"
|
September 18, 2008 Re: Passing file handles from functions? (Changed since dmd v0.118) | ||||
---|---|---|---|---|
| ||||
Posted in reply to BCS | 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? |
September 18, 2008 Re: Passing file handles from functions? (Changed since dmd v0.118) | ||||
---|---|---|---|---|
| ||||
Posted in reply to AEon | 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
|
September 18, 2008 Re: Passing file handles from functions? (Changed since dmd v0.118) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Lars Kyllingstad | 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
|
September 18, 2008 Re: Passing file handles from functions? (Changed since dmd v0.118) | ||||
---|---|---|---|---|
| ||||
Posted in reply to AEon | 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 |
Copyright © 1999-2021 by the D Language Foundation