• Marc (unregistered) in reply to poochner

    oh crap, do everyone a favor and look into your compiler manual.

    there's an actual need for unused parameters in C ocasionally. especialy when you start throwing around function pointers and you need all the functions to have the same signature (like the interupt vector table.

    #pragma unused(a) works with some compilers, variations of taht work on others.

  • Jens (unregistered) in reply to themagni
    Other times, you'll get a "condition always true" error for your superloop:

    do{

    //most of your code lives here

    }while(true);

    Why would yo do that, you ask? You'd do that on an embedded chip without an RTOS.

    Put comments on the line so you remember why you're accepting the warning and so the next guy knows that he should spend no time trying to "solve" the warning. And whatever you do, don't turn off the warnings for those lines. I've seen people do that, and I think that's insane.

    Wouldn't a better (and warning-free) solution be:

    #define ever ;; for(ever){ // Code goes here }

  • (cs)

    Warnings are good, Warning messages would stop this WTF from ever existing.

    Also QString from what I can understand, is a class from the Qt library (cross platform libray). QString reference

  • (cs) in reply to Cthulhu
    Cthulhu:
    Kozak:
    I hope he's being sarcastic when he bashes -Wall... We actually do use it and find it very useful... The annoying thing is when people start using -Wall -Werror...

    The real WTF is that the -Wall option doesn't always work with Visual Studio 2005. I just tried compiling a vb.net AND a c# application with -Wall for example and neither of them got added to the windows firewall list. Then again I am running norton antivirus too, so who knows.

    aaahhhh, thats classic

  • Fudor (unregistered) in reply to poochner

    a;

    does the trick. At least with VS2003.

    We use it all the time when providing default implementation of some interface. We don't necessarly use all the parameters in that implementation, but they are there for a reason and some other implementation of this interface will use them.

  • Tom (unregistered) in reply to pjf

    It seems like in the modern world with classes and overloading, (x)=(x) isn't a good idea, because it can have side effects. Suppose X is a string - there's no way the compiler could know it doesn't have to do that. And I bet a fair number of classes have bugs where x=x would cause a segfault, because they delete their own data, then copy the other object's (now just-deleted) data.

    So either cast to void (which I guess could still have side effects, but who would overload that cast in practice?), or just don't give the argument a name. (e.g. f(int x, int /* unused */) { ... }

  • RogerWilco (unregistered) in reply to speaking of wtf's

    You should try the World of Warcraft forums...

    Oh, and I only consider a piece of code correct if it has no warnings, if only because it gets harder to detect real problems if you have a lot of warnings. Going from 0 to 1 warning is a lot easier to notice as going from 300 to 301.

  • Joce (unregistered) in reply to Marc
    Marc:
    oh crap, do everyone a favor and look into your compiler manual.

    there's an actual need for unused parameters in C ocasionally. especialy when you start throwing around function pointers and you need all the functions to have the same signature (like the interupt vector table.

    #pragma unused(a) works with some compilers, variations of taht work on others.

    I thought you could just declare them without a name, eg.

    void func1(int n) { // Warning, "n" not used }

    void func2(int) { // No warnings }

  • totolamoto (unregistered) in reply to themagni 
    do{

    //most of your code lives here
    

    }while(true);

    for(;;) {
//
}

    is better, it doesn't generate warnings on most compilers.

  • (cs) in reply to KattMan
    KattMan:
    ailivac:
    Actually, the joke is the opposite of this story.

    A programmer is smoking a cigarette, and his friend says to him "Why are you doing that? Didn't you see the warning on the package that says those can cause cancer?"

    The programer replies "I only care about errors, not warnings."

    Back when I smoked, I always smoked the ones that warned about low birth weight, ect. Seeing as how I am male that didn't concern me. Now the ones that warned about cancer and such I stayed away from.

    I had a roommate in college that smoked, and his favorite warning was about the smoke being harmful to non-smokers. His answer was "It's a good thing I'm not a non-smoker".

  • Kevin Kofler (unregistered)

    I call BS on this CodeSOD. While the code is obviously wrong, I don't believe you that it will actually cause any conforming C++ compiler to warn. QString is a class type, thus a variable of type QString is always initialized, in this case, it's initialized with the default constructor, which constructs a null QString (the same thing you'd get by copying QString::null, it's a QString which satisfies both isNull and isEmpty, a null QString is always empty, an empty QString is not always null). Thus, this code silently returns an empty string, with no warning whatsoever. I can only assume the original snippet was different than what was posted, maybe the variable was a char * or something rather than a QString?

  • Sam (unregistered) in reply to Kevin Kofler

    Kevin, did it occur to you that perhaps the warning was about the actual unused variable ipv4Addr?

    CAPTCHA: Prove that you're a robot. Type in the word you see in the image without misspelling it.

  • Kevin Kofler (unregistered)

    Oh, you have a good point there. ;-)

  • (cs) in reply to Bogglestone
    Bogglestone:
    MET:
    In the original post I was wondering what 'dns' stood for. How about

    Does Nothing Surprisingly

    Dummy New String

    Doesn't Need Specifying?

  • Seth Morris (unregistered)

    Wait, the real warning here is an unnecessary named variable!

    QString HostAddress::dns () const { Q_UINT32 ipv4Addr = getIpv4Address(); return QString(); }

    Anonymous rules!

    ...

    Oh, wait. That's in lisp. In real languages, it doesn't....

  • Anonymous (unregistered) in reply to ZSB
    ZSB:
    rien:
    i actually found the same kind of stuff in some embedded system code. the way to avoid the compiler warning was just 'different': 
    int doSomeStuff( int a, int b, int c )
{
    int result;

    a = a;
    b = b;
    c = c;

    // do some complex computation that does not involve any of the 3 variables and store the result

    return result;
}

    i loved the way they declared parameters, did not use them at all but obviously fixed the compiler warning instead of just removing the parameters. in the system involved, removing those unused parameters would have been no problem at all...

    I'll tell you maybe why they didn't remove the parameters: to do so they'd have to go and modify all the places that called that function.

    Why? Just change the function definition to

    int doSomeStuff( int /*a*/, int /*b*/, int /*c*/ )
{
    int result;

    // do some complex computation that does not involve any of the 3 variables and store the result

    return result;
}

    and you'll get rid of the unused parameter warning WITHOUT the need to change the rest of your code. And you won't leave the maintainers of your code scratching their heads for hours trying to figure out why you wrote "a=a;" etc. there.

    If the functions signature doesn't change, there is no need to change anything in the caller. Callers are still required to call this function with 3 parameters of type 'int'.

    ZSB:
    Some of those places fixed then might result in their *own* unused parameter variable warnings that need to have fixes propagated.
    It won't happen. The caller still calls the function with 
    doSomeStuff(p,q,r);
    Still the same call. Since these 3 parameters are considered used (because they're used as argument in some function call), the compiler won't complain that p/q/r is unused.
    ZSB:
    So a quick low-risk change to one function in one file to remove an annoying warning now becomes a multi-file odyssey with correspondingly higher risks and test requirements.
    It's a quick no-risk change. The only risk is you: you don't understand how to change it in a correct way. So, you're going to introduce the risks of changing a large bunch of code lines sprinkled around many files UNNECESSARILY!
    ZSB:
    I got clobbered once in a similar way: I needed to change a few high level functions to use const for certain parameters that they don't/shouldn't change, but then I was obligated to make similar fixes to dozens of lower level functions as the const-ness needed to propagate down the call chain (all of which legacy code was not const-correct).
    const-ness has to be planned ahead very carefuly and skillfully. Adding 'const' as an afterthough can easily break working code.
  • Anonymous (unregistered) in reply to SwEng
    SwEng:
    Other times, you'll get a "condition always true" error for your superloop:
    To avoid that, use for(;;). This idiom often used to be #defined as FOREVER, but is clear enough by itself. HTH+HAND.

    I can't agree more. Maybe, compiler writers should start considering including suggestions in the warning messages, so that those clueless people can learn the correct way to code.

    e.g.

    foo.c:15: (Warning) condition always true
          consider replacing the loop with a for(;;) loop, i.e.
          replace do {...} while (<the suspicious expression>);
          with    for (;;) {...}
  • pavel (unregistered) in reply to poochner

    Btw, the correct way to do it would be:

    int doSomeStuff( int, int, int) { }

    p.

  • dlrvwidr (unregistered) in reply to vt_mruhlin

    trrhrzkm http://qltzugvv.com bkgbtewc cwhxfyap

Leave a comment on “Another Brick in the Wall ”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article