C ++: uma sessão de arqueologia espontânea e por que você não deve usar funções variáveis ​​no estilo de C

O que dizer das reticências e va_list é dito no Padrão

• Você pode declarar uma função que recebe um número arbitrário de argumentos. I.e. uma função pode ter mais argumentos que parâmetros. Para fazer isso, a lista de seus parâmetros deve terminar com reticências, mas pelo menos um parâmetro fixo [C11 6.9.1 / 8] também deve estar presente:
  
  

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

• As informações sobre o número e os tipos de argumentos correspondentes às reticências não são passadas para a própria função. I.e. após o último parâmetro nomeado ( parm2 no exemplo acima) [C11 6.7.6.3/9] .
  
• Para acessar esses argumentos, você deve usar o tipo va_list declarado no cabeçalho <stdarg.h> e 4 macros (3 antes do padrão C11): va_start , va_arg , va_end e va_copy (começando com C11) [C11 7.16] .
  
  
  Por exemplo

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

  
  Sim, a função não sabe quantos argumentos ela possui. Ela precisa de alguma forma passar esse número. Nesse caso, por meio de um único argumento nomeado (outra opção comum é passar NULL como o último argumento, como em execl ou 0).
• O último argumento nomeado não pode ter uma classe de armazenamento de register , não pode ser uma função ou uma matriz. Caso contrário, comportamento indefinido [C11 7.16.1.4/4] .
• Além disso, ao último argumento nomeado e a todos os sem nome, é aplicada a " promoção de argumentos padrão " ( promoção de argumentos padrão ; se houver uma boa tradução desse conceito para o russo, eu o uso com prazer). Isso significa que se o argumento tiver o tipo char , short (com ou sem um sinal) ou float , os parâmetros correspondentes deverão ser acessados ​​como int , int (com ou sem um sinal) ou double . Caso contrário, comportamento indefinido [C11 7.16.1.1/2] .
• Sobre o tipo va_list , va_list -se apenas que ele é declarado em <stdarg.h> e está completo (ou seja, é conhecido o tamanho de um objeto desse tipo) [C11 7.16 / 3] .

Porque Mas porque!

A propósito, não há maneira aceitável de escrever uma função portátil de um número arbitrário de argumentos, porque Não existe uma maneira portátil para a função chamada descobrir quantos argumentos foram passados ​​para ela quando chamada. ... printf , a função mais típica da linguagem C de um número arbitrário de argumentos, ... não é portátil e deve ser implementada 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]; 

Funções variáveis ​​em C ++

• Porque C ++, ao contrário de C, permite obter o endereço de register de variáveis, então o último argumento nomeado de uma função variável pode ter essa classe de armazenamento.
  
• Porque os links que apareceram no C ++ violam a regra não escrita das funções da variável C - o tamanho do parâmetro deve corresponder ao tamanho do tipo declarado -, então o último argumento nomeado não pode ser um link. Caso contrário, comportamento vago.
  
• Porque em C ++, não há conceito de " aumentar o tipo de argumento por padrão ", então a frase
  

  Se o parâmetro parmN for declarado com ... um tipo que não é compatível com o tipo resultante após a aplicação das promoções de argumentos padrão, o comportamento será indefinido

  deve ser substituído por

  Se o parâmetro parmN for declarado com ... um tipo que não é compatível com o tipo resultante ao transmitir um argumento para o qual não há parâmetro, o comportamento será indefinido

Como usar funções variáveis ​​de maneira fácil e incorreta

1. É incorreto declarar o último argumento nomeado com um tipo promovido, ou seja, char , char signed char , signed char unsigned char , singed short , unsigned short ou float . O resultado de acordo com a Norma será um comportamento 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 os compiladores que eu tinha em mãos (gcc, clang, MSVC), apenas o clang emitiu um aviso.
   
   
   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); ^ 

   
   E, embora em todos os casos o código compilado tenha se comportado corretamente, você não deve contar com ele.
   
   
   Vai dar certo

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

   
   
