More binary I/O problems

Charles Hixson via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Fri Apr 8 20:15:58 PDT 2016



On 04/08/2016 07:42 PM, Basile B. via Digitalmars-d-learn wrote:
> On Friday, 8 April 2016 at 20:58:06 UTC, Charles Hixson wrote:
>>> [...]
>> And that worked, but suddenly (after a compiler upgrade, did that 
>> matter? I'd also changed the program, though in ways that shouldn't 
>> have affected this.) it stopped working with the message:
>> let4a.d(138): Error: no [] operator overload for type Chnk
>>
>> [...]
>
> you can cast too (void*)
>
> struct Chnk
> {
>     char[20] wrd;
>     ubyte  length;
>     ulong  id;
>     this (ulong id, string wrd) {}
>     uint hCode () {return  0;}
>     string toString () { return "";}
>     string wrdStr() {return "";}
> }
>
> void main()
> {
>     import std.file: read, write;
>     Chnk c;
>     write("a.txt", (cast(void*)&c)[0..Chnk.sizeof]);
>     auto buff = read("a.txt", Chnk.sizeof);
>     (cast(void*)&c)[0..Chnk.sizeof] = buff[0..Chnk.sizeof];
> }
>
Thanks.  That syntax looks like it would work, but gee!  The syntax is 
getting worse and worse.
OTOH, I notice that you're using a file name rather than a File. Perhaps 
that's my problem, but if so how do I specify that I want a binary 
read/write rather than a text one.  (I notice that you named the file 
"a.txt", and I explicitly do not want to do a text conversion.  That 
would result in different numbers taking up different numbers of bytes, 
and so random addressing wouldn't work.)  Also read indicates that it 
tries to read in the entire file, so perhaps it's not intended for this 
purpose, and I should use rawRead/rawWrite which should work with that 
hideous cast & copy to/from ubyte[] step.

I suppose I could code the I/O in C...that way I might need to use 
foreign calling conventions, but the I/O would be straightforwards. And 
since everything is fixed length it should be an easy transition...
I want to use D because the garbage collection is useful and the 
handling of unicode strings/chars is hard to beat.  It would also mean I 
didn't need to use ZMQ when I got around to parallel execution.  But 
this code was working, and now it suddenly isn't.  I know you pointed 
out that I could get around this by copying it to a buffer, and writing 
out the buffer, and then reading in the buffer, and then copying the 
buffer to the object, with lots of casting. And I admit that it's 
doable, but I'm having trouble believing how ugly it is.  Not to mention 
that this is needed because code that used to be working stopped 
working.  Fortunately I was still developing this area, or it might have 
broken totally and I wouldn't have known until I tried to put the pieces 
together.


More information about the Digitalmars-d-learn mailing list