By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,778 Members | 1,890 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,778 IT Pros & Developers. It's quick & easy.

void

P: n/a

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

tclCtrlBoard::tclCtrlBoard( void* poService )
{

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

}

Feb 17 '07 #1
Share this Question
Share on Google+
18 Replies


P: n/a
hyderabadblues wrote:
What does (void) poService in followinf peace of code mean

tclCtrlBoard::tclCtrlBoard( void* poService )
{

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

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

John
Feb 17 '07 #2

P: n/a
hyderabadblues 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?

--

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

P: n/a
On Sat, 17 Feb 2007 08:03:01 -0500, Pete Becker <pe**@versatilecoding.com>
wrote:
>hyderabadblues 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::tclCtrlBoard(void*)
{
}
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(void* DEBUG_VAR(poService))
{
#if defined DEBUG
// Use poService for debugging
VERIFY(poService == 0);
#endif
}

-dr
Feb 17 '07 #4

P: n/a
Dave Rahardja wrote:
On Sat, 17 Feb 2007 08:03:01 -0500, Pete Becker <pe**@versatilecoding.com>
wrote:
>hyderabadblues 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::tclCtrlBoard(void*)
{
}
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(void* DEBUG_VAR(poService))
{
#if defined DEBUG
// Use poService for debugging
VERIFY(poService == 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)
Feb 17 '07 #5

P: n/a
In article <Uu******************************@giganews.com>,
pe**@versatilecoding.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.
Feb 17 '07 #6

P: n/a
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<void>
#else
(void)
#endif
(x=1);'

:-)

Feb 17 '07 #7

P: n/a
(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)
"?? ???? ??????? ?????")
Feb 17 '07 #8

P: n/a
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)
Feb 17 '07 #9

P: n/a
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
Feb 17 '07 #10

P: n/a
"Dave Rahardja" <dr****************************@pobox.comwrote in message
news:p6********************************@4ax.com...
On Sat, 17 Feb 2007 08:03:01 -0500, Pete Becker <pe**@versatilecoding.com>
wrote:
>>hyderabadblues 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::tclCtrlBoard(void*)
{
}
Personally, I would change it to:

tclCtrlBoard::tclCtrlBoard( 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::tclCtrlBoard(void* DEBUG_VAR(poService))
{
#if defined DEBUG
// Use poService for debugging
VERIFY(poService == 0);
#endif
}

-dr

Feb 17 '07 #11

P: n/a
In article <11**********************@j27g2000cwj.googlegroups .com>,
Cl*********@gmail.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<void>
#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<void>
#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.
Feb 17 '07 #12

P: n/a
On Sat, 17 Feb 2007 14:56:43 -0500, Pete Becker <pe**@versatilecoding.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
Feb 18 '07 #13

P: n/a

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/
Feb 19 '07 #14

P: n/a
Jim Langston wrote:
>
Personally, I would change it to:

tclCtrlBoard::tclCtrlBoard( 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(void* DEBUG_VAR(poService))
--
Maksim A. Polyanin

"In thi world of fairy tales rolls are liked olso"
/Gnume/
Feb 19 '07 #15

P: n/a
I think the following example with DEBUG_VAR is best,
because comment /**/ can not be nested, that makes temporary code hiding
harder during test work. You can not easy comment part of code and pass it
to compile,

/*
tclCtrlBoard::tclCtrlBoard( void* /*poService*/

here end of comments
)
{
}

*/

and method

#if 0
#endif

can be worse, because some IDEs can not use "comment" colors for code
disabled with preprocessor.

--
Maksim A. Polyanin

"In thi world of fairy tales rolls are liked olso"
/Gnume/
Feb 19 '07 #16

P: n/a
In article <er**********@aioe.org>, gr******@yandex.ru says...

[ ... ]
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{
Now I know too many years on Usenet has warped my brain. Seeing "asm"
and "portable" together was enough that when I glanced at "Nold", I saw
"Nudds". (Un?)fortunately, even with my advanced years, my heart seems
to have withstood the shock and horror of that moment!

Okay -- I promise to stay on-topic, and keep my warped sense of humor in
check for a while.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Feb 19 '07 #17

P: n/a
Jerry Coffin wrote:
>
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{

Now I know too many years on Usenet has warped my brain. Seeing "asm"
and "portable" together was enough that when I glanced at "Nold",
I saw "Nudds".
(Un?)fortunately, even with my advanced years, my heart seems
to have withstood the shock and horror of that moment!
"warp, Nudds, withstood" - my dictionary of 8000 popular english words
has no them, but probably I can guess what you meant. Really, you are
writing, but we are translating all of that.
Okay -- I promise to stay on-topic, and keep my warped sense
of humor in check for a while.
Probably it was dark humor, that can turn readers into false
thoughts.
>Seeing "asm" and "portable" together was enough
"Asm" and "portable" of course can be used together.

Interface (of function or class declaration) makes any part of code
"portable", and multiple implementations (with "asm" fro example)
makes the part of code "effective".

Std library function memcpy() is a well-known example of the
combination. Some compilers has target dependent, builtin effective
implemetations for it.

This is portable implementation of memcpy()

namespace Nportable{
inline void *memcpy(void *dest, const void *src, const int num)
{
if(!num)return dest;
if( (!dest) || (!src) )throw "zptr";

register char *d=static_cast<char*>(dest);
register const char * s=static_cast<const char*>(src);

for(register int i=num; i; --i){*d++=*s++;}
}}

This is one of possible more effective implementation of memcpy() for
concrete target

namespace Nx86{
inline void *memcpy(
register void *dest,
register const void *src,
register const int num
)
{asm{
//complier will eliminate the move opcode
//and will place "dest, src"
//in correct register directly
//in fact, it is "input register assuming"
movl dest,%edi
movl src,%esi

//if you maintain agreement that
//DF between functions in concrete state
//(for example is always down to up)
//cld and std opcode can be avoided

movl num,%ecx
shrl $2,%ecx
rep movsl

movl num,%ecx
andl $3,%ecx
rep movsb
}}}

In you program you can link suitable memcpy implementation for example
with the help of "using".

Perfomance of Nx86::memcpy on some CPUs can be more than 4 times
better than perfomans Nportable::memcpy. So, if your program is
copying large areas of memory, you will see noticable improvement
without any portability lost.

In general, we are forced to use "asm" when we need hardware specific,
because C and C++ compiler do not implement all possible operations.
Why "swap", for example, is not supported? I do not know.

--
Maksim A. Polyanin

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

Feb 19 '07 #18

P: n/a
Grizlyk wrote:
Jerry Coffin wrote:
Now I know too many years on Usenet has warped my brain. Seeing
"asm" and "portable" together was enough that when I glanced at
"Nold", I saw "Nudds".
(Un?)fortunately, even with my advanced years, my heart seems
to have withstood the shock and horror of that moment!

"warp, Nudds, withstood" - my dictionary of 8000 popular english words
has no them, but probably I can guess what you meant. Really, you are
writing, but we are translating all of that.
If your dictionary doesn't have "warp" or "withstood" then I recommend
a different one. Some online ones:

<http://m-w.com/>
<http://dictionary.com>
Nudds is a proper noun, and I doubt you could figure it out from
context. A bit of Google Groups searching would tell you.

Brian
Feb 20 '07 #19

This discussion thread is closed

Replies have been disabled for this discussion.