Re: Socket & PrintWriter issue-- writing a float to a C client
"Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> wrote in message
news:45017f2f$0$640$bed64819@news.gradwell.net...
Dale King wrote:
char buffer[4];
int num;
float flt;
num = read(sockfd, buffer, 4);
memcpy(&flt, buffer, 4);
printf("You returned %f from the server\n", flt);
I hope that was meant as a joke as it is the *WORST* way to do this. It
is
non-portable. You are assuming that Java and C use the same binary
representation for their floating point values, which is a completely
unfounded assumption.
However the assumption /could/ be true in the OP's environment.
Which is basically what I said when I said it was non-portable. It will work
on some environments, but will not work in many others. It could break when
you changed machines or could even break with just a new version of the
compiler.
The key is to do one of three things.
1) Create an interchange format which is designed to be portable and
which is text based -- as Dale suggests.
2) Create an interchange format which is deigned to be portable and
which is binary based -- in which case the spec for the format must
lay down the exact layout at the bits and bytes level. For
instance
"the next four bytes are a 32-bit IEEE floating point
number in little-endian format"
Obviously your C and Java code will reflect the specification.
3) Create an interchange format which is /not/ designed to be portable
and which is binary based. In that case you have no real control
over when it stops working unless you control completely the
- machines it runs on
- compiler (make and version) the compiles it
- compiler options
(3) is obviously irresponsible,
which is why I said it is the worst way to do it.
but there's no general reason to prefer (1)
over (2) or vice versa. Of course, if you /do/ choose to use (2) then
there's
nothing to stop you choosing the format to be one that you can easily
implement
for your current /actual/ machines. In which case you might easily end up
with
an implementation which looked like the above code on the 'C' end of the
link.
I think there is a reason to prefer 1 over 2. If you chose 2 then you are
locking down how precise the number will be in the data format. What if we
later decide float is not precise enough and we want to use double on both
sides. Or perhaps we even go to BigDecimal. You then either have to throw
away that extra precision when talking between the two or change your
protocol. With choice1 it supports any arbitrary precision on either end.
You can certainly design a binary protocol (I don't actually find much
importance in the distinction between "text" and "binary") that allowed
variable precision but that would be a lot more work to implement.
--
Dale King