Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #15133 > unrolled thread

Need your experience: is "(void)param;" to avoid unused variable warnings well known for you?

Back to article view | Back to comp.lang.c++

Contents

  Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? Qi <no@no.com> - 2012-04-02 19:16 +0800
    Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? "Fred Zwarts \(KVI\)" <F.Zwarts@KVI.nl> - 2012-04-02 13:39 +0200
      Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? Victor Bazarov <v.bazarov@comcast.invalid> - 2012-04-02 09:49 -0400
        Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? Qi <no@no.com> - 2012-04-02 22:01 +0800
          Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? Victor Bazarov <v.bazarov@comcast.invalid> - 2012-04-02 11:50 -0400
          Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? Paul N <gw7rib@aol.com> - 2012-04-02 12:54 -0700
        Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? Juha Nieminen <nospam@thanks.invalid> - 2012-04-03 05:27 +0000
          Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-04-03 08:02 +0000
            Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? Juha Nieminen <nospam@thanks.invalid> - 2012-04-03 14:19 +0000
      Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? Mike McCarty <mcmccarty@gmail.com> - 2012-04-02 06:43 -0700
    Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? GM <GM@no.spam.it> - 2012-04-02 14:41 +0200
    Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? bartek szurgot <basz@no.spam> - 2012-04-02 16:55 +0200
      Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? Juha Nieminen <nospam@thanks.invalid> - 2012-04-03 05:28 +0000
        Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? Qi <no@no.com> - 2012-04-03 13:54 +0800
          Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? Juha Nieminen <nospam@thanks.invalid> - 2012-04-03 14:09 +0000
            Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? Robert Wessel <robertwessel2@yahoo.com> - 2012-04-03 11:21 -0500
              Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? bartek szurgot <basz@no.spam> - 2012-04-04 17:39 +0200
    Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-04-02 15:13 +0000
    Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? "MikeWhy" <boat042-nospam@yahoo.com> - 2012-04-02 11:37 -0500
      Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? Qi <no@no.com> - 2012-04-03 10:29 +0800
        Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-04-03 06:00 +0200
          Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? Qi <no@no.com> - 2012-04-03 13:56 +0800
    Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? goran.pusic@gmail.com - 2012-04-02 04:25 -0700
      Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? scott@slp53.sl.home (Scott Lurndal) - 2012-04-02 22:01 +0000
    Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? Öö Tiib <ootiib@hot.ee> - 2012-04-02 07:37 -0700
    Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? Dombo <dombo@disposable.invalid> - 2012-04-03 19:35 +0200
    Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? Stuart Redmann <DerTopper@web.de> - 2012-04-04 11:56 -0700
    Re: Need your experience: is "(void)param;" to avoid unused variable warnings well known for you? Qi <no@no.no> - 2012-04-05 14:17 +0800

Page 1 of 2  [1] 2  Next page →

#15133 — Need your experience: is "(void)param;" to avoid unused variable warnings well known for you?

Hi all,

Let me show some code first,

void someFunction(int param)
{
    (void)param; // param is not used in this function. This line is
// just to silence the compiler warning about unused param.
}

Please note the "(void)param".
Is that usage common or well known for you?
Or you rarely saw it? Or even it's weird to you?

Just your experience is enough, no need to debate for it's good
or bad. :-)

The reason I ask this is, in my another thread, some very veteran
C++ developers said they rarely saw that kind of usage.
That makes me a little nervous because I used it a lot in my
code to *improve* the code readability.
If it's not well known trick then it reduces code readability
and then I'm going to change my code about that.

That's not only about coding style but also about code readability.

Looking forward to hearing your experience.

Thanks


-- 
WQ

[toc] | [next] | [standalone]

#15135

"Qi"  wrote in message news:jlc1qv$kjj$2@speranza.aioe.org...
>
>Hi all,
>
>Let me show some code first,
>
>void someFunction(int param)
>{
>    (void)param; // param is not used in this function. This line is
>// just to silence the compiler warning about unused param.
>}
>
>Please note the "(void)param".
>Is that usage common or well known for you?
>Or you rarely saw it? Or even it's weird to you?
>
>Just your experience is enough, no need to debate for it's good
>or bad. :-)
>
>The reason I ask this is, in my another thread, some very veteran
>C++ developers said they rarely saw that kind of usage.
>That makes me a little nervous because I used it a lot in my
>code to *improve* the code readability.
>If it's not well known trick then it reduces code readability
>and then I'm going to change my code about that.
>
>That's not only about coding style but also about code readability.
>
>Looking forward to hearing your experience.
>
>Thanks

