Too bad for Visual Studio then. Statements that have no effect are normally quite bad.Originally Posted by Elysia
But then this "fix" isn't really portable.
Too bad for Visual Studio then. Statements that have no effect are normally quite bad.
But then this "fix" isn't really portable.
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
Are not. The compiler will ignore them anyway.
And it's a great way to remove the "unreferenced" warning.
I think it's a good thing.
That's the point. In most contexts you do not write a code to be ignored by the compiler. So when such a code is encountered - it is very likely to be an errorThe compiler will ignore them anyway
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
Ah yes, but they do work fine for things such as suppressing warnings, if the compiler supports it. I think it is a good feature, anyway.
I'm using following macro for unused function argumants - but I do not know if some compiler
will complain
(unused local vars I just remove or place inside proper #ifdefs)
Code:#define UNUSED_ARG(_arg) if (_arg) {}
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
Wouldn't it be quite easy to do this?
Code:void foo(int , int y) //first argument is unused { //use y }
Last edited by anon; 03-13-2008 at 12:10 PM.
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
Yep, that's what I do for function arguments.
I write mostly in C
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
I'll give you another example:
I encountered some 3rd party code similar to this. Since they use the ASSERT() macro, num is used in Debug mode but not in Release mode. God only knows what the point is of this, but I didn't write it and I don't want to risk breaking anything, so the only ways of silencing the warning about unused parameter is either use a #pragma, or add num; to make the compiler shut up.Code:void func( char* str, int num ) { ASSERT( num < 50 ); ... // num isn't used anywhere else. }
#pragma statements (and warning numbers/messages) are different between compilers, so I chose num; instead.
>Statements that have no effect are normally quite bad.
Agreed.
To do VC++ justice, it seems that only expressions of type p; don't cause a warning. If there's an operator or such thrown into the mix, you get the "effectless statement" warning (e.g a + b; ).
I could still imagine such a situation where a warning might draw attention to a problem:
Code://global int c; void foo() { int a, b; c; //one semicolon by mistake ... }
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
I don't think I've ever done such a mistake...
But then, if you tried to use c, you'd get an undeclared warning and it should be pretty obvious then that you have done a mistake there...
I think I have made such mistakes (semicolon instead of comma), and in this example there is a global int c. Meaning the whole function will use this, instead of a local c that was supposed to shadow it.
It is a contrived example, though...
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
