C ++: una sesión de arqueología espontánea y por qué no debes usar funciones variables al estilo de C

¿Qué pasa con los puntos suspensivos y va_list se dice en el Estándar?

• Puede declarar una función que tome un número arbitrario de argumentos. Es decir Una función puede tener más argumentos que parámetros. Para hacer esto, la lista de sus parámetros debe terminar con puntos suspensivos, pero al menos un parámetro fijo [C11 6.9.1 / 8] también debe estar presente:
  
  

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

• La información sobre el número y los tipos de argumentos correspondientes a los puntos suspensivos no se pasa a la función misma. Es decir después del último parámetro nombrado ( parm2 en el ejemplo anterior) [C11 6.7.6.3/9] .
  
• Para acceder a estos argumentos, debe usar el tipo va_list declarado en el <stdarg.h> y 4 macros (3 antes del estándar C11): va_start , va_arg , va_end y va_copy (comenzando con C11) [C11 7.16] .
  
  
  Por ejemplo

   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; } 

  
  Sí, la función no sabe cuántos argumentos tiene. Ella necesita pasar de alguna manera este número. En este caso, a través de un único argumento con nombre (otra opción común es pasar NULL como último argumento, como en execl , o 0).
• El último argumento nombrado no puede tener una clase de almacenamiento de register ; no puede ser una función o una matriz. De lo contrario, comportamiento indefinido [C11 7.16.1.4/4] .
• Además, para el último argumento nombrado y para todos los sin nombre, se aplica la " promoción de argumento por defecto " ( promoción de argumento por defecto ; si hay una buena traducción de este concepto al ruso, con mucho gusto lo uso). Esto significa que si el argumento tiene el tipo char , short (con o sin signo) o float , entonces se debe acceder a los parámetros correspondientes como int , int (con o sin signo) o double . De lo contrario, comportamiento indefinido [C11 7.16.1.1/2] .
• Sobre el tipo va_list solo se dice que está declarado en <stdarg.h> y está completo (es decir, se conoce el tamaño de un objeto de este tipo) [C11 7.16 / 3] .

Por qué Pero porque!

Por cierto, no hay una forma aceptable de escribir una función portátil de un número arbitrario de argumentos, porque No hay una forma portátil para que la función llamada descubra cuántos argumentos se le pasaron cuando se llamó. ... printf , la función de lenguaje C más típica de un número arbitrario de argumentos, ... no es portátil y debe implementarse para cada sistema.

 #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]; 

Funciones variables en C ++

• Porque C ++, a diferencia de C, le permite obtener la dirección de register de las variables, luego el último argumento nombrado de una función variable puede tener esta clase de almacenamiento.
  
• Porque los enlaces que aparecieron en C ++ violan la regla no escrita de las funciones variables de C (el tamaño del parámetro debe coincidir con el tamaño de su tipo declarado), entonces el último argumento nombrado no puede ser un enlace. De lo contrario, comportamiento vago.
  
• Porque en C ++ no existe el concepto de " elevar el tipo de argumento por defecto ", entonces la frase
  

  Si el parámetro parmN se declara con ... un tipo que no es compatible con el tipo que resulta después de la aplicación de las promociones de argumento predeterminadas, el comportamiento es indefinido

  debe ser reemplazado por

  Si el parámetro parmN se declara con ... un tipo que no es compatible con el tipo que resulta al pasar un argumento para el que no hay parámetro, el comportamiento es indefinido

Cómo usar funciones variables de manera fácil e incorrecta

1. Es incorrecto declarar el último argumento nombrado con un tipo promocionado, es decir char , char signed char , unsigned char , singed short , unsigned short o float . El resultado según la Norma será un comportamiento indefinido.
   
   
   Código inválido

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

   
   
   
   De todos los compiladores que tenía a mano (gcc, clang, MSVC), solo clang emitió una advertencia.
   
   
   Advertencia de argot

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

   
   Y aunque en todos los casos el código compilado se comportó correctamente, no debe contar con él.
   
   
   Estara bien

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

   
   
