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(scanin) ;

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

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

 

[Alf P. Steinbach]

* Sameer:

#include <iostream.h>

This is not a standard header; it's not available with all compilers.

Instead, use standard

#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" ;

When using standard <iostream>, you'll need to write std::cout here
(or, likely to lead to bugs, have a 'using' declaration somewhere).

cin >> scanin ;
while(scanin != 'Z')
{
range = high-low ;

low = low + range * low_range(scanin) ;

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

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

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

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

int low_range(char symbol)
{
if(strcmp(symbol,"B")==0) //This is the line which gives error

You're comparing a 'char' with a pointer to char.

Possibly you meant

if( symbol == 'B' )

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

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

}

Here you lack a 'return' statement to provide the function's result
value.

 

[Gianni Mariani]

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.

You're comparing a C string (array of char) with a char.

int low_range(char symbol)
{
if(strcmp(symbol,"B")==0) //This is the line

try:
if ( 'B' == symbol )

BTW - I'm not sure what your code is supposed to do so I'm not sure that
this is the intent of your code.

 

[Shark]

#include <string.h>

these headers are deprecated. You should #include <iostream> and

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.

cin >> scanin ;
while(scanin != 'Z')
{
range = high-low ;

low = low + range * low_range(scanin) ;

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

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

Yes. basically you are trying to compare symbol which is of type char
to "B" which is a c-string. The signature of strcmp is:
int strcmp ( const char * string1, const char * string2 ); //uses two
c-style strings

The compiler wants the first argument to be of type const char*, but
the first argument you are giving it is a char. So the compiler says:
duh! you gave me a char but I need a const char*! ERROR!!!

Basically when you pass arguments to functions, the C++ compiler wants
to make sure that they are of the same type as the parameters. If they
are not, it calls the copy constructor "implicitly" (look it up,
although I may be wrong). If the copy constructor fails to do its job,
there is no solution and thereupon the compiler spits out errors.

Also, to use strcmp you need to #include<cstring> as it is a
c-function, not C++
hope this helps.

 

[Gavin Deane]

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

<iostream.h> is not deprecated. As far as C++ is concerned,
<iostream.h> does not exist. You are correct though that the OP wants
<iostream> instead.

But the OP's use of <string.h> is entirely correct. They are using
strcmp from the C string library which is declared in <string.h>.
<string> is the header for std::string which is completely different.
You could argue that the OP should prefer <cstring> to the deprecated
<string.h> but unfortunately I believe that many compilers do not
implement the contents of <cxxx> headers correctly so you might as well
stick with <xxx.h>

Gavin Deane

 

[Shark]

<iostream.h> is not deprecated. As far as C++ is concerned,
<iostream.h> does not exist. You are correct though that the OP wants
<iostream> instead.

Yes you are correct.

But code that includes iostream.h compiles none the less and these
headers are usually marked "deprecated" on gnu systems....so I thought
I'd use that word.

But the OP's use of <string.h> is entirely correct. They are using
strcmp from the C string library which is declared in <string.h>.
<string> is the header for std::string which is completely different.
You could argue that the OP should prefer <cstring> to the deprecated
<string.h> but unfortunately I believe that many compilers do not
implement the contents of <cxxx> headers correctly so you might as well
stick with <xxx.h>

hahaha. Well, I was looking at <string.h> right by <iostream.h>, so you
can't blame me for screwing up the context!

 

[Ian Collins]

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.

What's "Plz" ?

strcmp takes a const char* as its first parameter, you a passing a char.

Why not just use symbol == 'B'?

Ian

 

[Alf P. Steinbach]

* Shark:

But code that includes iostream.h compiles none the less

With some compilers.

 

[Shark]

* Shark:

With some compilers.

yea, but "most" of those "some" compilers are used to compile "most" of
the code. gcc & vc
(ok, hasty generalization on my part)

iostream.h and like will linger on for some time.

 

[Alf P. Steinbach]

* Shark:

yea, but "most" of those "some" compilers are used to compile "most" of
the code. gcc & vc

Note that modern versions of the vc compiler, from version 7.0 and
onwards (I think it was), do not provide <iostream.h>.

 

[Bo Persson]

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.


Bo Persson

 

[WittyGuy]

* Sameer:

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.

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:

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 responsibilities, 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.

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 responsibilities. 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.programming].

 

[roberts.noah]

these headers are deprecated. You should #include <iostream> and


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.