void

[hyderabadblues]

What does (void) poService in followinf peace of code mean

tclCtrlBoard::t clCtrlBoard( void* poService )
{

# if defined Something
(void) poService; \\ What does this mean

}

[John Harrison]

Re: void

hyderabadblues wrote:

What does (void) poService in followinf peace of code mean
>
tclCtrlBoard::t clCtrlBoard( void* poService )
{
>
# if defined Something
(void) poService; \\ What does this mean
>
}
>

Nothing, it's a waste of typing, remove it.

John

[Pete Becker]

Re: void

hyderabadblues wrote:

What does (void) poService in followinf peace of code mean
>
tclCtrlBoard::t clCtrlBoard( void* poService )
{
>
# if defined Something
(void) poService; \\ What does this mean
>
}
>

It's a workaround for a compiler warning that the argument poService is
not used. It tells the compiler to evaluate the expression poService and
to ignore it. Isn't it wonderful what people do to cope with busybody
compilers?

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

[Dave Rahardja]

Re: void

On Sat, 17 Feb 2007 08:03:01 -0500, Pete Becker <pete@versatile coding.com>
wrote:

>hyderabadblu es wrote:

>What does (void) poService in followinf peace of code mean
>>
>tclCtrlBoard:: tclCtrlBoard( void* poService )
> {
>>
> # if defined Something
> (void) poService; \\ What does this mean
>>
> }
>>

>
>It's a workaround for a compiler warning that the argument poService is
>not used. It tells the compiler to evaluate the expression poService and
>to ignore it. Isn't it wonderful what people do to cope with busybody
>compilers?

That busybody compiler feature was probably added as a warning that helps you
find bugs. If the OP wants to get rid of the warning, change the function's
definition to:

tclCtrlBoard::t clCtrlBoard(voi d*)
{
}


Sometimes certain input parameters are only during debug builds. In that case
I tend to use:

#if defined(DEBUG)
#define DEBUG_VAR(x) (x)
#else
#define DEBUG_VAR(x)
#endif

tclCtrlBoard::t clCtrlBoard(voi d* DEBUG_VAR(poSer vice))
{
#if defined DEBUG
// Use poService for debugging
VERIFY(poServic e == 0);
#endif
}

-dr

[Pete Becker]

Re: void

Dave Rahardja wrote:

On Sat, 17 Feb 2007 08:03:01 -0500, Pete Becker <pete@versatile coding.com>
wrote:
>

>hyderabadblu es wrote:

>>What does (void) poService in followinf peace of code mean
>>>
>>tclCtrlBoard: :tclCtrlBoard( void* poService )
>> {
>>>
>> # if defined Something
>> (void) poService; \\ What does this mean
>>>
>> }
>>>

>It's a workaround for a compiler warning that the argument poService is
>not used. It tells the compiler to evaluate the expression poService and
>to ignore it. Isn't it wonderful what people do to cope with busybody
>compilers?

>
That busybody compiler feature was probably added as a warning that helps you
find bugs.

It was added as a warning that some comiler writer thought might help
find bugs, but it's really a matter of enforcing someone's notion of
good coding style. If your ideas of good style differ, you end up
fighting with the compiler.

If the OP wants to get rid of the warning, change the function's
definition to:
>
tclCtrlBoard::t clCtrlBoard(voi d*)
{
}
>
>
Sometimes certain input parameters are only during debug builds. In that case
I tend to use:
>
#if defined(DEBUG)
#define DEBUG_VAR(x) (x)
#else
#define DEBUG_VAR(x)
#endif
>
tclCtrlBoard::t clCtrlBoard(voi d* DEBUG_VAR(poSer vice))
{
#if defined DEBUG
// Use poService for debugging
VERIFY(poServic e == 0);
#endif
}
>

All that, just because some compiler writer decided that he knows better
than you do what you meant to write? I prefer to turn off stylistic
warnings like this one.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

[Jerry Coffin]

Re: void

