Adam Burton wrote:
> Jonathan M Davis wrote: > >> 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 > Fair enough that's more clear, I hadn't actually thought of an array of > pointers as I was thinking of a pointer forced into ubyte[] with other > data types. I suppose that'll help remind people to double check what they > are sending but if you are going to send int*[] down a socket then you're > probably gonna put cast(ubyte[]) without looking anyway. Just a thought then, rather than using ubyte[] and casting to force someone to check (and possibly encourage a bad habit of automatically putting in a cast without checking, through fustration or over confidence) make send and receive templates methods that don't accept types we are unable to determine how to handle (like pointers and classes)? Maybe even give a static assert with an error message explaining pointers etc are not allowed?