I have never seen this trick. Why don't you use the standard C++ way? Remove 
the name of the parameter and the compiler will stop complaining. Less code, 
better readability. The "(void)param" makes me wonder what the purpose is. 
You will need comments to explain why it is used. If the parameter name is 
omitted, it is immediately clear that it is not used in the function. No 
comments needed. For the reason why it is not used in the function, comments 
may be needed in both cases.

void someFunction(int)
{

//
} 

[toc] | [prev] | [next] | [standalone]

#15137

On 4/2/2012 7:39 AM, Fred Zwarts (KVI) wrote:
> "Qi" wrote in message news:jlc1qv$kjj$2@speranza.aioe.org...
>>
>> Hi all,
>>
>> Let me show some code first,
>>
>> void someFunction(int param)
>> {
>> (void)param; // param is not used in this function. This line is
>> // just to silence the compiler warning about unused param.
>> }
>>
>> Please note the "(void)param".
>> Is that usage common or well known for you?
>> Or you rarely saw it? Or even it's weird to you?
>>
>> Just your experience is enough, no need to debate for it's good
>> or bad. :-)
>>
>> The reason I ask this is, in my another thread, some very veteran
>> C++ developers said they rarely saw that kind of usage.
>> That makes me a little nervous because I used it a lot in my
>> code to *improve* the code readability.
>> If it's not well known trick then it reduces code readability
>> and then I'm going to change my code about that.
>>
>> That's not only about coding style but also about code readability.
>>
>> Looking forward to hearing your experience.
>>
>> Thanks
>
> I have never seen this trick. Why don't you use the standard C++ way?
> Remove the name of the parameter and the compiler will stop complaining.
> Less code, better readability. The "(void)param" makes me wonder what
> the purpose is. You will need comments to explain why it is used. If the
> parameter name is omitted, it is immediately clear that it is not used
> in the function. No comments needed. For the reason why it is not used
> in the function, comments may be needed in both cases.
>
> void someFunction(int)
> {
>
> //
> }

I've seen that trick usually used in (a) a larger function than just one 
empty line and one line of comment, and (b) in presence of some reason 
to keep the argument name, like alternative configurations 
(Debug/Release for instance):

    void someFunction(int argumentUsedOnlyInDebug)
    {
        ...  // some code
    #ifdef NDEBUG
        (void)argumentUsedOnlyInDebug;
    #else
        ... // some code that uses argumentUsedOnlyInDebug
    #endif
        ...  // more code
    }

Any suggestions for a better alternative?

V
-- 
I do not respond to top-posted replies, please don't ask

[toc] | [prev] | [next] | [standalone]

#15138

On 2012-4-2 21:49, Victor Bazarov wrote:
>
> I've seen that trick usually used in (a) a larger function than just one
> empty line and one line of comment, and (b) in presence of some reason
> to keep the argument name, like alternative configurations
> (Debug/Release for instance):

I don't understand (a).
Can you give some example code?

> void someFunction(int argumentUsedOnlyInDebug)
> {
> ... // some code
> #ifdef NDEBUG
> (void)argumentUsedOnlyInDebug;
> #else
> ... // some code that uses argumentUsedOnlyInDebug
> #endif
> ... // more code
> }
>
> Any suggestions for a better alternative?

I think one more readable way is using some marco?

#define UNUSED_ARG(arg) (void)arg

UNUSED_ARG(argumentUsedOnlyInDebug);

It's less confusing than
(void)argumentUsedOnlyInDebug;


-- 
WQ

[toc] | [prev] | [next] | [standalone]

#15142

