C ++: a session of spontaneous archeology and why you should not use variable functions in the style of C

What about ellipse and va_list is stated in the Standard

• You can declare a function that takes an arbitrary number of arguments. Those. function arguments may have more than parameters. To do this, the list of its parameters must end with an ellipsis, but also at least one fixed parameter must be present [C11 6.9.1 / 8] :
  
  

  void foo(int parm1, int parm2, ...);

• Information about the number and types of arguments corresponding to the ellipsis is not transferred to the function itself. Those. after the last named parameter ( parm2in the example above) [C11 6.7.6.3/9] .
  
• To access these arguments must use declared title <stdarg.h>type va_list, and 4 (3 to standard C11) macro: va_start, va_arg, va_endand va_copy(since C11) [C11 7.16] .
  
  
  for example

  int add(int count, ...) 
  {
      int result = 0;
      va_list args;
      va_start(args, count);
      for (int i = 0; i < count; ++i)
      {
          result += va_arg(args, int);
      }
      va_end(args);
      return result;
  }

  
  Да, функция не знает, сколько у нее аргументов. Ей надо как-то передать это число. В данном случае — через единственный именованный аргумент (другой распространенный вариант — передавать последним аргументом NULL, как в execl, или 0).
• The last named argument cannot have a storage class register, cannot be a function or an array. Otherwise, the behavior is undefined [C11 7.16.1.4/4] .
• Moreover, the last named argument and all the nameless ones are given a “ default argument type increase” ( default argument promotion ; if there is a good translation of this concept into Russian, I will gladly use it). This means that if an argument has a type char, short(with or without a sign) or float, then the corresponding parameters must be addressed as int, int(with or without a sign) or double. Otherwise, the behavior is undefined [C11 7.16.1.1/2] .
• About the type, va_listit says only that it is declared in <stdarg.h>and is complete (that is, the size of an object of this type is known) [C11 7.16 / 3] .

Why? But because!

By the way, there is no acceptable way to write a portable function of an arbitrary number of arguments, since There is no portable way for the called function to find out how many arguments were passed to it when it was called. ... printf, the most typical function of the C language of an arbitrary number of arguments, ... is not portable and must be implemented for each system.

#ifndef _STADARG
#define _STADARG
#define _AUPBND 1
#define _ADNBND 1
typedef char* va_list
#define va_arg(ap, T) \
 (*(T*)(((ap) += _Bnd(T, _AUPBND)) - _Bnd(T, _ADNBND)))
#define va_end(ap) \
 (void)0
#define va_start(ap, A) \
 (void)((ap) = (char*)&(A) + _Bnd(A, _AUPBND))
#define _Bnd(X, bnd) \
 (sizeof(X)  + (bnd) & ~(bnd))
#endif

typedef struct
{
    unsigned int gp_offset;
    unsigned int fp_offset;
    void *overflow_arg_area;
    void *reg_save_area;
} va_list[1];

Variable functions in C ++

• Because C ++, in contrast to C, allows you to get the address of registervariables, then the last named argument of a variable function can have this storage class.
  
• Because references appearing in C ++ violate the unspoken rule of C variable functions — the size of the parameter must match the size of its declared type — the last named argument cannot be a link. Otherwise - indefinite behavior.
  
• Because in C ++ there is no concept of " increasing the type of the argument by default ", then the phrase
  

  If you parmNdon’t know what to say about this?

  need to be replaced by

  It parmNis not the case of the parameter.

How easy and wrong to use variable functions

1. It is wrong to declare the last named argument with the type being raised, i.e. char, signed char, unsigned char, singed short, unsigned shortOr float. The result according to the Standard will be undefined behavior.
   
   
   Wrong code

   void foo(float n, ...)
   {
       va_list va;
       va_start(va, n);
       std::cout << va_arg(va, int) << std::endl;
       va_end(va);
   }

   
   
   
   Of all the compilers that I had on hand (gcc, clang, MSVC), only clang issued a warning.
   
   
   Clang warning

   ./test.cpp:7:18: warning: passing an object that undergoes default argument promotion to 'va_start' has undefined behavior [-Wvarargs]
       va_start(va, n);
                    ^

   
   And although in all cases the compiled code behaved correctly, you should not count on it.
   
   
   It will be right

   void foo(double n, ...)
   {
       va_list va;
       va_start(va, n);
       std::cout << va_arg(va, int) << std::endl;
       va_end(va);
   }

   
   
