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

-- Dmitry Olshansky
May 15 2012
prev sibling 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 next 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=

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

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

 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