type conversion from char** argv

[neos]

I have this code, it finds x ^ y. I want to pass two floating point vars at the command line, so I used char** argv and then tried to convert the argv[1] and argv[2] to a float, but I get the error "pointer value used where a floating point value was expected." how do i convert properly.

#include <iostream>
#include <math.h>
#include <stdlib.h>

int main(int argc, char** argv) {
float x, y;
if(argc != 3) {
cout << &quot;Usage: pow x y\n&quot;;
}
else {
x = float(argv[1]);
y = float(argv[2]);
cout << pow(x, y) << &quot;\n&quot;;
}
system(&quot;PAUSE&quot;
return 0;
} shaun

 

[mingis]

As an oldtimer I would use
sscanf(argv[1], &quot;%f&quot;, &x);
instead of
x = float(argv[1]);
because MSDN help does not give me any information about float().

 

[Zyrenthian]

The data is coming in a strings so what you need to do is

float x = atof(argv[1]);
float y = atof(argv[2]);

atof can be replaced with strtol or _tcstol if in Unicode.

Matt

 

[PerFnurt]

I would say atof can be replaced with strtol or wcstod if in Unicode. _t stuff is for ppl who don't know what their code is doing (and hence evil imho).

 

[Zyrenthian]

_tcstod for compatability in both. I know it oh to well
That was the one thing that annoyed me when we went japanese. There exists an _ttoa but no _ttof. I dont understand why. I compensated with the str function.

Matt

 

[Pyramus]

laff at perfnurt- interesting view you've got there.

 

[Zyrenthian]

And no, im not evil . The _t stuff saves us from doing things like

#ifdef UNICODE
// convert wide
#else
// convert single byte
#endif

I dont think anyone understands how useful the _t functions are until they start programing in another language that requires Unicode. The _t functions give you the ability to build with and without unicode and have your code work. There are plenty of steps that need to be taken (as you can see in my faq) but for me, the _t macros have been a time saver. If that makes me evil, I say MUHAHAHAHAHAHA

Matt

 

[PerFnurt]

Ahem, I dint find YOU evil, but rather _t thingie.
Well, perhaps not evil, but Bad(tm) anyway. ;-)

Yes, of course I do realize the benefit of _t stuff when you support both chartypes or is in transition from one (not-unicode) to another (unicode). But once you over that phase...

For me and I doubt Im really that odd, but I might be (), I usually know what platform I'm coding for (NT/2000/XP).

When I _know_ it's UNICODE I find it silly to obfuscate the code by using works-in-non-unicode stuff.

I might be unusual in this, perhaps all you out there support unicode as well as not-unicode versions of your stuff.

If so just regard my comment as a freak's opinion (as if you didn't already ).

 

[Zyrenthian]

I agree the _T macro, _t related functions etc get to be a real pain. Eschew Obfuscation! I agree completely, however in our case, we had no choice. Some of our applications that use shared dlls are not configured to work in unicode. They dont have a unicode build config so by selecting the regular build of Release or Debug, we can still build em. I think that is the real benefit of the _t stuff. I agree 100% that if all code is unicode compliant, the use of _t functions is a waste of time and the _w functions should be used instead. Of course you can disregard this reply as a freak's reply to a freak's opinion.

If we start quoting Rick James, this post has gone too far (-:

Matt