On 4/2/2012 10:01 AM, Qi wrote:
> On 2012-4-2 21:49, Victor Bazarov wrote:
>>
>> I've seen that trick usually used in (a) a larger function than just one
>> empty line and one line of comment, and (b) in presence of some reason
>> to keep the argument name, like alternative configurations
>> (Debug/Release for instance):
>
> I don't understand (a).
> Can you give some example code?

*You* gave the example code.  In your code the function had effectively 
an empty body.  In that case there is no need to have "ignore" 
templates, "UNUSED_PARAMETER" macros, or any other BS.  Just drop the 
argument altogether.

I am talking any reasonable function that actually is supposed to do 
something.  The "code example" is below.

>
>> void someFunction(int argumentUsedOnlyInDebug)
>> {
>> ... // some code
>> #ifdef NDEBUG
>> (void)argumentUsedOnlyInDebug;
>> #else
>> ... // some code that uses argumentUsedOnlyInDebug
>> #endif
>> ... // more code
>> }
>>
>> Any suggestions for a better alternative?
>
> I think one more readable way is using some marco?
>
> #define UNUSED_ARG(arg) (void)arg
>
> UNUSED_ARG(argumentUsedOnlyInDebug);
>
> It's less confusing than
> (void)argumentUsedOnlyInDebug;

<shrug>  Same difference.

V
-- 
I do not respond to top-posted replies, please don't ask

[toc] | [prev] | [next] | [standalone]

#15184

On Apr 2, 3:01 pm, Qi <n...@no.com> wrote:
> On 2012-4-2 21:49, Victor Bazarov wrote:
>
>
>
> > I've seen that trick usually used in (a) a larger function than just one
> > empty line and one line of comment, and (b) in presence of some reason
> > to keep the argument name, like alternative configurations
> > (Debug/Release for instance):
>
> I don't understand (a).
> Can you give some example code?
>
> > void someFunction(int argumentUsedOnlyInDebug)
> > {
> > ... // some code
> > #ifdef NDEBUG
> > (void)argumentUsedOnlyInDebug;
> > #else
> > ... // some code that uses argumentUsedOnlyInDebug
> > #endif
> > ... // more code
> > }
>
> > Any suggestions for a better alternative?
>
> I think one more readable way is using some marco?
>
> #define UNUSED_ARG(arg) (void)arg
>
> UNUSED_ARG(argumentUsedOnlyInDebug);
>
> It's less confusing than
> (void)argumentUsedOnlyInDebug;

I'd be wary of code that said UNUSED_ARG(arg); and then went ahead to
use arg. Perhaps POSSIBLY_UNUSED_ARG(arg); would be better in this
situation?

[toc] | [prev] | [next] | [standalone]

#15192

Victor Bazarov <v.bazarov@comcast.invalid> wrote:
>    void someFunction(int argumentUsedOnlyInDebug)
>    {
>        ...  // some code
>    #ifdef NDEBUG
>        (void)argumentUsedOnlyInDebug;
>    #else
>        ... // some code that uses argumentUsedOnlyInDebug
>    #endif
>        ...  // more code
>    }
> 
> Any suggestions for a better alternative?

  Since the above situation is extremely rare, you could use the trick
in that specific situation (which in practice means almost never) and
add a clarifying comment to it.

  Btw, do compilers by convention not issue a warning about a no-op line
like that?

[toc] | [prev] | [next] | [standalone]

#15196

On Tue, 2012-04-03, Juha Nieminen wrote:
> Victor Bazarov <v.bazarov@comcast.invalid> wrote:
>>    void someFunction(int argumentUsedOnlyInDebug)
>>    {
>>        ...  // some code
>>    #ifdef NDEBUG
>>        (void)argumentUsedOnlyInDebug;
>>    #else
>>        ... // some code that uses argumentUsedOnlyInDebug
>>    #endif
>>        ...  // more code
>>    }
>> 
>> Any suggestions for a better alternative?
>
>   Since the above situation is extremely rare, you could use the trick
> in that specific situation (which in practice means almost never) and
> add a clarifying comment to it.

