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


Groups > comp.lang.c++ > #82819

Re: Can anyone improve this ?

From "Alf P. Steinbach" <alf.p.steinbach@gmail.com>
Newsgroups comp.lang.c++
Subject Re: Can anyone improve this ?
Date 2022-01-18 12:09 +0100
Organization A noiseless patient Spider
Message-ID <ss674f$a87$1@dont-email.me> (permalink)
References <srjdtm$d9c$1@dont-email.me> <86ee56rzbz.fsf@linuxsc.com> <ss4ksr$d9d$1@dont-email.me> <86sftlr1c7.fsf@linuxsc.com>

Show all headers | View raw


On 18 Jan 2022 07:43, Tim Rentsch wrote:
> "Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
> 
>> On 17 Jan 2022 19:28, Tim Rentsch wrote:
>>
>>> (Note:  the cases() macro produces one 'case X:' for each
>>> argument X except the last one where the ':' is omitted,
>>> written using the standard C preprocessor, and left as an
>>> exercise for any ambitious readers.)
>>
>> Exercise for you:  test that unrevealed macro with Visual C++.
> 
> Update after my previous message.  The cases() macro I wrote has
> now been tested with Visual C++, and it compiles there without
> complaint.

Good to hear. Visual C++ has or had somewhat non-standard treatment of 
token pasting and variadic macros, and either it's been fixed, or your 
code avoided running into it. A comment in some old code of mine says that

❞ [Visual C++ 2017] is unable to count `__VA_ARGS__` as *n* arguments, 
and instead counts it as 1. Mostly.

Counting the number of arguments of a variadic macro was AFAIK invented 
by Laurent Deniau in 2006, and it can go like this:


#define N_ARGUMENTS( ... )                         \
     INVOKE_MACRO(                                  \
         ARGUMENT_64,                               \
         (                                               \
             __VA_ARGS__,                                \
                                     63, 62, 61, 60,     \
             59, 58, 57, 56, 55, 54, 53, 52, 51, 50,     \
             49, 48, 47, 46, 45, 44, 43, 42, 41, 40,     \
             39, 38, 37, 36, 35, 34, 33, 32, 31, 30,     \
             29, 28, 27, 26, 25, 24, 23, 22, 21, 20,     \
             19, 18, 17, 16, 15, 14, 13, 12, 11, 10,     \
              9,  8,  7,  6,  5,  4,  3,  2,  1,  0      \
         )                                               \
     )

#define ARGUMENT_64( \
      a1,  a2,  a3,  a4,  a5,  a6,  a7,  a8,  a9, a10,  \
     a11, a12, a13, a14, a15, a16, a17, a18, a19, a20,  \
     a21, a22, a23, a24, a25, a26, a27, a28, a29, a30,  \
     a31, a32, a33, a34, a35, a36, a37, a38, a39, a40,  \
     a41, a42, a43, a44, a45, a46, a47, a48, a49, a50,  \
     a51, a52, a53, a54, a55, a56, a57, a58, a59, a60,  \
     a61, a62, a63, a64, ... ) \
     a64


... where `INVOKE_MACRO` tackles the Visual C++ quirks:


/// \brief Invokes the specified macro with the specified arguments list.
/// \hideinitializer
/// \param m        The name of a macro to invoke.
/// \param arglist  A parenthesized list of arguments. Can be empty.
///
/// The only difference between `INVOKE_MACRO` and `INVOKE_MACRO_B` is 
that they're
/// *different* macros. One may have to use both in order to guarantee 
macro expansion in
/// certain (not very well defined) situations.

#define INVOKE_MACRO( m, arglist ) \
     m arglist

#define INVOKE_MACRO_B( m, arglist ) \
     m arglist


I've removed macro name prefixes in the above. For reusable code there 
better be name prefixes, to reduce or avoid name collisions.

- Alf

Back to comp.lang.c++ | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Can anyone improve this ? Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-11 09:08 +0100
  Re: Can anyone improve this ? Juha Nieminen <nospam@thanks.invalid> - 2022-01-11 09:50 +0000
    Re: Can anyone improve this ? Juha Nieminen <nospam@thanks.invalid> - 2022-01-11 11:07 +0000
    Re: Can anyone improve this ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-01-11 11:08 +0000
    Re: Can anyone improve this ? Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-11 18:28 +0100
      Re: Can anyone improve this ? Christian Gollwitzer <auriocus@gmx.de> - 2022-01-11 18:41 +0100
        Re: Can anyone improve this ? Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-11 19:36 +0100
      Re: Can anyone improve this ? Öö Tiib <ootiib@hot.ee> - 2022-01-11 21:54 -0800
  Re: Can anyone improve this ? Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-11 21:51 +0100
    Re: Can anyone improve this ? Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-12 14:19 +0100
    Re: Can anyone improve this ? Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-12 14:20 +0100
      Re: Can anyone improve this ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-01-12 14:14 +0000
        Re: Can anyone improve this ? Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-12 17:20 +0100
          Re: Can anyone improve this ? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-01-12 08:38 -0800
          Re: Can anyone improve this ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-01-12 16:55 +0000
        Re: Can anyone improve this ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-16 12:09 -0800
        Re: Can anyone improve this ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-16 12:12 -0800
          Re: Can anyone improve this ? Öö Tiib <ootiib@hot.ee> - 2022-01-16 13:00 -0800
            Re: Can anyone improve this ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-17 10:13 -0800
  Re: Can anyone improve this ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-17 10:28 -0800
    Re: Can anyone improve this ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-01-17 21:51 +0100
      Re: Can anyone improve this ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-17 16:16 -0800
      Re: Can anyone improve this ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-17 22:43 -0800
        Re: Can anyone improve this ? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-01-18 12:09 +0100
    Re: Can anyone improve this ? Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-18 09:18 +0100

csiph-web