On 07/27/2016 06:46 AM, Rene Zwanenburg via Digitalmars-d-learn wrote:
On Wednesday, 27 July 2016 at 02:20:57 UTC, Charles Hixson wrote:
O, dear. It was sounding like such an excellent approach until this
last paragraph, but growing the file is going to be one of the common
operations.
On Wednesday, 27 July 2016 at 02:20:57 UTC, Charles Hixson wrote:
O, dear. It was sounding like such an excellent approach until
this
last paragraph, but growing the file is going to be one of the
common
operations. (Certainly at first.) (...)
So I'm probably better off sticking to using a
On 07/26/2016 12:53 PM, Adam D. Ruppe via Digitalmars-d-learn wrote:
On Tuesday, 26 July 2016 at 19:30:35 UTC, Charles Hixson wrote:
It looks as if the entire file is stored in memory, which is not at
all what I want, but I also can't really believe that's what's going on.
It is just mapped
On Tuesday, 26 July 2016 at 16:35:26 UTC, Charles Hixson wrote:
That's sort of what I have in mind, but I want to do what in
Fortran would be (would have been?) called record I/O, except
that I want a file header that specifies a few things like
magic number, records allocated, head of free
On 7/26/16 3:30 PM, Charles Hixson via Digitalmars-d-learn wrote:
On 07/26/2016 11:31 AM, Steven Schveighoffer via Digitalmars-d-learn wrote:
Now, C i/o's buffering may not suit your exact needs. So I don't know
how it will perform. You may want to consider mmap which tells the
kernel to link
On Tuesday, 26 July 2016 at 19:30:35 UTC, Charles Hixson wrote:
It looks as if the entire file is stored in memory, which is
not at all what I want, but I also can't really believe that's
what's going on.
It is just mapped to virtual memory without actually being loaded
into physical
On 07/26/2016 11:31 AM, Steven Schveighoffer via Digitalmars-d-learn wrote:
On 7/26/16 1:57 PM, Charles Hixson via Digitalmars-d-learn wrote:
Thanks. Since there isn't any excess overhead I guess I'll use stdio.
Buffering, however, isn't going to help at all since I'm doing
randomIO. I know
On 7/26/16 1:57 PM, Charles Hixson via Digitalmars-d-learn wrote:
Thanks. Since there isn't any excess overhead I guess I'll use stdio.
Buffering, however, isn't going to help at all since I'm doing
randomIO. I know that most of the data the system reads from disk is
going to end up getting
On 07/26/2016 10:18 AM, Steven Schveighoffer via Digitalmars-d-learn wrote:
On 7/26/16 12:58 PM, Charles Hixson via Digitalmars-d-learn wrote:
Ranges aren't free, are they? If so then I should probably use stdfile,
because that is probably less likely to change than core.stdc.stdio.
Do you
On 7/26/16 12:58 PM, Charles Hixson via Digitalmars-d-learn wrote:
Ranges aren't free, are they? If so then I should probably use stdfile,
because that is probably less likely to change than core.stdc.stdio.
Do you mean slices?
When I see "f.rawRead([0 .. 1])" it looks to me as if unneeded
On 07/26/2016 05:31 AM, Steven Schveighoffer via Digitalmars-d-learn wrote:
On 7/25/16 9:19 PM, Charles Hixson via Digitalmars-d-learn wrote:
On 07/25/2016 05:18 PM, ketmar via Digitalmars-d-learn wrote:
On Monday, 25 July 2016 at 18:54:27 UTC, Charles Hixson wrote:
Are there reasons why one
On 07/25/2016 09:22 PM, ketmar via Digitalmars-d-learn wrote:
On Tuesday, 26 July 2016 at 04:05:22 UTC, Charles Hixson wrote:
Yes, but I really despise the syntax they came up with. It's
probably good if most of your I/O is ranges, but mine hasn't yet ever
been. (Combining ranges with random
On 7/25/16 9:19 PM, Charles Hixson via Digitalmars-d-learn wrote:
On 07/25/2016 05:18 PM, ketmar via Digitalmars-d-learn wrote:
On Monday, 25 July 2016 at 18:54:27 UTC, Charles Hixson wrote:
Are there reasons why one would use rawRead and rawWrite rather than
fread and fwrite when doiing
On Tuesday, 26 July 2016 at 04:05:22 UTC, Charles Hixson wrote:
Yes, but I really despise the syntax they came up with. It's
probably good if most of your I/O is ranges, but mine hasn't
yet ever been. (Combining ranges with random I/O?)
that's why i wrote iv.stream, and then iv.vfs, with
On 07/25/2016 07:11 PM, ketmar via Digitalmars-d-learn wrote:
On Tuesday, 26 July 2016 at 01:19:49 UTC, Charles Hixson wrote:
then I will prefer the core.stdc.stdio approach. I find it's
appearance extremely much cleaner...
only if you are really used to write C code. when you see pointer,
On Tuesday, 26 July 2016 at 01:19:49 UTC, Charles Hixson wrote:
then I will prefer the core.stdc.stdio approach. I find it's
appearance extremely much cleaner...
only if you are really used to write C code. when you see
pointer, or explicit type size argument in D, it is a sign of C
On 07/25/2016 05:18 PM, ketmar via Digitalmars-d-learn wrote:
On Monday, 25 July 2016 at 18:54:27 UTC, Charles Hixson wrote:
Are there reasons why one would use rawRead and rawWrite rather than
fread and fwrite when doiing binary random io? What are the advantages?
In particular, if one is
On Monday, 25 July 2016 at 18:54:27 UTC, Charles Hixson wrote:
Are there reasons why one would use rawRead and rawWrite rather
than fread and fwrite when doiing binary random io? What are
the advantages?
In particular, if one is reading and writing structs rather
than arrays or ranges, are
18 matches
Mail list logo