Unfortunately, such code is not rare everywhere. Bad high-level design
choices ("feature A and B have similarities; let's call them FOO and
implement them with the same code. Only a few ifdefs needed ...") plus
a ban on compiler warnings leads to such things.

>   Btw, do compilers by convention not issue a warning about a no-op line
> like that?

Yes, that's my impression. I wouldn't be surprised if it was lint that
introduced the convention in the 1980s or earlier.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#15201

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> Unfortunately, such code is not rare everywhere. Bad high-level design
> choices ("feature A and B have similarities; let's call them FOO and
> implement them with the same code. Only a few ifdefs needed ...") plus
> a ban on compiler warnings leads to such things.

  Reminds me of an open source project (which shall remain unnamed)
where the developers had the breaindead principle that, 1) all warnings
are errors (by using the gcc flag for that), and 2) they used every single
warning flag that they could find on gcc's info page. Naturally they
considered these settings mandatory for official builds.

  This meant, for example, that if gcc did not inline a function that
was marked as 'inline' you would get an error, even though that situation
is completely inconsequential to the validity of the program. (The warning
in question is purely informative, and not turned on with -Wall, for
obvious reasons.)

  It also meant that the program might compile with one version of gcc but
not with another, if they use different inlining strategies. Way to go.

[toc] | [prev] | [next] | [standalone]

#15180

On Monday, April 2, 2012 6:39:50 AM UTC-5, F.Zwarts wrote:
> I have never seen this trick. Why don't you use the standard C++ way? Remove 
> the name of the parameter and the compiler will stop complaining. Less code, 
> better readability. The "(void)param" makes me wonder what the purpose is. 
> You will need comments to explain why it is used. If the parameter name is 
> omitted, it is immediately clear that it is not used in the function. No 
> comments needed. For the reason why it is not used in the function, comments 
> may be needed in both cases.
> 
> void someFunction(int)
> {
> 
> //
> }

Usually this only a problem in #ifdef'ed code.  E.g.

void someFunction(int wparam)
{
#ifdef _WIN32
  ...
#else
  // Only need this parameter on Windows.
  (void)wparam;
#endif
}

This works on most compilers but the only technique that I know of that works on all compilers is this:

namespace my {
  template <typename T> inline void unused(const T&) {}
}

...

  my::unused(wparam);


Mike

[toc] | [prev] | [next] | [standalone]

#15136

04/02/2012 13:16, Qi wrote:

> void someFunction(int param)
> {
>     (void)param; // param is not used in this function. This line is
> // just to silence the compiler warning about unused param.
> }
>
> Please note the "(void)param".
> Is that usage common or well known for you?
> Or you rarely saw it? Or even it's weird to you?
>
> Just your experience is enough

Sometime i've used some macros defined by my environment header file.
This code comes from winnt.h distributed with MS windows sdk 
(auto-explicative):

...

// begin_ntminiport begin_ntndis begin_ntminitape

//
// Macros used to eliminate compiler warning generated when formal
// parameters or local variables are not declared.
//
// Use DBG_UNREFERENCED_PARAMETER() when a parameter is not yet
// referenced but will be once the module is completely developed.
//
// Use DBG_UNREFERENCED_LOCAL_VARIABLE() when a local variable is not yet
// referenced but will be once the module is completely developed.
//
// Use UNREFERENCED_PARAMETER() if a parameter will never be referenced.
//
// DBG_UNREFERENCED_PARAMETER and DBG_UNREFERENCED_LOCAL_VARIABLE will
// eventually be made into a null macro to help determine whether there
// is unfinished work.
//

#if ! defined(lint)
#define UNREFERENCED_PARAMETER(P)          (P)
#define DBG_UNREFERENCED_PARAMETER(P)      (P)
#define DBG_UNREFERENCED_LOCAL_VARIABLE(V) (V)

#else // lint

// Note: lint -e530 says don't complain about uninitialized variables for
// this varible.  Error 527 has to do with unreachable code.
// -restore restores checking to the -save state

#define UNREFERENCED_PARAMETER(P)          \
     /*lint -save -e527 -e530 */ \
     { \
         (P) = (P); \
     } \
     /*lint -restore */