2. É incorreto declarar o último argumento nomeado como referência. Qualquer link. O padrão neste caso também promete um comportamento 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); } 

   
   O gcc 7.3.0 compilou esse código sem um único comentário. O idioma 6.0.0 emitiu um aviso, mas ainda o compilou.
   
   
   Clang warning

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

   
   Nos dois casos, o programa funcionou corretamente (por sorte, você não pode confiar nele). Mas o MSVC 19.15.26730 se destacou - ele se recusou a compilar o código, porque va_start argumento va_start não va_start ser uma referência.
   
   
   Erro do 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 

   
   
   Bem, a opção correta se parece, por exemplo, com esta

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

   
   
3. É errado solicitar ao va_arg aumentar o tipo - char , short ou 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; } 

   
   É mais interessante aqui. O gcc na compilação avisa que é necessário usar double vez de float , e se esse código ainda for executado, o programa terminará com um erro.
   
   
   Aviso do Gcc

    ./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 fato, o programa trava com uma reclamação sobre uma instrução inválida.
   Uma análise de despejo mostra que o programa recebeu um sinal SIGILL. E também mostra a estrutura do va_list . Para 32 bits, isso é
   
   

    va = 0xfffc6918 "" 

   
   isto é va_list é apenas char* . Para 64 bits:
   
   

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

   
   isto é exatamente o que é descrito em SystemV ABI AMD64.
   
   clang na compilação alerta para um comportamento indefinido e também sugere a substituição de float por 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; ^~~~~ 

   
   Mas o programa não falha mais, a versão de 32 bits produz:
   
   

    1 0 1073741824 

   
   64 bits:
   
   

    1 0 3 

   
   O MSVC produz exatamente os mesmos resultados, apenas sem aviso, mesmo com /Wall .
   
   Aqui, pode-se supor que a diferença entre 32 e 64 bits se deve ao fato de que, no primeiro caso, a ABI passa todos os argumentos da pilha para a função chamada e, no segundo, os quatro primeiros argumentos (Windows) ou seis (Linux) através do processador registram, o restante através pilha [ wiki ]. Mas não, se você chamar foo não com 4 argumentos, mas com 19, e produzi-los da mesma maneira, o resultado será o mesmo: confusão total na versão de 32 bits e zeros para todos os float na de 64 bits. I.e. o ponto está claro na ABI, mas não no uso de registradores para passar argumentos.
   
   
   Bem, é claro, é certo fazê-lo

    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. É incorreto passar uma instância de uma classe com um construtor ou destruidor não trivial como um argumento sem nome. A menos, é claro, que o destino desse código o excite pelo menos um pouco mais do que "compile e execute aqui e agora".
   
   
   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 é o mais rígido de todos novamente. Ele simplesmente se recusa a compilar esse código porque o segundo argumento, va_arg não va_arg tipo POD e alerta que o programa va_arg na inicialização.
   
   
   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); ^ 

   
   Assim será, se você ainda compilar com o -Wno-non-pod-varargs .
   
   A MSVC adverte que o uso de tipos com construtores não triviais nesse caso não é portátil.
   
   
   Aviso do MSVC

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

   
   Mas o código compila e executa corretamente. O seguinte é obtido no console:
   
   
   Resultado do lançamento

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

   
   I.e. uma cópia é criada apenas no momento da chamada va_arg , e o argumento, ao que parece, é passado por referência. De alguma forma, não é óbvio, mas o Padrão permite.
   
   O gcc 6.3.0 é compilado sem um único comentário. A saída é a mesma:
   
   
   Resultado do lançamento

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

   
   O gcc 7.3.0 também não avisa sobre nada, mas o comportamento está mudando:
   
   
   Resultado do lançamento

    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 

   
   I.e. essa versão do compilador passa argumentos por valor e, quando chamada, va_arg faz outra cópia. Seria divertido procurar essa diferença ao alternar da sexta para a sétima versão do gcc se os construtores / destruidores tiverem efeitos colaterais.
   
   A propósito, se você passar e solicitar explicitamente uma referência à classe:
   
   
   Outro código errado

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

   
   todos os compiladores lançarão um erro. Conforme exigido pela Norma.
   
   Em geral, se você realmente quiser, é melhor passar argumentos por ponteiro.
   
   
   Assim

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

   
   