2. It is wrong to declare the last named argument by reference. Any reference. The standard in this case also promises undefined behavior.
   
   
   Wrong code

   void foo(int& n, ...)
   {
       va_list va;
       va_start(va, n);
       std::cout << va_arg(va, int) << std::endl;
       va_end(va);
   }

   
   gcc 7.3.0 compiled this code without a single comment. clang 6.0.0 issued a warning, but nevertheless compiled it.
   
   
   Clang warning

   ./test.cpp:7:18: warning: passing an object of reference type to 'va_start' has undefined behavior [-Wvarargs]
       va_start(va, n);
                    ^

   
   In both cases, the program worked correctly (lucky, you can not rely on it). But MSVC 19.15.26730 distinguished itself - he refused to compile the code, because The argument va_startshould not be a link.
   
   
   MSVC Error

   c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.15.26726\include\vadefs.h(151): error C2338: va_start argument must not have reference type and must not be parenthesized

   
   
   Well, the correct version looks like this, for example.

   void foo(int* n, ...)
   {
       va_list va;
       va_start(va, n);
       std::cout << va_arg(va, int) << std::endl;
       va_end(va);
   }

   
   
3. It is wrong to ask for a va_argraiseable type - char, shortor float.
   
   
   Wrong code

   #include <cstdarg>
   #include <iostream>
   void foo(int n, ...)
   {
       va_list va;
       va_start(va, n);
       std::cout << va_arg(va, int) << std::endl;
       std::cout << va_arg(va, float) << std::endl;
       std::cout << va_arg(va, int) << std::endl;
       va_end(va);
   }
   int main()
   {
       foo(0, 1, 2.0f, 3);
       return 0;
   }

   
   Here is more interesting. When compiling gcc , it gives a warning that you should use it doubleinstead float, and if this code is executed anyway, the program will end with an error.
   
   
   Gcc warning

   ./test.cpp:9:15: warning: ‘float’ is promoted to ‘double’ when passed through ‘...’
     std::cout << va_arg(va, float) << std::endl;
                  ^~~~~~
   ./test.cpp:9:15: note: (so you should pass ‘double’ not ‘float’ to ‘va_arg’)
   ./test.cpp:9:15: note: if this code is reached, the program will abort

   
   And indeed, the program crashes with a complaint about an invalid instruction.
   Dump analysis shows that the program received a SIGILL signal. And more shows the structure va_list. For 32 bits this
   
   

   va = 0xfffc6918 ""

   
   those. va_list- just char*. For 64 bits:
   
   

   va = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0x7ffef147e7e0, reg_save_area = 0x7ffef147e720}}

   
   those. exactly what is described in SystemV ABI AMD64. compilation
   
   clang warns about undefined behavior and also suggests replacing floatwith double.
   
   
   Clang warning

   ./test.cpp:9:26: warning: second argument to 'va_arg' is of promotable type 'float'; this va_arg has undefined behavior because arguments will be promoted to 'double' [-Wvarargs]
           std::cout << va_arg(va, float) << std::endl;
                                   ^~~~~

   
   But the program does not fall, the 32-bit version gives:
   
   

   1
   0
   1073741824

   
   64-bit:
   
   

   1
   0
   3

   
   MSVC produces exactly the same results, but without warning, even with /Wall.
   
   Here one would assume that the difference between 32 and 64 bits is due to the fact that in the first case ABI passes the called function all the arguments through the stack, and in the second the first four (Windows) or six (Linux) arguments through the processor registers, the rest through stack [ wiki ]. But no, if you call foonot with 4 arguments, but from 19, and also output them, the result will be the same: a complete mess in the 32-bit version, and zeros for all floatin the 64-bit. Those. It's a matter of course in ABI, but not in the use of registers for passing arguments.
   
   
   Well, correctly, of course, do so

   void foo(int n, ...)
   {
       va_list va;
       va_start(va, n);
       std::cout << va_arg(va, int) << std::endl;
       std::cout << va_arg(va, double) << std::endl;
       std::cout << va_arg(va, int) << std::endl;
       va_end(va);
   }

   
   
