On Monday, September 12, 2011 14:53 Adam Burton wrote: > Simen Kjaeraas wrote: > > On Mon, 12 Sep 2011 23:13:29 +0200, Adam Burton <[email protected]> wrote: > >> I quite like the idea of > >> void[] representing a chunk of memory that could contain anything, > >> serialized data; an array of ubytes or strings, and allow ubyte[] to > >> just represent an array of ubytes (after all is serialized data an > >> array of bytes > >> or a block of data containing various data types cramed into it in some > >> organised manner?). In the end it is just a convention I like, not > >> attached > >> to it or anything, and D tends to discourage working based on > >> conventions anyway, I guess I am somewhat playing devil's advocate in > >> this paragraph > >> > >> :-). > > > > I believe the reasons for not using void[] is exactly that it could > > contain anything, including pointers, which likely would not be valid in > > the other end. > > How does a ubyte[] prevent that? If you've serialized an int (or even a > pointer) then ubyte[] is just as bad, ubyte[0] would seem to indicate a > meaningful unit of data itself when it's actually just the first byte of an > int (or pointer). void[] at least says "I don't know, I just know the start > and how long, you figure it out, I presume I have somewhere to go to be > given context".
With void[], you can pass something like int*[] to it without having to worry about converting it, because the conversion is implicity. ubyte[], on the other hand, forces you to do the conversion explicitly. So yes, you could still make it so that the ubyte[] passed in contains pointers, but you have to do it explicitly, whereas with void[], it'll take any array without complaining. - Jonathan M Davis