#define DBG_UNREFERENCED_PARAMETER(P)      \
     /*lint -save -e527 -e530 */ \
     { \
         (P) = (P); \
     } \
     /*lint -restore */
#define DBG_UNREFERENCED_LOCAL_VARIABLE(V) \
     /*lint -save -e527 -e530 */ \
     { \
         (V) = (V); \
     } \
     /*lint -restore */

#endif // lint

...

[toc] | [prev] | [next] | [standalone]

#15140

On 04/02/2012 01:16 PM, Qi wrote:
> Hi all,
> 
> Let me show some code first,
> 
> void someFunction(int param)
> {
>    (void)param; // param is not used in this function. This line is
> // just to silence the compiler warning about unused param.
> }


hi,

this is the way it was often done in C. nowadays you can simply comment
out variable name - it's more compact and readable that way.

there is just one issue with this. when you use some variable only in
debug, but not in release, in the second case you still get warning. for
example:

void doSth(const char *name)
{
  assert(name!=NULL);
  // no other usages of 'name'
}

for this i use other trick, added to a common code part:

template<typename T>
void ignore(const T&) { }

// ...

void doSth(const char *name)
{
  ignore(name);
  assert(name!=NULL);
  // no other usages of 'name'
}

i find it more readable (explicit intentions) than "(void)name".

-- 
pozdrawiam serdecznie / best regards,
bartek szurgot
/* http://www.baszerr.eu */

[toc] | [prev] | [next] | [standalone]

#15193

bartek szurgot <basz@no.spam> wrote:
> there is just one issue with this. when you use some variable only in
> debug, but not in release, in the second case you still get warning. for
> example:
> 
> void doSth(const char *name)
> {
>  assert(name!=NULL);
>  // no other usages of 'name'
> }

  A compiler should be smart enough to not give a warning in the above
case even if NDEBUG is defined (because, after all, the variable *is*
used: As a parameter to a macro.)

[toc] | [prev] | [next] | [standalone]

#15194

On 2012-4-3 13:28, Juha Nieminen wrote:
>>
>> void doSth(const char *name)
>> {
>>   assert(name!=NULL);
>>   // no other usages of 'name'
>> }
>
>    A compiler should be smart enough to not give a warning in the above
> case even if NDEBUG is defined (because, after all, the variable *is*
> used: As a parameter to a macro.)

When compiler sees the code, that line has gone if NDEBUG is defined
because it's removed by preprocessor if assert is empty when NDEBUG
is defined.
So there is still warning, no?


-- 
WQ

[toc] | [prev] | [next] | [standalone]

#15200

Qi <no@no.com> wrote:
>>    A compiler should be smart enough to not give a warning in the above
>> case even if NDEBUG is defined (because, after all, the variable *is*
>> used: As a parameter to a macro.)
> 
> When compiler sees the code, that line has gone if NDEBUG is defined
> because it's removed by preprocessor if assert is empty when NDEBUG
> is defined.
> So there is still warning, no?

  In the era where the C preprocessor, the compiler and the linker were
all completely separate programs that might have been the case (because
the compiler, which is the one issuing warnings, does not see the original
source code, only the code generated by the C preprocessor).

  However, in modern compilers there really is no need to separate the
C preprocessor from the compiler so at least in principle the compiler
could see that "hey, this variable is given as parameter to this macro"
and thus elide the warning.

  OTOH, I don't know if any modern compiler is that smart... I'm just
talking hypothetically here.

[toc] | [prev] | [next] | [standalone]

#15203

On 03 Apr 2012 14:09:09 GMT, Juha Nieminen <nospam@thanks.invalid>
wrote:

>Qi <no@no.com> wrote:
>>>    A compiler should be smart enough to not give a warning in the above
>>> case even if NDEBUG is defined (because, after all, the variable *is*
>>> used: As a parameter to a macro.)
>> 
>> When compiler sees the code, that line has gone if NDEBUG is defined
>> because it's removed by preprocessor if assert is empty when NDEBUG
>> is defined.
>> So there is still warning, no?
>
>  In the era where the C preprocessor, the compiler and the linker were
>all completely separate programs that might have been the case (because
>the compiler, which is the one issuing warnings, does not see the original
>source code, only the code generated by the C preprocessor).
>
>  However, in modern compilers there really is no need to separate the
>C preprocessor from the compiler so at least in principle the compiler
>could see that "hey, this variable is given as parameter to this macro"
>and thus elide the warning.
>
>  OTOH, I don't know if any modern compiler is that smart... I'm just
>talking hypothetically here.


