randomIO, std.file, core.stdc.stdio

[Steven Schveighoffer via Digitalmars-d-learn]

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 binary random io?  What are the advantages?
>>>
>>> In particular, if one is reading and writing structs rather than
>>> arrays or ranges, are there any advantages?
>>
>> yes: keeping API consistent. ;-)
>>
>> for example, my stream i/o modules works with anything that has
>> `rawRead`/`rawWrite` methods, but don't bother to check for any other.
>>
>> besides, `rawRead` is just looks cleaner, even with all `(&a)[0..1])`
>> noise.
>>
>> so, a question of style.
>>
> OK.  If it's just a question of "looking cleaner" and "style", then I
> will prefer the core.stdc.stdio approach.  I find it's appearance
> extremely much cleaner...except that that's understating things. I'll
> probably wrap those routines in a struct to ensure things like files
> being properly closed, and not have explicit pointers persisting over
> large areas of code.

It's more than just that. Having a bounded array is safer than a 
pointer/length separated parameters. Literally, rawRead and rawWrite are 
inferred @safe, whereas fread and fwrite are not.

But D is so nice with UFCS, you don't have to live with APIs you don't 
like. Allow me to suggest adding a helper function to your code:

rawReadItem(T)(File f, ref T item) @trusted
{
    f.rawRead(&item[0 .. 1]);
}

-Steve