2. Es incorrecto declarar el último argumento nombrado como referencia. Cualquier enlace El estándar en este caso también promete un comportamiento indefinido.
   
   
   Código inválido

    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 compiló este código sin un solo comentario. lang 6.0.0 emitió una advertencia, pero aún así la compiló.
   
   
   Advertencia de argot

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

   
   En ambos casos, el programa funcionó correctamente (por suerte, no puede confiar en él). Pero MSVC 19.15.26730 se distinguió: se negó a compilar el código, porque va_start argumento va_start no va_start ser una referencia.
   
   
   Error de MSVC

    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 

   
   
   Bueno, la opción correcta se ve, por ejemplo, así

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

   
   
3. Es incorrecto solicitar va_arg elevar el tipo - char , short o float .
   
   
   Código inválido

    #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; } 

   
   Es más interesante aquí. gcc at compilation advierte que es necesario usar double lugar de float , y si este código aún se ejecuta, el programa terminará con un error.
   
   
   Advertencia de CCG

    ./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 

   
   De hecho, el programa se bloquea con una queja sobre una instrucción no válida.
   Un análisis de volcado muestra que el programa recibió una señal SIGILL. Y también muestra la estructura de va_list . Para 32 bits esto es
   
   

    va = 0xfffc6918 "" 

   
   es decir va_list es solo char* . Para 64 bits:
   
   

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

   
   es decir exactamente lo que se describe en SystemV ABI AMD64.
   
   El sonido metálico en la compilación advierte sobre un comportamiento indefinido y también sugiere reemplazar el float por el double .
   
   
   Advertencia de argot

    ./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; ^~~~~ 

   
   Pero el programa ya no se bloquea, la versión de 32 bits produce:
   
   

    1 0 1073741824 

   
   64 bit:
   
   

    1 0 3 

   
   MSVC produce exactamente los mismos resultados, solo sin previo aviso, incluso con /Wall .
   
   Aquí se podría suponer que la diferencia entre 32 y 64 bits se debe al hecho de que en el primer caso, el ABI pasa todos los argumentos a través de la pila a la función llamada, y en el segundo, los primeros cuatro (Windows) o seis (Linux) argumentos a través de los registros del procesador, el resto a través de apilar [ wiki ]. Pero no, si llama a foo no con 4 argumentos, sino con 19, y los genera de la misma manera, el resultado será el mismo: desorden completo en la versión de 32 bits y ceros para todos los float en la de 64 bits. Es decir el punto es, por supuesto, en ABI, pero no en el uso de registros para pasar argumentos.
   
   
   Bueno, claro, por supuesto, hacerlo

    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. Es incorrecto pasar una instancia de una clase con un constructor o destructor no trivial como argumento sin nombre. A menos que, por supuesto, el destino de este código lo entusiasme al menos un poco más que "compilar y ejecutar aquí y ahora".
   
   
   Código inválido

    #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; } 

   
   Clang es el más estricto de todos Simplemente se niega a compilar este código porque el segundo argumento, va_arg no va_arg un tipo de POD, y advierte que el programa se va_arg en el inicio.
   
   
   Advertencia de argot

    ./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); ^ 

   
   Así será, si aún compila con el indicador -Wno-non-pod-varargs .
   
   MSVC advierte que el uso de tipos con constructores no triviales en este caso no es portátil.
   
   
   Advertencia de MSVC

    d:\my documents\visual studio 2017\projects\test\test\main.cpp(31): warning C4840:    "Bar"          

   
   Pero el código se compila y se ejecuta correctamente. Lo siguiente se obtiene en la consola:
   
   
   Resultado de lanzamiento

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

   
   Es decir se crea una copia solo al momento de llamar a va_arg , y resulta que el argumento se pasa por referencia. De alguna manera no es obvio, pero la Norma lo permite.
   
   gcc 6.3.0 compila sin un solo comentario. La salida es la misma:
   
   
   Resultado de lanzamiento

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

   
   gcc 7.3.0 tampoco advierte sobre nada, pero el comportamiento está cambiando:
   
   
   Resultado de lanzamiento

    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 

   
   Es decir Esta versión del compilador pasa argumentos por valor, y cuando se llama, va_arg hace otra copia. Sería divertido buscar esta diferencia al cambiar de la sexta a la séptima versión de gcc si los constructores / destructores tienen efectos secundarios.
   
   Por cierto, si pasa explícitamente y solicita una referencia a la clase:
   
   
   Otro código equivocado

    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; } 

   
   entonces todos los compiladores arrojarán un error. Según lo requiera la Norma.
   
   En general, si realmente lo desea, es mejor pasar los argumentos por puntero.
   
   
   Como este

    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; } 

   
   

