www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - std.file, std.stdio(File), std.stream(File:Stream)

reply "ref2401" <refactor24 gmail.com> writes:
general question:
-std.file,
-std.stdio.File,
-std.stream.File

which of the existing approaches i have to choose when working 
with files? what shall i look at?

for example, i have a binary file. i want to read the first byte, 
process it and then read the following N bytes (N calculation 
based on the first byte value), process this chunk and then read 
the file to the end.
May 15 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, May 15, 2012 at 05:14:15PM +0200, ref2401 wrote:

 general question:
 -std.file,


std.file is badly named. It really deals with the _filesystem_, that is,
pathnames, etc.. It doesn't deal with individual files.



 -std.stdio.File,


Use this.



 -std.stream.File


This will soon be deprecated, don't use it.



 which of the existing approaches i have to choose when working with
 files? what shall i look at?
 
 for example, i have a binary file. i want to read the first byte,
 process it and then read the following N bytes (N calculation based
 on the first byte value), process this chunk and then read the file
 to the end.


Use std.stdio.File.rawRead and pass in a byte[] parameter.


T

-- 
People tell me that I'm skeptical, but I don't believe it.
May 15 2012
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 15.05.2012 19:32, H. S. Teoh wrote:

 On Tue, May 15, 2012 at 05:14:15PM +0200, ref2401 wrote:

 general question:
 -std.file,


 std.file is badly named. It really deals with the _filesystem_, that is,
 pathnames, etc.. It doesn't deal with individual files.


Bleh, std.file.read does just that - reads entire file into memory. In 
essence std.file works with filesystem and files, and unit of work is a 
file.


 -std.stdio.File,


 Use this.



 -std.stream.File


 This will soon be deprecated, don't use it.


Yup.

-- 
Dmitry Olshansky
May 15 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, May 15, 2012 at 07:47:24PM +0400, Dmitry Olshansky wrote:

 On 15.05.2012 19:32, H. S. Teoh wrote:

On Tue, May 15, 2012 at 05:14:15PM +0200, ref2401 wrote:

general question:
-std.file,


std.file is badly named. It really deals with the _filesystem_, that is,
pathnames, etc.. It doesn't deal with individual files.


 
 Bleh, std.file.read does just that - reads entire file into memory.
 In essence std.file works with filesystem and files, and unit of
 work is a file.


[...]

OK, that is totally deserving of a WAT. The split between std.file,
std.stdio, std.stream, etc., are just soooo illogical. I'm hoping that
std.io will eventually clear up this crazy mess, but I suspect std.file
will still remain. Is there any logical reason why we shouldn't rename
it to std.filesystem or std.fs? Calling it std.file is needlessly
confusing, esp. given that most of the functions actually concerned with
file I/O are in std.stdio (or the future std.io).


T

-- 
Give a man a fish, and he eats once. Teach a man to fish, and he will sit
forever.
May 15 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, May 15, 2012 09:48:23 H. S. Teoh wrote:

 On Tue, May 15, 2012 at 07:47:24PM +0400, Dmitry Olshansky wrote:

 On 15.05.2012 19:32, H. S. Teoh wrote:

On Tue, May 15, 2012 at 05:14:15PM +0200, ref2401 wrote:

general question:
-std.file,


std.file is badly named. It really deals with the _filesystem_, that is,
pathnames, etc.. It doesn't deal with individual files.


 
 Bleh, std.file.read does just that - reads entire file into memory.
 In essence std.file works with filesystem and files, and unit of
 work is a file.


 
 [...]
 
 OK, that is totally deserving of a WAT. The split between std.file,
 std.stdio, std.stream, etc., are just soooo illogical. I'm hoping that
 std.io will eventually clear up this crazy mess, but I suspect std.file
 will still remain. Is there any logical reason why we shouldn't rename
 it to std.filesystem or std.fs? Calling it std.file is needlessly
 confusing, esp. given that most of the functions actually concerned with
 file I/O are in std.stdio (or the future std.io).


std.file operates on files. I don't see anything wrong with it. Most of it
isn't 
I/O though (aside from read and write which operate on the whole file at once). 
The I/O stuff is in std.stdio. I really don't think that the current separation 
is a problem. std.stdio definitely needs some work (hence the future std.io), 
but I think that std.file is fine as-is. Renaming it would break code to no 
benefit IMHO.

- Jonathan M Davis
May 16 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, May 16, 2012 at 08:37:08PM -0700, Jonathan M Davis wrote:

 On Tuesday, May 15, 2012 09:48:23 H. S. Teoh wrote:

 On Tue, May 15, 2012 at 07:47:24PM +0400, Dmitry Olshansky wrote:

 On 15.05.2012 19:32, H. S. Teoh wrote:

On Tue, May 15, 2012 at 05:14:15PM +0200, ref2401 wrote:

general question:
-std.file,


std.file is badly named. It really deals with the _filesystem_,
that is, pathnames, etc.. It doesn't deal with individual files.


 
 Bleh, std.file.read does just that - reads entire file into
 memory.  In essence std.file works with filesystem and files, and
 unit of work is a file.


 
 [...]
 
 OK, that is totally deserving of a WAT. The split between std.file,
 std.stdio, std.stream, etc., are just soooo illogical. I'm hoping
 that std.io will eventually clear up this crazy mess, but I suspect
 std.file will still remain. Is there any logical reason why we
 shouldn't rename it to std.filesystem or std.fs? Calling it std.file
 is needlessly confusing, esp. given that most of the functions
 actually concerned with file I/O are in std.stdio (or the future
 std.io).


 
 std.file operates on files. I don't see anything wrong with it.


[...]

Hindsight is always 20/20.  I agree with you that it makes sense... but
only after you've learned what it is. This does not help newcomers nor
give them a good impression of D. We need to reduce the amount of stuff
that only makes sense after the fact, especially when there's no good
reason to do so.


T

-- 
In order to understand recursion you must first understand recursion.
May 16 2012
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, May 16, 2012 20:58:02 H. S. Teoh wrote:

 Hindsight is always 20/20.  I agree with you that it makes sense... b=


ut

 only after you've learned what it is. This does not help newcomers no=


r

 give them a good impression of D. We need to reduce the amount of stu=


ff

 that only makes sense after the fact, especially when there's no good=



 reason to do so.


I really don't think that renaming the module is going to help much wit=
h that.=20
std.file is plenty descriptive. It operates on files, and the name make=
s that=20
clear. And its module documentation is _quite_ clear on the matter:

--------------
Util=C2=ADi=C2=ADties for ma=C2=ADnip=C2=ADu=C2=ADlat=C2=ADing files an=
d scan=C2=ADning di=C2=ADrec=C2=ADto=C2=ADries. Func=C2=ADtions=20
in this mod=C2=ADule han=C2=ADdle files as a unit, e.g., read or write =
one file at a time.=20
For open=C2=ADing files and ma=C2=ADnip=C2=ADu=C2=ADlat=C2=ADing them v=
ia han=C2=ADdles refer to mod=C2=ADule=20
std.=E2=80=8Bstdio.
--------------

I don't see how you can get any clearer than that.

- Jonathan M Davis
May 16 2012