The way C macros are defined work makes that hard - the variable is
*not* being passed to the macro - a bit of text is, so how would the
compiler know if rather than using the variable name, the macro might
be generating a string with that as contents?

OTOH, a special case for assert(), might make sense.  Although again,
there are going to be problematic corner cases - the text passed to
assert does not have to be a valid C expression if NDEBUG is defined -
so perhaps a new assert() with better semantics might be required.

[toc] | [prev] | [next] | [standalone]

#15210

On 04/03/2012 06:21 PM, Robert Wessel wrote:
> The way C macros are defined work makes that hard - the variable is
> *not* being passed to the macro - a bit of text is, so how would the
> compiler know if rather than using the variable name, the macro might
> be generating a string with that as contents?
> 
> OTOH, a special case for assert(), might make sense.  Although again,
> there are going to be problematic corner cases - the text passed to
> assert does not have to be a valid C expression if NDEBUG is defined -
> so perhaps a new assert() with better semantics might be required.


i don't think that doing "exceptions" for macros is a good idea. it
would be better to expand assert(x) to some implementation, that ignores
the parameter, like ignore(x) example i've provided before.

this would require change in the standard, since now assert(x), when
NDEBUG is set, is required to expand into ((void)0) (as it is in C).

-- 
pozdrawiam serdecznie / best regards,
bartek szurgot
/* http://www.baszerr.eu */

[toc] | [prev] | [next] | [standalone]

#15141

On Mon, 2012-04-02, Qi wrote:
> Hi all,
>
> Let me show some code first,
>
> void someFunction(int param)
> {
>     (void)param; // param is not used in this function. This line is
> // just to silence the compiler warning about unused param.
> }
>
> Please note the "(void)param".
> Is that usage common or well known for you?
> Or you rarely saw it? Or even it's weird to you?

I see it a lot in C code (sometimes hidden inside a UNUSED(param)
macro). I don't think I see it in C++ code, but I don't read much of
other people's C++ code.

> Just your experience is enough, no need to debate for it's good
> or bad. :-)
>
> The reason I ask this is, in my another thread, some very veteran
> C++ developers said they rarely saw that kind of usage.
> That makes me a little nervous because I used it a lot in my
> code to *improve* the code readability.
> If it's not well known trick then it reduces code readability
> and then I'm going to change my code about that.

I don't understand your reasoning. Why would the above be more
readable than

  void someFunction(int) // parameter obviously unused
  {}

or

  void someFunction() // parameter so unused it doesn't even exist
  {}

?

> That's not only about coding style but also about code readability.
>
> Looking forward to hearing your experience.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#15143

"Qi" <no@no.com> wrote in message news:jlc1qv$kjj$2@speranza.aioe.org...
> Hi all,
>
> Let me show some code first,
>
> void someFunction(int param)
> {
>    (void)param; // param is not used in this function. This line is
> // just to silence the compiler warning about unused param.
> }
>
> Please note the "(void)param".
> Is that usage common or well known for you?
> Or you rarely saw it? Or even it's weird to you?
>
> Just your experience is enough, no need to debate for it's good
> or bad. :-)

I say "NOT GOOD". It does indeed silence the compiler warning, but does not 
prevent subsequent use of that param, contrary to the expectations set by 
silencing the warning.

[toc] | [prev] | [next] | [standalone]

#15190

On 2012-4-3 0:37, MikeWhy wrote:
>
> I say "NOT GOOD". It does indeed silence the compiler warning, but does
> not prevent subsequent use of that param, contrary to the expectations
> set by silencing the warning.

I did something like that.
I (void)param first, then later I added some code to use param.
Really not good and confusing...


-- 
WQ

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web