A few notes on choosing between Go and D for a quick project

FG via Digitalmars-d digitalmars-d at puremagic.com
Mon Mar 23 10:31:16 PDT 2015


On 2015-03-23 at 12:59, krzaq wrote:
> I'd argue that joiner is intuitive enough, but I agree on byChunk. I am also baffled why this byLine/byChunk madness is necessary at all, it should be something like
> File("path").startsWith(s)
> or
> File("path").data.startswith(s)

Yeah, that would be useful for example to test magic values at the beginning of files:

     string[] scripts;
     foreach (string path; dirEntries(topDir, SpanMode.depth))
         if (isFile(path) && File(path).startsWith("#!"))
             scripts ~= path;

but that's the simplest case of a bigger problem, because here you just need the first few bytes, and you don't want to read the whole file, nor anything more than a sector.

OTOH, there are also file formats like ZIP that put the meta information at the end of the file and scatter the rest of the data all over the place using offset information. You don't need to read everything just to grab the metadata. But, when I had a look at the sources of libzip, I went crazy seeing all the code performing tons of file seeking, reading into buffers and handling them[1].

D's std.zip took a simple approach and doesn't deal with that at all; it reads the whole file into the memory. That makes the algorithm more clearly visible, but at the same time it makes the module completely useless if you want to handle archives that are larger than the available memory, and over-the-top if all you wanted was to extract a single file from the archive or only read the directory structure.

So, how do you envision something representing a file, i.e. a mix of "BufferedRange" and "SeekableRange", that would neatly handle buffering and seeking, without you dropping to stdc IO or wanting to shoot yourself when you look at the code?


[1] for your amusement: http://hg.nih.at/libzip/file/78b8e3fa72a0/lib/zip_open.c


More information about the Digitalmars-d mailing list