[Issue 1482] std.file docs are insufficient

d-bugmail at puremagic.com d-bugmail at puremagic.com
Fri Sep 7 16:46:34 PDT 2007


http://d.puremagic.com/issues/show_bug.cgi?id=1482


thecybershadow at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://digitalmars.com/d/pho
                   |                            |bos/std_file.html




------- Comment #1 from thecybershadow at gmail.com  2007-09-07 18:46 -------
It returns an array of the bytes that it read from the file. I think that the
bug here is that the specs don't describe what a void[] really is. Closest to
that is the "Implicit Conversions" sections here: 

http://digitalmars.com/d/arrays.html#strings
(linked to closest anchor, scroll a bit below)

A void[] is functionally the same as a byte[] or ubyte[], with the differences:
1) you can't access an element of it (since the type of the underlying data is
unknown)
2) any array implicitly converts to void[] - this allows you to work with
functions that take void[] arguments without using explicit casts, except when
you need to pass something that isn't an array, in which case you have to
resort to syntax like write(filename, &mystruct[0..1]). 

IMO D or Phobos should have a simple syntax or template that allows you to
convert any variable to a void[], which is essentially a void* and a length.
Currently I use this (pretty crude) template (which likely can be rewritten in
a much better way):

struct BufferEx
{
        union
        {
                buffer buf;
                struct Fields
                {
                        size_t length;
                        void* ptr;
                } Fields fields;
        }
}

buffer toBuffer(T)(inout T data)
{
        BufferEx b;
        b.fields.ptr = &data;
        b.fields.length = T.sizeof;
        return b.buf;
}

The std.file functions aren't part of a class. Upside is simple and readable
code for small programs, downside is possible name collisions ("read"/"write"
is a common thing to be found in the global namespace). Yay for
selective/static/renaming imports, I guess. Note that Tango uses a File class
(which makes the code more bloated, as you need two operations - class
instantiation and the operation - for a single file operation).

P.S. It's none of my business, but is IBM interested in D now? :)


-- 



More information about the Digitalmars-d-bugs mailing list