In article <UuCdnSz97qV6gU rYnZ2dnUVZ_vvin Z2d@giganews.co m>,
pete@versatilec oding.com says...

Dave Rahardja wrote:

[ ... ]

That busybody compiler feature was probably added as a warning that
helps you find bugs.

>
It was added as a warning that some comiler writer thought might help
find bugs, but it's really a matter of enforcing someone's notion of
good coding style. If your ideas of good style differ, you end up
fighting with the compiler.

I disagree with Pete on this one. In fact the compiler should warn you
if you ignore any result, not just one from a function. After all,
something like 'x=1;' _might_ have been a mistake -- perhaps you really
intended to assign the result to something else. '(void)x=1;' makes it
absolutely clear that ignoring the result of the assignment was really
intended!

[Note for the humor impaired: that's called sarcasm -- I think Pete's
absolutely right. I once used a lint program that issued a warning for
any typedef that wasn't in all caps. When I say "once" I don't mean "I
used to use it" -- I mean I used it exactly once, and then erased it.]

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Clem.Dickey@gmail.com]

Re: void

On Feb 17, 9:20 am, Jerry Coffin <jcof...@taeus. comwrote:

'(void)x=1;' makes it
absolutely clear that ignoring the result of the assignment was really
intended!

You need more parentheses: '(void)(x=1);'. And C++ programmers should
avoid old cast syntax:

#if 199711L <= __cplusplus
static_cast<voi d>
#else
(void)
#endif
(x=1);'

:-)

[Alex Mizrahi]

Re: void

