void

Discussion in 'C++' started by hyderabadblues, Feb 17, 2007.

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

    tclCtrlBoard::tclCtrlBoard( void* poService )
    {

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

    }
    hyderabadblues, Feb 17, 2007
    #1
    1. Advertising

  2. 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
    John Harrison, Feb 17, 2007
    #2
    1. Advertising

  3. hyderabadblues

    Pete Becker Guest

    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)
    Pete Becker, Feb 17, 2007
    #3
  4. On Sat, 17 Feb 2007 08:03:01 -0500, Pete Becker <>
    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
    Dave Rahardja, Feb 17, 2007
    #4
  5. hyderabadblues

    Pete Becker Guest

    Dave Rahardja wrote:
    > On Sat, 17 Feb 2007 08:03:01 -0500, Pete Becker <>
    > 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)
    Pete Becker, Feb 17, 2007
    #5
  6. hyderabadblues

    Jerry Coffin Guest

    In article <>,
    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.
    Jerry Coffin, Feb 17, 2007
    #6
  7. hyderabadblues

    Guest

    On Feb 17, 9:20 am, Jerry Coffin <> wrote:
    > '(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, 2007
    #7
  8. hyderabadblues

    Alex Mizrahi Guest

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

    PB> It was added as a warning that some comiler writer thought might help
    PB> find bugs, but it's really a matter of enforcing someone's notion of
    PB> good coding style. If your ideas of good style differ, you end up
    PB> fighting 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)
    "?? ???? ??????? ?????")
    Alex Mizrahi, Feb 17, 2007
    #8
  9. hyderabadblues

    Kai-Uwe Bux Guest

    Alex Mizrahi wrote:

    > (message (Hello 'Pete)
    > (you :wrote :eek:n '(Sat, 17 Feb 2007 10:19:02 -0500))
    > (
    >
    > PB> It was added as a warning that some comiler writer thought might help
    > PB> find bugs, but it's really a matter of enforcing someone's notion of
    > PB> good coding style. If your ideas of good style differ, you end up
    > PB> fighting 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
    Kai-Uwe Bux, Feb 17, 2007
    #9
  10. hyderabadblues

    Pete Becker Guest

    Alex Mizrahi wrote:
    > (message (Hello 'Pete)
    > (you :wrote :eek:n '(Sat, 17 Feb 2007 10:19:02 -0500))
    > (
    >
    > PB> It was added as a warning that some comiler writer thought might help
    > PB> find bugs, but it's really a matter of enforcing someone's notion of
    > PB> good coding style. If your ideas of good style differ, you end up
    > PB> fighting 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)
    Pete Becker, Feb 17, 2007
    #10
  11. hyderabadblues

    Jim Langston Guest

    "Dave Rahardja" <> wrote in message
    news:p...
    > On Sat, 17 Feb 2007 08:03:01 -0500, Pete Becker <>
    > 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
    Jim Langston, Feb 17, 2007
    #11
  12. hyderabadblues

    Jerry Coffin Guest

    In article <>,
    says...
    > On Feb 17, 9:20 am, Jerry Coffin <> wrote:
    > > '(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.
    Jerry Coffin, Feb 17, 2007
    #12
  13. On Sat, 17 Feb 2007 14:56:43 -0500, Pete Becker <>
    wrote:

    >Alex Mizrahi wrote:
    >> (message (Hello 'Pete)
    >> (you :wrote :eek:n '(Sat, 17 Feb 2007 10:19:02 -0500))
    >> (
    >>
    >> PB> It was added as a warning that some comiler writer thought might help
    >> PB> find bugs, but it's really a matter of enforcing someone's notion of
    >> PB> good coding style. If your ideas of good style differ, you end up
    >> PB> fighting 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
    Dave Rahardja, Feb 18, 2007
    #13
  14. hyderabadblues

    Grizlyk Guest

    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, Feb 19, 2007
    #14
  15. hyderabadblues

    Grizlyk Guest

    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/
    Grizlyk, Feb 19, 2007
    #15
  16. hyderabadblues

    Grizlyk Guest


    > 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/
    Grizlyk, Feb 19, 2007
    #16
  17. hyderabadblues

    Jerry Coffin Guest

    In article <erbfa1$6f4$>, 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.
    Jerry Coffin, Feb 19, 2007
    #17
  18. hyderabadblues

    Grizlyk Guest

    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/
    Grizlyk, Feb 19, 2007
    #18
  19. hyderabadblues

    Default User Guest

    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
    Default User, Feb 20, 2007
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Sergio

    returning a void (*)(void)

    Sergio, Jan 5, 2005, in forum: C++
    Replies:
    6
    Views:
    425
    Jonathan Turkanis
    Jan 5, 2005
  2. Ollej Reemt
    Replies:
    7
    Views:
    500
    Jack Klein
    Apr 22, 2005
  3. Stig Brautaset

    `void **' revisited: void *pop(void **root)

    Stig Brautaset, Oct 25, 2003, in forum: C Programming
    Replies:
    15
    Views:
    777
    The Real OS/2 Guy
    Oct 28, 2003
  4. Replies:
    5
    Views:
    815
    S.Tobias
    Jul 22, 2005
  5. Replies:
    1
    Views:
    394
    Victor Bazarov
    May 23, 2007
Loading...

Share This Page