doubt in strcmp

Discussion in 'C++' started by Sameer, Jan 19, 2006.

  1. Sameer

    Sameer Guest

    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 ;
    }
     
    Sameer, Jan 19, 2006
    #1
    1. Advertising

  2. * Sameer:
    >
    > #include <iostream.h>


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

    Instead, use standard

    #include <iostream>


    > #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.

    --
    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?
     
    Alf P. Steinbach, Jan 19, 2006
    #2
    1. Advertising

  3. Sameer wrote:
    > 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.
     
    Gianni Mariani, Jan 19, 2006
    #3
  4. Sameer

    Shark Guest

    > #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.

    > 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.
     
    Shark, Jan 19, 2006
    #4
  5. Sameer

    Gavin Deane Guest

    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


    <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
     
    Gavin Deane, Jan 19, 2006
    #5
  6. Sameer

    Shark Guest

    Gavin Deane wrote:
    > 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

    >
    > <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. :D

    > 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!
     
    Shark, Jan 19, 2006
    #6
  7. Sameer

    Ian Collins Guest

    Sameer wrote:
    > 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

    --
    Ian Collins.
     
    Ian Collins, Jan 19, 2006
    #7
  8. * Shark:
    >
    > But code that includes iostream.h compiles none the less :)


    With some compilers.

    --
    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?
     
    Alf P. Steinbach, Jan 19, 2006
    #8
  9. Sameer

    Shark Guest

    Alf P. Steinbach wrote:
    > * Shark:
    > >
    > > But code that includes iostream.h compiles none the less :)

    >
    > With some compilers.


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

    iostream.h and like will linger on for some time.
     
    Shark, Jan 19, 2006
    #9
  10. * Shark:
    > Alf P. Steinbach wrote:
    > > * Shark:
    > > >
    > > > But code that includes iostream.h compiles none the less :)

    > >
    > > With some compilers.

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

    --
    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?
     
    Alf P. Steinbach, Jan 19, 2006
    #10
  11. Sameer

    Bo Persson Guest

    "Shark" <> skrev i meddelandet
    news:...
    >>
    >> 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
     
    Bo Persson, Jan 19, 2006
    #11
  12. Sameer

    WittyGuy Guest

    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-
     
    WittyGuy, Jan 20, 2006
    #12
  13. Why one should generally avoid certain language features (was: doubt in strcmp)

    * 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 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.


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

    --
    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?
     
    Alf P. Steinbach, Jan 20, 2006
    #13
  14. Sameer

    Guest

    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.
     
    , Jan 20, 2006
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Shane Peck

    strcmp problem

    Shane Peck, Sep 19, 2003, in forum: C++
    Replies:
    6
    Views:
    2,359
    Kevin Goodsell
    Sep 22, 2003
  2. Bob Nelson

    doubt about doubt

    Bob Nelson, Jul 28, 2006, in forum: C Programming
    Replies:
    11
    Views:
    629
  3. Replies:
    0
    Views:
    566
  4. Peter Otten
    Replies:
    2
    Views:
    119
    Cousin Stanley
    Aug 10, 2013
  5. Terry Reedy
    Replies:
    0
    Views:
    120
    Terry Reedy
    Aug 10, 2013
Loading...

Share This Page