4. It is wrong to pass as an unnamed argument an instance of a class with a non-trivial constructor or destructor. If, of course, the fate of this code worries you a little more than “compile and run here and now.”
   
   
   Wrong code

   #include <cstdarg>
   #include <iostream>
   struct Bar
   {
       Bar() { std::cout << "Bar default ctor" << std::endl; }
       Bar(const Bar&) { std::cout << "Bar copy ctor" << std::endl; }
       ~Bar() { std::cout << "Bar dtor" << std::endl; }
   };
   struct Cafe
   {
       Cafe() { std::cout << "Cafe default ctor" << std::endl; }
       Cafe(const Cafe&) { std::cout << "Cafe copy ctor" << std::endl; }
       ~Cafe() { std::cout << "Cafe dtor" << std::endl; }
   };
   void foo(int n, ...)
   {
       va_list va;
       va_start(va, n);
       std::cout << "Before va_arg" << std::endl;
       const auto b = va_arg(va, Bar);
       va_end(va);
   }
   int main()
   {
       Bar b;
       Cafe c;
       foo(1, b, c);
       return 0;
   }

   
   Stricter of all again clang . He simply refuses to compile this code due to the fact that the second argument is va_argnot a POD type, and warns that the program will crash when launched.
   
   
   Clang warning

   ./test.cpp:23:31: error: second argument to 'va_arg' is of non-POD type 'Bar' [-Wnon-pod-varargs]
       const auto b = va_arg(va, Bar);
                                 ^~~
   ./test.cpp:31:12: error: cannot pass object of non-trivial type 'Bar' through variadic function; call will abort at runtime [-Wnon-pod-varargs]
       foo(1, b, c);
              ^

   
   So it will be if all the same compile with the flag -Wno-non-pod-varargs.
   
   MSVC warns that the use in this case of types with non-trivial constructors is intolerable.
   
   
   MSVC warning

   d:\my documents\visual studio 2017\projects\test\test\main.cpp(31): warning C4840: непереносимое использование класса "Bar" в качестве аргумента в функции с переменным числом аргументов

   
   But the code is compiled and executed correctly. In the console, the following is obtained:
   
   
   Startup Result

   Bar default ctor
   Cafe default ctor
   Before va_arg
   Bar copy ctor
   Bar dtor
   Cafe dtor
   Bar dtor

   
   Those. a copy is created only at the time of the call va_arg, and the argument, it turns out, is passed by reference. Somehow not obvious, but the Standard permits.
   
   gcc 6.3.0 compiles without a single comment. At the output we have the same thing:
   
   
   Startup Result

   Bar default ctor
   Cafe default ctor
   Before va_arg
   Bar copy ctor
   Bar dtor
   Cafe dtor
   Bar dtor

   
   gcc 7.3.0 also warns about nothing, but the behavior changes:
   
   
   Startup Result

   Bar default ctor
   Cafe default ctor
   Cafe copy ctor
   Bar copy ctor
   Before va_arg
   Bar copy ctor
   Bar dtor
   Bar dtor
   Cafe dtor
   Cafe dtor
   Bar dtor

   
   Those. this version of the compiler passes arguments by value, and when called va_argit makes another copy. It would be fun to look for this difference when switching from the 6th to the 7th version of gcc, if designers / destructors have side effects.
   
   By the way, if you explicitly pass and request a reference to the class:
   
   
   Another wrong code

   void foo(int n, ...)
   {
       va_list va;
       va_start(va, n);
       std::cout << "Before va_arg" << std::endl;
       const auto& b = va_arg(va, Bar&);
       va_end(va);
   }
   int main()
   {
       Bar b;
       Cafe c;
       foo(1, std::ref(b), c);
       return 0;
   }

   
   then all compilers will give an error. As required by the Standard.
   
   In general, if you really want to, it is better to pass arguments by pointer.
   
   
   Like this

   void foo(int n, ...)
   {
       va_list va;
       va_start(va, n);
       std::cout << "Before va_arg" << std::endl;
       const auto* b = va_arg(va, Bar*);
       va_end(va);
   }
   int main()
   {
       Bar b;
       Cafe c;
       foo(1, &b, &c);
       return 0;
   }

   
   

Overload Resolution and Variable Functions

#include <iostream>
void foo(...)
{
    std::cout << "C variadic function" << std::endl;
}
void foo(int)
{
    std::cout << "Ordinary function" << std::endl;
}
int main()
{
    foo(1);
    foo(1ul);
    foo();
    return 0;
}

$ ./test 
Ordinary function
Ordinary function
C variadic function

#include <iostream>
void foo(...)
{
    std::cout << "C variadic function" << std::endl;
}
void foo()
{
    std::cout << "Ordinary function without arguments" << std::endl;
}
int main()
{
    foo(1);
    foo();
    return 0;
}

./test.cpp:16:9: error: call of overloaded ‘foo()’ is ambiguous
     foo();
         ^
./test.cpp:3:6: note: candidate: void foo(...)
 void foo(...)
      ^~~
./test.cpp:8:6: note: candidate: void foo()
 void foo()
      ^~~

When all the same it is necessary to use variable functions

• The most frequent and obvious case is backward compatibility. Here I will take both the use of third-party C libraries (my case with JNI) and the provision of the C API to the C ++ implementation.
  
• SFINAE . It is also very relevant here that in C ++ the variable function does not need to have named arguments, and that when resolving overloaded functions, the variable function is considered the last (if there is at least one argument). And like any other function, the variable function can only be declared, but never called.
  
  
  Example

  template <class T> 
  struct HasFoo
  {
  private:
      template <class U, class = decltype(std::declval<U>().foo())>
      static void detect(const U&);
      static int detect(...);
  public:
      static constexpr bool value = std::is_same<void, decltype(detect(std::declval<T>()))>::value;
  };

  
  Although in C ++ 14 you can do a little differently.
  
  
  Another example

  template <class T> 
  struct HasFoo
  {
  private:
      template <class U, class = decltype(std::declval<U>().foo())>
      static constexpr bool detect(const U*)
      {
          return true;
      }
      template <class U>
      static constexpr bool detect(...)
      {
          return false;
      }
  public:
      static constexpr bool value = detect<T>(nullptr);
  };

  
  And in this case it is already necessary to keep track of which arguments can be invoked detect(...). I would prefer to change a couple of lines and use a modern alternative to variable functions, devoid of all their flaws.
  

Variable patterns or how to create functions from an arbitrary number of arguments in modern C ++

• A template parameter pack is a template parameter, instead of which you can pass any number of template arguments (including 0);
  
• a function parameter pack ( function parameter pack ) - accordingly, this is a function parameter that accepts any (including 0) number of function arguments;
  
• and packet expansion ( pack expansion ) is the only thing that can be done with a package of parameters.
  

template <class ... Args>
void foo(const std::string& format, Args ... args)
{
    printf(format.c_str(), args...);
}

• The function parameter package can be expanded into another function's argument list.

  template <class ... Args>
  void bar(const std::string& format, Args ... args)
  {
      foo<Args...>(format.c_str(), args...);
  }

  
  
• or in the initialization list

  template <class ... Args>
  void foo(const std::string& format, Args ... args)
  {
      const auto list = {args...};
  }

  
  
• or to the lambda capture list

  template <class ... Args>
  void foo(const std::string& format, Args ... args)
  {
      auto lambda = [&format, args...] ()
      {
          printf(format.c_str(), args...);
      };
      lambda();
  }

  
  
• another batch of function parameters can be expanded in a convolution expression

  template <class ... Args>
  int foo(Args ... args)
  {
      return (0 + ... + args);
  }

  
  Convolutions appeared in C ++ 14 and can be unary and binary, right and left. The most complete description, as always, in the Standard [C ++ 17 8.1.6] .
  
• Both types of parameter packages can be expanded in the sizeof operator ...

  template <class ... Args>
  void foo(Args ... args)
  {
      const auto size1 = sizeof...(Args);
      const auto size2 = sizeof...(args);
  }

  
  

