doubt in strcmp

[Sameer]

Hi friends,
I am beginner in C++. I am using g++ compiler. below is my code
which gives error as " invlid conversion from 'char' to 'const char*'
..Plz help me with this.

#include <iostream.h>
#include <string.h>
int low_range(char symbol) ;

int main(int argc, char **argv)
{
char scanin ;
float range ;

float low = 0.0 ;
float high = 1.0 ;

cout << "Enter symbol\t" ;
cin >> scanin ;
while(scanin != 'Z')
{
range = high-low ;

low = low + range * low_range(scani n) ;

cout << "Value\t" ;
cin >> scanin ;

}
cout << low << endl ;
}
int rng ;
int low_range(char symbol)
{
if(strcmp(symbo l,"B")==0) //This is the line
which gives error
rng = 0.2 ;
cout << "Low range\t" << rng << endl ;
}

[Bo Persson]

"Shark" <cp*******@yaho o.com> skrev i meddelandet
news:11******** *************@g 49g2000cwa.goog legroups.com...

int main(int argc, char **argv)
{
char scanin ;
float range ;

float low = 0.0 ;
float high = 1.0 ;

cout << "Enter symbol\t" ;
small issue here: you should use std::endl instead of \t to flush
the
output stream.

On the other hand, std::cin is by default tie()'d to std::cout, so it
will do this automagically anyway.

cin >> scanin ;

Bo Persson

[WittyGuy]

Alf P. Steinbach wrote:

* Sameer:

cout << "Value\t" ;
cin >> scanin ;

}
cout << low << endl ;
}
int rng ;
Don't use global variables, especially not uninitialized ones.

Could you please provide the reason for the above statement?
It seems that this was really meant as a local variable in the function
below.

rng = 0.2 ;
cout << "Low range\t" << rng << endl ;

Don't do output in a function that computes something.

Why shouldn't we? What might be the ill-effect of doing so?

thanks,
--Wg-

[Alf P. Steinbach]

* WittyGuy:

* Alf P. Steinbach:

* Sameer:

cout << "Value\t" ;
cin >> scanin ;

}
cout << low << endl ;
}
int rng ;

Don't use global variables, especially not uninitialized ones.

Could you please provide the reason for the above statement?

There is a conundrum. For the newbie, who most of all needs to avoid
global variables, nearly at any cost, the reasons (note: plural) to
avoid them are extremely hard to fathom. On the other hand, experienced
programmers who are able to understand the reasons usually do understand
them and are already avoiding use of globals, and need no explanation.

And we, or at least I, fear that most newbies who ask about this or ask
similar questions of a general nature will strenously object to any
reasons offered. It's the same as with use of 'goto'. Or any other
feature that is technically OK, and exists for very good reasons, but is
disastrous as general practice -- only meant for very special things.

Thirdly, it's not a question that's very much specific to C++; it
applies to any programming language, and so is mostly off-topic in
[comp.lang.c++].

So in explaining this we often resort to the old authority argument,
which is a fallacy; or we vaguely indicate that globals will rise up and
bite you in an area in front of your behind, at every opportunity,
without mentioning much how globals are able to do these gymnastic feats
(this is the approach of the FAQ, see the end of FAQ item 39.8 about
for-loop scoping rules, and also my approach above); or we keep silent.

However, having said A, I feel obliged to say B, when that B is asked
for, so, first about global variables in general, which you should not
think of as an exhaustive list, just what bubbled to the surface of my
mind first:

* Global variables are accessible from anywhere, which means you can't
rely on a global variable having the value you just put there, and
means you can generally have a hard time tracking down where a value
came from. And which means unclear responsibilitie s, in general.
All that in turn means hard to understand code, and it means bugs,
and it means hard to debug.

* Global variables are not thread-safe.

* Global variables are not even recursion-safe (an important special
case of the first point).

* Global variables in C++ are not exception safe, in the sense that
there's no portable way to catch an exception arising from the
initialization of a global variable.

* Global variables in C++ are not initialization-order safe; it's
possible to use a global variable before it's been initialized, even
when that global is declared with an initializer.

* Global variables lead to name clashes and inadvertent usage.

* Global variables may constrain your code to a single object or call
chain, which typically surfaces as an unsurmountable problem long
after you have written thousands of lines of code depending on the
global-variable-based code.

And so on.

Oh, I forgot, my comment about "especially not uninitialized ones".

Using an uninitialized variable is Undefined Behavior in C++, but that
does not apply directly to a global variable, because a global variable
with no initializer is zero-initialized. So except for the
initialization unsafety of globals (possible use before initialization)
there's not really such a thing as an uninitialized global. What my
comment referred to was lack of _explicit_ initialization.

Often that means that some function is supposed to be called before that
global is otherwise used, where that function will do the
initialization.

Tracking down which function that is can be hard; ensuring that the
global is not used before that function is called can be hard; and
ensuring that that function is actually called, only once, at the proper
time and in proper sequence with other functions, especially other such
functions, can be hard -- it's very unnecessary complexity.

It seems that this was really meant as a local variable in the function
below.

rng = 0.2 ;
cout << "Low range\t" << rng << endl ;

Don't do output in a function that computes something.

Why shouldn't we? What might be the ill-effect of doing so?

Effects, plural. First and foremost, consider making a GUI (window)
version of the program. Can that function be used unchanged?

Secondly, consider reuse in general: can that function be reused
somewhere (even within the same program) where that exact output, or any
output, is undesired?

Third, consider the effect on data flow, and thus design. Data is
passed down into functions, but results never come back up: they're just
displayed. That leads to very control-flow oriented design, with an
all-important main function somewhere coordinating it all, taking on
more and more responsibilitie s. Which is incompatible with OO and is a
well known anti-pattern, known as "the blob" or "the octopus", IIRC.

Note again, that this is not very C++-specific, and so is largely
off-topic in [comp.lang.c++].

Follow-ups therefore set to [comp.programmin g].

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[roberts.noah]

Shark wrote:

#include <iostream.h>
#include <string.h>

these headers are deprecated. You should #include <iostream> and
#include<string > instead of the ones you have

int low_range(char symbol) ;

int main(int argc, char **argv)
{
char scanin ;
float range ;

float low = 0.0 ;
float high = 1.0 ;

cout << "Enter symbol\t" ;

small issue here: you should use std::endl instead of \t to flush the
output stream.

Nitpick: std::endl and \t will result in totally different output. You
can't use std::endl in place of \t. If you need a flush at this point
use flush.

I believe you expected to see \n.