(message (Hello 'Pete)
(you :wrote :on '(Sat, 17 Feb 2007 10:19:02 -0500))
(

PBIt was added as a warning that some comiler writer thought might help
PBfind bugs, but it's really a matter of enforcing someone's notion of
PBgood coding style. If your ideas of good style differ, you end up
PBfighting with the compiler.

you think having bullshit variables that are not used anyware might be a
good style??

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"?? ???? ??????? ?????")

[Pete Becker]

Re: void

Alex Mizrahi wrote:

(message (Hello 'Pete)
(you :wrote :on '(Sat, 17 Feb 2007 10:19:02 -0500))
(
>
PBIt was added as a warning that some comiler writer thought might help
PBfind bugs, but it's really a matter of enforcing someone's notion of
PBgood coding style. If your ideas of good style differ, you end up
PBfighting with the compiler.
>
you think having bullshit variables that are not used anyware might be a
good style??
>

There are situations where you write functions that take arguments that
aren't used. One example is given in Dave Rahardja's message earlier in
this thread. For another example, when you call through a pointer to a
function, all the pointees have to have the same argument list, even if
some of them don't use some or all of the arguments. Or if you're
writing a base class with pure virtual functions, the functions
generally don't use any of their arguments. In all cases giving the
arguments names can help document their roles. It's not up to the
compiler writer to tell me that I shouldn't do that.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

[Kai-Uwe Bux]

Re: void

Alex Mizrahi wrote:

(message (Hello 'Pete)
(you :wrote :on '(Sat, 17 Feb 2007 10:19:02 -0500))
(
>
PBIt was added as a warning that some comiler writer thought might help
PBfind bugs, but it's really a matter of enforcing someone's notion of
PBgood coding style. If your ideas of good style differ, you end up
PBfighting with the compiler.
>
you think having bullshit variables that are not used anyware might be a
good style??

In the case of the OP, that variable was a parameter. There are cases where
a function signature may specify parameters that are not needed to
implement the contract. Examples include:

a) Virtual functions where the additional parameter might only be needed in
some derived classes.

b) Hint parameters (as in the insert methods for the standard containers).
These do not influence the result of the operation but can be used for
performance improvements. An initial implementation may just leave these
parameters unused. Also the initial implementation may be a good reference
implementation as it is likely less complex and can be used to test the
correctness of an implementation that takes advantage of the hint
parameter.


Also, sometimes local variables just look as though they are not used. E.g.,
an RAII guard for a mutex (locking upon construction, unlocking upon
destruction) might lock a critical region of code like so:

{
LockGuard dummy ( the_lock ); // locking
/*
here goes stuff that never ever
uses dummy
*/
} // oops, dummy is destroyed and releases the lock

A compiler might be smart enough to detect the non-trivial destructor.
However, if you write your code base with multi-threading in mind, you
might have use a technique where just the implementation of LockGuard
changes in a single-threaded application (so that now the constructor and
destructor are both trivial). Then you have an honest to god unused
variable that just serves as a hook in your library code to support use in
multi-threaded applications.


Best

Kai-Uwe Bux

[Jim Langston]

Re: void

"Dave Rahardja" <drahardja_atsi gn_pobox_dot_co m@pobox.comwrot e in message
news:p66et2p9av 2qbtskch3981erf n5q47h7pg@4ax.c om...

On Sat, 17 Feb 2007 08:03:01 -0500, Pete Becker <pete@versatile coding.com>
wrote:
>

>>hyderabadblue s wrote:

>>What does (void) poService in followinf peace of code mean
>>>
>>tclCtrlBoard: :tclCtrlBoard( void* poService )
>> {
>>>
>># if defined Something
>> (void) poService; \\ What does this mean
>>>
>> }
>>>

>>
>>It's a workaround for a compiler warning that the argument poService is
>>not used. It tells the compiler to evaluate the expression poService and
>>to ignore it. Isn't it wonderful what people do to cope with busybody
>>compilers?

>
That busybody compiler feature was probably added as a warning that helps
you
find bugs. If the OP wants to get rid of the warning, change the
function's
definition to:
>
tclCtrlBoard::t clCtrlBoard(voi d*)
{
}

Personally, I would change it to:

tclCtrlBoard::t clCtrlBoard( void* /*poService*/ )
{
}

>
>
Sometimes certain input parameters are only during debug builds. In that
case
I tend to use:
>
#if defined(DEBUG)
#define DEBUG_VAR(x) (x)
#else
#define DEBUG_VAR(x)
#endif
>
tclCtrlBoard::t clCtrlBoard(voi d* DEBUG_VAR(poSer vice))
{
#if defined DEBUG
// Use poService for debugging
VERIFY(poServic e == 0);
#endif
}
>
-dr

[Jerry Coffin]

Re: void

In article <1171738825.689 678.235090@j27g 2000cwj.googleg roups.com>,
Clem.Dickey@gma il.com says...

On Feb 17, 9:20 am, Jerry Coffin <jcof...@taeus. comwrote:

'(void)x=1;' makes it
absolutely clear that ignoring the result of the assignment was really
intended!

>
You need more parentheses: '(void)(x=1);'. And C++ programmers should
avoid old cast syntax:
>
#if 199711L <= __cplusplus
static_cast<voi d>
#else
(void)
#endif
(x=1);'
>
:-)

That's a bit only the ugly side though -- I think it shold be wrapped up
in a function:

template<class T>
void mov(T &a, T const &b) {
#if 199711L <= __cplusplus
static_cast<voi d>
#else
(void)
#endif
(x=1);'
}

Then we could write things like:

int eax, ebx, ecx, edx, esi, edi;

mov(eax, ebx);
mov(ecx, edx);
mov(eax, ecx);

and life would clearly be wonderful! Of course, to go with, we'd need
functions for other operations, including add, sub, mul, div, idiv
(signed division), and so on. Think of the beauty:

int eax, ebx, ecx, edx, esi, edi;

mov(eax, 0x1);
mov(ebx, 0x2);
add(eax, ebx);
mov(ecx, 0x3);
div(eax, ecx);
mov(esi, eax);

There's really only one shortcoming with this language -- since we're
doing everything with function calls, the parentheses and semicolons are
really unnecessary. I think a small preprocessor would be in order, so
the code above would be written like this:

mov eax, 0x1
mov ebx, 0x2
add eax, ebx
mov ecx, 0x3
div eax, ecx
mov esi, eax

This improves productivity by about 3/14= ~21%. Think of it: fewer bugs
and 21% better productivity. This is the ultimate language, and will
lead to an amazing new era in software design and development. Free from
the constraints of previous paradigms, we will no longer need to build
programs from the ground up, but instead simply assemble these high
level building blocks into ever more sophisticated programs. Clearly
this innovation should be called "assembly language" to distinguish it
from the previous, inferior attempts.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Dave Rahardja]

Re: void

On Sat, 17 Feb 2007 14:56:43 -0500, Pete Becker <pete@versatile coding.com>
wrote:

>Alex Mizrahi wrote:

>(message (Hello 'Pete)
>(you :wrote :on '(Sat, 17 Feb 2007 10:19:02 -0500))
>(
>>
> PBIt was added as a warning that some comiler writer thought might help
> PBfind bugs, but it's really a matter of enforcing someone's notion of
> PBgood coding style. If your ideas of good style differ, you end up
> PBfighting with the compiler.
>>
>you think having bullshit variables that are not used anyware might be a
>good style??
>>

>
>There are situations where you write functions that take arguments that
>aren't used. One example is given in Dave Rahardja's message earlier in
>this thread. For another example, when you call through a pointer to a
>function, all the pointees have to have the same argument list, even if
>some of them don't use some or all of the arguments. Or if you're
>writing a base class with pure virtual functions, the functions
>generally don't use any of their arguments. In all cases giving the
>arguments names can help document their roles. It's not up to the
>compiler writer to tell me that I shouldn't do that.

That's what compiler switches are for, I suppose.

-dr

[Grizlyk]

Re: void


Jerry Coffin wrote:

>
Then we could write things like:
>
int eax, ebx, ecx, edx, esi, edi;
>
mov(eax, ebx);
mov(ecx, edx);
mov(eax, ecx);
>
and life would clearly be wonderful! Of course, to go with, we'd need
functions for other operations, including add, sub, mul, div, idiv
(signed division), and so on. Think of the beauty:

All correct compilers contain internal "asm" operators and even
"human-readable asm" stuffs, that allow you to group what all you have
written befor and after into single function, to make your code fast and
portable together

namespace Nold_CPU{
void foo()
{asm

mov eax, ebx
mov ebx, ecx
mov ecx, edx

}}}

namespace Nnew_CPU{
void foo()
{asm

mov eax, edx

}}}

This improves productivity by about 3/14= ~21%.

It is really improves productivity even much more than 21%, for example,
221% or 421%.

Think of it: fewer bugs and 21% better productivity.
This is the ultimate language, and will
lead to an amazing new era in software design and development.

It is not new, it is very old and popular stuff.

Free from
the constraints of previous paradigms,

Probably you call your habits as "only correct paradigm"? And what you can
say against well implemented functions?

I think you disagree with OO conception - portable interface and hidden
effective implementation and want to have "portable effective
implementation" - the last is impossible in nature.

--
Maksim A. Polyanin

"In thi world of fairy tales rolls are liked olso"
/Gnume/

[Grizlyk]

Re: void

Jim Langston wrote:

>
Personally, I would change it to:
>
tclCtrlBoard::t clCtrlBoard( void* /*poService*/ )
{
}

I think the following example with DEBUG_VAR is best, because some compilers
can not understand "#pragma argsused" and the pragma has not selective
disabling.

Maybe DEBUG_VAR can be called shorter, for example, AU.

>Sometimes certain input parameters are only during debug builds. In that
>case
>I tend to use:
>>
>#if defined(DEBUG)
>#define DEBUG_VAR(x) (x)
>#else
>#define DEBUG_VAR(x)
>#endif
>>
>tclCtrlBoard:: tclCtrlBoard(vo id* DEBUG_VAR(poSer vice))

--
Maksim A. Polyanin

"In thi world of fairy tales rolls are liked olso"
/Gnume/