template <class ... Args>
void foo()
{
    using OneTuple = std::tuple<std::tuple<Args>...>;
    using NestTuple = std::tuple<std::tuple<Args...>>;
}

Example implementation of printf using variable patterns

void printf(const char* s)
{
    while (*s)
    {
        if (*s == '%' && *++s != '%')
            throw std::runtime_error("invalid format string: missing arguments");
        std::cout << *s++;
    }
}
template <typename T, typename ... Args>
void printf(const char* s, T value, Args ... args)
{
    while (*s)
    {
        if (*s == '%' && *++s != '%')
        {
            std::cout << value;
            return printf(++s, args...);
        }
        std::cout << *s++;
    }
    throw std::runtime_error("extra arguments provided to printf");
}

template <typename ... Args>
void printf(const std::string& fmt, const Args& ... args)
{
    size_t fmtIndex = 0;
    size_t placeHolders = 0;
    auto printFmt = [&fmt, &fmtIndex, &placeHolders]()
    {
        for (; fmtIndex < fmt.size(); ++fmtIndex)
        {
            if (fmt[fmtIndex] != '%')
                std::cout << fmt[fmtIndex];
            else if (++fmtIndex < fmt.size())
            {
                if (fmt[fmtIndex] == '%')
                    std::cout << '%';
                else
                {
                    ++fmtIndex;
                    ++placeHolders;
                    break;
                }
            }
        }
    };
    ((printFmt(), std::cout << args), ..., (printFmt()));
    if (placeHolders < sizeof...(args))
        throw std::runtime_error("extra arguments provided to printf");
    if (placeHolders > sizeof...(args))
        throw std::runtime_error("invalid format string: missing arguments");
}

Overload Resolution and Variable Template Functions

#include <iostream>
void foo(int)
{
    std::cout << "Ordinary function" << std::endl;
}
void foo()
{
    std::cout << "Ordinary function without arguments" << std::endl;
}
template <class T>
void foo(T)
{
    std::cout << "Template function" << std::endl;
}
template <class ... Args>
void foo(Args ...)
{
    std::cout << "Template variadic function" << std::endl;
}
int main()
{
    foo(1);
    foo();
    foo(2.0);
    foo(1, 2);
    return 0;
}

$ ./test 
Ordinary function
Ordinary function without arguments
Template function
Template variadic function

#include <iostream>
void foo(...)
{
    std::cout << "C variadic function" << std::endl;
}
template <class ... Args>
void foo(Args ...)
{
    std::cout << "Template variadic function" << std::endl;
}
int main()
{
    foo(1);
    foo();
    return 0;
}

$ ./test 
Template variadic function
C variadic function

A quick note on the speed of variable template functions.

Short summary and conclusion

• They do not know the number of their arguments or their types. The developer must use part of the function arguments in order to pass information about the rest.
  
• Implicitly raise the types of unnamed arguments (and the last named one). If you forget about it, you get indefinite behavior.
  
• Retain backward compatibility with pure C and therefore do not support passing arguments by reference.
  
• Prior to C ++ 11, arguments of non- POD types were not supported , but starting from C ++ 11, support for non-trivial types was left to the discretion of the compiler. Those. The behavior of the code depends on the compiler and its version.
  

• Know the number and types of all their arguments.
  
• Type safe, do not change the types of their arguments.
  
• Support the transmission of arguments in any form - by value, by pointer, by reference, by universal reference.
  
• Like any other C ++ functions, there are no restrictions on the types of arguments.
  
• When resolving overloads, they are considered last (second only to variable C functions), as the least specialized ones.
  

Literature and sources

• PJ Plauger, The Standard C Library
  
• Brian W. Kernighan and Dennis M. Ritchie, The C Programming Language, 1st Edition
  
• Brian W. Kernighan and Dennis M. Ritchie, The C Programming Language, 2nd Edition
  
• Standard C11, draft N1570
  
• C ++ 98 standard
  
• C ++ 03 standard
  
• Standard C ++ 11, draft N3337
  
• Standard C ++ 14, draft N4296
  
• Standard C ++ 17, draft N4659
  

PS