Resolução de sobrecarga e funções variáveis

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

Quando vale a pena usar funções variáveis

• O caso mais comum e óbvio é a compatibilidade com versões anteriores. Aqui, incluirei o uso de bibliotecas C de terceiros (meu caso com JNI) e o fornecimento da API C para a implementação C ++.
  
• SFINAE . É muito útil aqui que, em C ++, não é necessário que uma função variável tenha argumentos nomeados e que, ao resolver funções sobrecarregadas, uma função variável é considerada a última (se houver pelo menos um argumento). E, como qualquer outra função, uma função variável só pode ser declarada, mas nunca chamada.
  
  
  Exemplo

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

  
  Embora no C ++ 14 você possa fazer um pouco diferente.
  
  
  Outro exemplo

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

  
  E, neste caso, já é necessário observar com que argumentos detect(...) podem ser chamados. Eu preferiria mudar algumas linhas e usar uma alternativa moderna a funções variáveis, desprovida de todas as suas deficiências.
  

Modelos de variantes ou como criar funções a partir de um número arbitrário de argumentos no C ++ moderno

• parâmetros do modelo de pacote ( template parâmetro pacote ) - é um modelo de parâmetro, em vez de que é possível transferir qualquer (incluindo 0) número de argumento modelo;
  
• um pacote de parâmetros de função (pacote de parâmetros de função ) - portanto, este é um parâmetro de função que aceita qualquer número (incluindo 0) de argumentos de função;
  
• e a expansão do pacote ( expansão do pacote ) é a única coisa que pode ser feita com o pacote de parâmetros.
  

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

• O pacote de parâmetros da função pode ser expandido para a lista de argumentos de outra função

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

  
  
• ou para a lista de inicialização

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

  
  
• ou para a 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(); } 

  
  
• outro pacote de parâmetros de função pode ser expandido em uma expressão de convolução

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

  
  As convoluções apareceram em C ++ 14 e podem ser unárias e binárias, direita e esquerda. A descrição mais completa, como sempre, está no Padrão [C ++ 17 8.1.6] .
  
• os dois tipos de pacotes de parâmetros podem ser expandidos para 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...>>; } 

Exemplo de implementação de printf usando modelos variáveis

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

Resolução de sobrecarga e funções de modelo variável

 #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 

Uma observação rápida sobre a velocidade das funções de modelo variável

Breve resumo e conclusão

• Eles não sabem o número de seus argumentos ou seus tipos. O desenvolvedor deve usar parte dos argumentos da função para passar informações sobre o restante.
  
• Aumente implicitamente os tipos de argumentos não nomeados (e o último nomeado). Se você se esquecer disso, terá um comportamento vago.
  
• Eles mantêm compatibilidade com o C puro e, portanto, não suportam a passagem de argumentos por referência.
  
• Antes do C ++ 11, os argumentos que não eram do tipo POD não eram suportados e, desde o C ++ 11, o suporte para tipos não triviais era deixado a critério do compilador. I.e. O comportamento do código depende do compilador e de sua versão.
  

• Conheça o número e os tipos de todos os seus argumentos.
  
• Digite safe, não altere os tipos de seus argumentos.
  
• Eles suportam a passagem de argumentos de qualquer forma - por valor, por ponteiro, por referência, por link universal.
  
• Como qualquer outra função C ++, não há restrições nos tipos de argumentos.
  
• ( C ), .
  

Literatura e Fontes

• PJ Plauger, Biblioteca Padrão C
  
• Brian W. Kernighan e Dennis M. Ritchie, Linguagem de Programação C, 1ª Edição
  
• Brian W. Kernighan e Dennis M. Ritchie, Linguagem de Programação C, 2ª Edição
  
• Norma C11, projecto N1570
  
• Padrão C ++ 98
  
• Padrão C ++ 03
  
• Padrão C ++ 11, rascunho N3337
  
• Padrão C ++ 14, projeto N4296
  
• Padrão C ++ 17, rascunho N4659
  

PS