compile warning question..

[b][red]This message was edited by PAG at 2002-11-21 17:18:33[/red][/b][hr]
This just struck my mind today, how serious should one take on compiler warnings? I mean sometimes i get "suspicious pointer" warning or "#varnam is never used in function #functionname", or "functions containing for are not expanded inline"...

Do I need to make changes so the warnings disappear?
I usually dont make any changes as long as my program works the way it should.


Comments

  • : This just struck my mind today, how serious should one take on compiler warnings? I mean sometimes i get "suspicious pointer" warning

    A "suspicious pointer" warning should not be ignored. Something is broken, and it needs fixing.


    : or "#varnam is never used in function #functionname",

    If you aren't using it, why not get rid of it? I can't think of any advantages here, but I can think of a few disadvantages.


    : or "functions containing for are not expanded inline"...

    If you already know this, then shutting this *one* off might not be a bad idea.



    : Do I need to make changes so the warnings disappear?

    Yes, fix your code.


    : I usually dont make any changes as long as my program works the way it should.

    "If it ain't broke, don't fix it" is certainly appropriate in alot of cases. However, it's hard to tell if something is actually broken, and just limping along, in software. Undefined behavior has a nasty habit of staying quiet until you are demonstrating your software in front of your boss, or worse, your customer.

    I remember a story about a compiler writer that had accidentally forgotten to close a comment in the source code, and the comment didn't get closed until the next comment down (i.e. the next "*/"). Unfortunately, the code that never made it was a call to the hashing function for looking up symbols in the symbol table. Compiles on short programs weren't too bad, but compiles on large programs took forever. Everything still "worked" (gave the correct result), but not really the "way it should". Those are two different things, and programmers are notorious for getting it wrong. Ever notice a compiler that warns about a "/*" in a comment? That compiler writer sure could have used that one huh?


    HTH,
    Will
    --
    http://www.tuxedo.org/~esr/faqs/smart-questions.html
    http://www.eskimo.com/~scs/C-faq/top.html
    http://www.parashift.com/c++-faq-lite/
    http://www.accu.org/


  • [b][red]This message was edited by Darius at 2002-11-21 19:49:21[/red][/b][hr]
    : : This just struck my mind today, how serious should one take on compiler warnings? I mean sometimes i get "suspicious pointer" warning
    :
    : A "suspicious pointer" warning should not be ignored. Something is broken, and it needs fixing.
    :
    :
    : : or "#varnam is never used in function #functionname",
    :
    : If you aren't using it, why not get rid of it? I can't think of any advantages here, but I can think of a few disadvantages.
    :
    :
    : : or "functions containing for are not expanded inline"...
    :
    : If you already know this, then shutting this *one* off might not be a bad idea.
    :
    :
    :
    : : Do I need to make changes so the warnings disappear?
    :
    : Yes, fix your code.
    :
    :
    : : I usually dont make any changes as long as my program works the way it should.
    :
    : "If it ain't broke, don't fix it" is certainly appropriate in alot of cases. However, it's hard to tell if something is actually broken, and just limping along, in software. Undefined behavior has a nasty habit of staying quiet until you are demonstrating your software in front of your boss, or worse, your customer.
    :
    : I remember a story about a compiler writer that had accidentally forgotten to close a comment in the source code, and the comment didn't get closed until the next comment down (i.e. the next "*/"). Unfortunately, the code that never made it was a call to the hashing function for looking up symbols in the symbol table. Compiles on short programs weren't too bad, but compiles on large programs took forever. Everything still "worked" (gave the correct result), but not really the "way it should". Those are two different things, and programmers are notorious for getting it wrong. Ever notice a compiler that warns about a "/*" in a comment? That compiler writer sure could have used that one huh?
    :
    :
    : HTH,
    : Will
    : --
    : http://www.tuxedo.org/~esr/faqs/smart-questions.html
    : http://www.eskimo.com/~scs/C-faq/top.html
    : http://www.parashift.com/c++-faq-lite/
    : http://www.accu.org/
    :
    :
    :

    How about this as a guideline:

    If you don't know WHY you are getting a warning, then something is broken (perhaps you'll learn the why and find out that, nope it really was alright, until then your code is not what you intended which can't be a good thing). If you know why, then you probably can and should fix it or address it in some way, however there are times when that's not reasonably possible.

    A warning: you need to REALLY UNDERSTAND WHY. Not, the compiler is giving me a 'non-const member function call on a const object', I can "fix" it with a const_cast<>. (That's actually a warning in Borland 5.6! W8037)

    Many people are of the mind that warnings are equivalent to errors. Obviously, you can't go wrong with that belief except by believing that no warnings/errors == correct program, i.e. false security. However, that is just a little bit more extreme than necessary.

    Back to GotW.

    "We can't do nothing and think someone else will make it right."
    -Kyoto Now, Bad Religion



  • : : : This just struck my mind today, how serious should one take on compiler warnings?



    : How about this as a guideline:
    :
    : If you don't know WHY you are getting a warning, then something is broken (perhaps you'll learn the why and find out that, nope it really was alright, until then your code is not what you intended which can't be a good thing). If you know why, then you probably can and should fix it or address it in some way, however there are times when that's not reasonably possible.

    Nicely put.


    : A warning: you need to REALLY UNDERSTAND WHY. Not, the compiler is giving me a 'non-const member function call on a const object', I can "fix" it with a const_cast<>. (That's actually a warning in Borland 5.6! W8037)

    How true, and depressing. Too often, casts are the first thing done to quiet warnings. Unfortunately, they are usually just as wrong as the code was in the first place.


    : Many people are of the mind that warnings are equivalent to errors. Obviously, you can't go wrong with that belief except by believing that no warnings/errors == correct program, i.e. false security. However, that is just a little bit more extreme than necessary.

    Quite true. I always get the warnings for "assignment in controlling expression" or similar. I can live with that one. :)


    : Back to GotW.

    Oooooh, I'm jealous! :)


    Will
    --
    http://www.tuxedo.org/~esr/faqs/smart-questions.html
    http://www.eskimo.com/~scs/C-faq/top.html
    http://www.parashift.com/c++-faq-lite/
    http://www.accu.org/


  • Hey guys! I just read both of your posts and they were really good. I do have another question about Warnings though.

    When I was taking my Intermediate C++ class, the teacher told us in quite a few lectures that we should expect to see some warnings when we got into some higher level of coding. His advice to us was to simply compile it in Release mode vs. Debug mode and when we did that, the warnings would disappear. Low and behold, he was right.

    Just curious of your opinions on that solution. Thanks!

    : : : : This just struck my mind today, how serious should one take on compiler warnings?
    :
    :
    :
    : : How about this as a guideline:
    : :
    : : If you don't know WHY you are getting a warning, then something is broken (perhaps you'll learn the why and find out that, nope it really was alright, until then your code is not what you intended which can't be a good thing). If you know why, then you probably can and should fix it or address it in some way, however there are times when that's not reasonably possible.
    :
    : Nicely put.
    :
    :
    : : A warning: you need to REALLY UNDERSTAND WHY. Not, the compiler is giving me a 'non-const member function call on a const object', I can "fix" it with a const_cast<>. (That's actually a warning in Borland 5.6! W8037)
    :
    : How true, and depressing. Too often, casts are the first thing done to quiet warnings. Unfortunately, they are usually just as wrong as the code was in the first place.
    :
    :
    : : Many people are of the mind that warnings are equivalent to errors. Obviously, you can't go wrong with that belief except by believing that no warnings/errors == correct program, i.e. false security. However, that is just a little bit more extreme than necessary.
    :
    : Quite true. I always get the warnings for "assignment in controlling expression" or similar. I can live with that one. :)
    :
    :
    : : Back to GotW.
    :
    : Oooooh, I'm jealous! :)
    :
    :
    : Will
    : --
    : http://www.tuxedo.org/~esr/faqs/smart-questions.html
    : http://www.eskimo.com/~scs/C-faq/top.html
    : http://www.parashift.com/c++-faq-lite/
    : http://www.accu.org/
    :
    :
    :

  • : Hey guys! I just read both of your posts and they were really good.

    Thanks, it's just one of my good days. ;)


    : I do have another question about Warnings though.
    :
    : When I was taking my Intermediate C++ class, the teacher told us in quite a few lectures that we should expect to see some warnings when we got into some higher level of coding. His advice to us was to simply compile it in Release mode vs. Debug mode and when we did that, the warnings would disappear. Low and behold, he was right.
    :
    : Just curious of your opinions on that solution. Thanks!

    IIRC, MS Visual C++ has a warning if an identifier name was truncated in the debugging information. Sometimes, the *actual* name of something is huge in C++. If this is the warning you are speaking of, then your teacher was right, this "Release mode" doesn't create debugging info. I can't say for sure, because I simply don't have much experience with that compiler, but I seem to recall this when I have used it. Perhaps a MSVC++ guru can enlighten the both of us.


    HTH,
    Will
    --
    http://www.tuxedo.org/~esr/faqs/smart-questions.html
    http://www.eskimo.com/~scs/C-faq/top.html
    http://www.parashift.com/c++-faq-lite/
    http://www.accu.org/


Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories