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 can have more than parameters. For this, the list of its parameters must end with an ellipsis, but at least one fixed parameter must also be present [C11 6.9.1 / 8] :
  
  

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

• Information on the number and types of arguments corresponding to the ellipsis is not transferred to the function itself. Those. after the last named parameter ( parm2 in the example above) [C11 6.7.6.3/9] .
  
• To access these arguments, use the va_list type and 4 (3 to C11 standard) macros in the <stdarg.h> header: va_start , va_arg , va_end and va_copy (starting with 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; } 

  
  Yes, the function does not know how many arguments it has. She needs to somehow pass this number. In this case, through a single named argument (another common option is to pass NULL as the last argument, as in execl , or 0).
• The last named argument cannot have a register storage class, 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 the type char , short (with or without a sign) or float , then the corresponding parameters should be treated as int , int (with or without a sign) or double . Otherwise, the behavior is undefined [C11 7.16.1.1/2] .
• The type va_list 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 C language function 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 ++

• Since C ++, in contrast to C, allows you to get the address of a register variable, then the last named argument of a variable function can have this storage class.
  
• Since 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.
  
• Since in C ++ there is no concept of “ increasing the type of argument by default ”, then the phrase
  

  parmN is not the case.

  need to be replaced by

  parmN is 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 short or 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 va_start argument va_start 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 query the va_arg type to be va_arg - char , short or 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. gcc when compiling produces a warning that you need to use double instead of float , and if this code is still executed, 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 also shows the structure of va_list . For 32 bits this
   
   

    va = 0xfffc6918 "" 

   
   those. va_list is 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.
   
   clang when compiling warns about undefined behavior and also suggests replacing float with 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 could 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 foo not with 4 arguments, but from 19, and also output them, the result will be the same: full mash in the 32-bit version, and zeros for all float in 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 va_arg not a POD type, and warns that the program will va_arg 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 you still compile with the -Wno-non-pod-varargs flag.
   
   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. The following is obtained in the console:
   
   
   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 moment of calling va_arg , and the argument, it turns out, is passed by reference. Somehow not obvious, but the Standard allows.
   
   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 doesn't warn about anything either, 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 you call va_arg it 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 transmit 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 is it still worth using 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 a C ++ implementation.
  
• SFINAE . Here it is very opportune that in C ++ the variable function does not have 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 called by detect(...) . I would prefer to change a couple of lines and use a modern alternative to variable functions, devoid of all their flaws.
  

Variable templates 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 in 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 of implementing 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 an undefined 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 transfer 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.
  
• ( C ), .
  

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