Resolución de sobrecarga y funciones variables

 #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() ^~~ 

Sin embargo, ¿cuándo vale la pena usar funciones variables?

• El caso más común y obvio es la compatibilidad con versiones anteriores. Aquí incluiré el uso de bibliotecas C de terceros (mi caso con JNI) y la provisión de la API C para la implementación de C ++.
  
• SFINAE Aquí, es muy útil que en C ++ una función variable no tenga que tener argumentos nombrados, y que al resolver funciones sobrecargadas, una función variable se considere la última (si hay al menos un argumento). Y como cualquier otra función, una función variable solo puede declararse, pero nunca llamarse.
  
  
  Ejemplo

   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; }; 

  
  Aunque en C ++ 14 puedes hacerlo un poco diferente.
  
  
  Otro ejemplo

   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); }; 

  
  Y en este caso ya es necesario mirar con qué argumentos se puede llamar detect(...) . Preferiría cambiar un par de líneas y usar una alternativa moderna a las funciones variables, desprovistas de todas sus deficiencias.
  

Plantillas variantes o cómo crear funciones a partir de un número arbitrario de argumentos en C ++ moderno

• parámetros de plantilla de paquete ( paquete de parámetro de plantilla ) - es una plantilla de parámetros, en lugar de la que es posible transferir cualquier (incluyendo 0) número de argumento de plantilla;
  
• un paquete de parámetros de función (paquete de parámetros de función ): en consecuencia, este es un parámetro de función que toma cualquier (incluido 0) número de argumentos de función;
  
• y la expansión del paquete ( expansión del paquete ) es lo único que se puede hacer con el paquete de parámetros.
  

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

• El paquete de parámetros de función se puede expandir a la lista de argumentos de otra función

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

  
  
• o a la lista de inicialización

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

  
  
• o a la lista de captura lambda

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

  
  
• otro paquete de parámetros de función puede expandirse en una expresión de convolución

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

  
  Las convoluciones aparecieron en C ++ 14 y pueden ser unarias y binarias, derecha e izquierda. La descripción más completa, como siempre, está en el Estándar [C ++ 17 8.1.6] .
  
• ambos tipos de paquetes de parámetros se pueden ampliar en el operador sizeof ...

   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...>>; } 

Ejemplo de implementación de printf usando plantillas variables

 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"); } 

Resolución de sobrecarga y funciones de plantilla variable

 #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 

Una nota rápida sobre la velocidad de las funciones de plantilla variable

Breve resumen y conclusión

• No conocen ni el número de sus argumentos ni sus tipos. El desarrollador debe usar parte de los argumentos de la función para pasar información sobre el resto.
  
• Levanta implícitamente los tipos de argumentos sin nombre (y el último nombre). Si te olvidas de eso, obtienes un comportamiento vago.
  
• Mantienen la compatibilidad con versiones anteriores de C puro y, por lo tanto, no admiten pasar argumentos por referencia.
  
• Antes de C ++ 11, no se admitían argumentos que no fueran de tipos POD , y desde C ++ 11, el soporte para tipos no triviales se dejaba a discreción del compilador. Es decir El comportamiento del código depende del compilador y su versión.
  

• Conozca el número y los tipos de todos sus argumentos.
  
• Escriba safe, no cambie los tipos de sus argumentos.
  
• Admiten pasar argumentos en cualquier forma: por valor, por puntero, por referencia, por enlace universal.
  
• Al igual que cualquier otra función de C ++, no hay restricciones en los tipos de argumentos.
  
• ( C ), .
  

Literatura y Fuentes

• PJ Plauger, la biblioteca estándar de C
  
• Brian W. Kernighan y Dennis M. Ritchie, The C Programming Language, 1st Edition
  
• Brian W. Kernighan y Dennis M. Ritchie, The C Programming Language, 2nd Edition
  
• Norma C11, borrador N1570
  
• C ++ 98 estándar
  
• C ++ 03 estándar
  
• C ++ 11 estándar, borrador N3337
  
• Estándar C ++ 14, borrador N4296
  
• C ++ 17 estándar, borrador N4659
  

PS