On 13.09.2011 2:44, Adam Burton wrote:
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?
Don't forget that there is also network byte order vs host machine byte
order. In other words everything should be (de)serialized, except plain
bytes/chars.
There was a talk of making result of e.g. htonl a special type so that
it can be send directly w/o cast, dunno if it's that useful. As a safety
net untill complementary call to ntohl this special type is unusable for
anything else except storage/copy.
Actually now when I recalled it, it seems to me like a good thing. Being
able to catch wrong byte order statically is nice, since it's a hard to
track bug (e.g. missing both of hton*/ntoh*).
--
Dmitry Olshansky
