Steven Schveighoffer <> changed:

           What    |Removed                     |Added
                 CC|                            |

--- Comment #5 from Steven Schveighoffer <> 2010-08-04 
05:24:44 PDT ---
(In reply to comment #4)
> One can add that .dup-ing a void[] will make all the precaution in
> of allocating the void[] with GC.BlkAttr.NO_SCAN useless. The
> dup'ed array won't have the NO_SCAN flag set. It really shows that void[] is
> not the natural type to use here.

any array operation which copies a block to another copies the flags from the
original array block.  So the NO_SCAN flag should persist.  If it doesn't,
that's a bug (looking at it, dup is the only function that doesn't copy the
block attributes, I'll address this on the mailing list).

I think the void[] type is more consistent than ubyte.

Consider two things.  First, a read where the array is provided by the caller. 
If this function is typed:

ubyte[] read(ubyte[] into);

then, you must cast your data to a ubyte[].  But void[] can be implicitly cast
to from anything, so void[] wins here.

Second, a write operation:

int write(ubyte[] from);

Again, cast is necessary where void[] would not require it.

To be sure could return a ubyte[], and unless you intend to
actually deal with it as a ubyte[], you need to cast to the type you need.  But
shouldn't it be consistent with other operations?

But we can forgo all this stuff if we add a template parameter to read, so you
can specify exactly the type you want.  If you know your file is a bunch of
int's, you could do:!(int)();

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to