bo******@hotmail.com wrote On 04/24/06 11:21,:
I am trying to write a function that returns a float. This is what the
function should do: It takes the socket number and a variable name.
The function looks up the variable in an array of structs stored on a
server. The string (of a float number) stored is returned. The
function works except that it does not return a float. It retreives
the string fine, but I don't know why it is not converting the string
to a float. What am I doing wrong?
Impossible to say with certainty, since the code
you provided is incomplete. At a guess, though, you
forgot to #include <stdlib.h>.
Two words of advice. First, when you have some
code whose behavior baffles you, post all of the code
and not just a few snippets or paraphrases. After all,
the very fact that you don't understand why the code
behaves as it does means that you are unqualified to
decide what parts are relevant and what are unimportant.
In the instance at hand you have shortened your posting
by omitting some "obvious" context, but it is likely
that the context itself is what is wrong.
Second, when posting complete code you should first
make an effort to strip away all distractions and side-
issues. Your question was about why the function didn't
seem to be converting a string to a float value, and the
fact that the string came from a socket connection had
nothing to do with the matter. You could have whittled
it all away and posted the following complete program
instead:
#include <stdio.h>
float readFloatVar(void);
int main(void) {
printf ("returned: %f\n", readFloatVar());
return 0;
}
float readFloatVar(void) {
char *string = "22333.3324";
return atof(string);
}
.... and the omission of <stdlib.h> would have been obvious
to all. Indeed, in the process of whittling down you might
well have discovered the problem for yourself.
Now, these two pieces of advice may seem diametrically
opposed: I say that you lack the understanding to whittle
effectively, and then encourage you to do it. That's where
the "complete program" part comes in: Whittle a bit, run the
program, and see what it does. If it still misbehaves, whittle
some more and try again; you'll eventually arrive at a short
program that demonstrates your essential problem unencumbered
by off-topic distractions. If at some point the program stops
misbehaving, you'll know that the problem had something to do
with the material most recently removed, and this clue may well
enable you to solve the mystery for yourself -- even if it
doesn't, adding the valuable clue to your question may help
someone else solve it for you.
If you're going to be a programmer, you need to practice
the skill of asking good questions. The process of debugging
is a process of forming and answering questions; if you learn
to ask good questions you'll be much more successful.
Oh, and another hint for success: Learn how to crank up
your compiler's warning levels. Many compilers, if properly
asked, would have pointed out your probably error quite
clearly.
--
Er*********@sun.com