Maneira eficiente de retornar um std :: vector em c ++

Quantos dados são copiados, ao retornar um std :: vector em uma função e quão grande será a otimização para colocar o std :: vector no free-store (no heap) e retornar um ponteiro, isto é:

std::vector *f()
{
  std::vector *result = new std::vector();
  /*
    Insert elements into result
  */
  return result;
} 

mais eficiente do que:

std::vector f()
{
  std::vector result;
  /*
    Insert elements into result
  */
  return result;
} 

?

Em C ++ 11, esta é a forma preferida:

std::vector<X> f();

Ou seja, retorno por valor.

Com o C ++ 11, std::vectortem semântica de movimento, o que significa que o vetor local declarado em sua função será movido no retorno e em alguns casos até mesmo o movimento pode ser omitido pelo compilador.

Você deve retornar por valor.

O padrão possui uma característica específica para melhorar a eficiência do retorno por valor. É chamado de "elisão de cópia" e, mais especificamente, neste caso, a "otimização do valor de retorno nomeado (NRVO)".

Os compiladores não precisam implementá-lo, mas, novamente, os compiladores não precisam implementar o inlining de funções (ou realizar qualquer otimização). Mas o desempenho das bibliotecas padrão pode ser muito pobre se os compiladores não otimizam, e todos os compiladores sérios implementam inlining e NRVO (e outras otimizações).

Quando o NRVO for aplicado, não haverá cópia no seguinte código:

std::vector<int> f() {
    std::vector<int> result;
    ... populate the vector ...
    return result;
}

std::vector<int> myvec = f();

Mas o usuário pode querer fazer isso:

std::vector<int> myvec;
... some time later ...
myvec = f();

A elisão de cópia não impede uma cópia aqui porque é uma atribuição em vez de uma inicialização. No entanto, você ainda deve retornar por valor. Em C ++ 11, a atribuição é otimizada por algo diferente, chamado "mover semântica". Em C ++ 03, o código acima causa uma cópia e, embora em teoria um otimizador possa evitá-lo, na prática é muito difícil. Então myvec = f(), em vez de , em C ++ 03, você deve escrever isto:

std::vector<int> myvec;
... some time later ...
f().swap(myvec);

Existe outra opção, que é oferecer uma interface mais flexível ao usuário:

template <typename OutputIterator> void f(OutputIterator it) {
    ... write elements to the iterator like this ...
    *it++ = 0;
    *it++ = 1;
}

Você também pode oferecer suporte à interface baseada em vetor existente além disso:

std::vector<int> f() {
    std::vector<int> result;
    f(std::back_inserter(result));
    return result;
}

Isso pode ser menos eficiente do que seu código existente, se seu código existente usar reserve()de uma forma mais complexa do que apenas uma quantia fixa inicial. Mas se o seu código existente basicamente chamar push_backo vetor repetidamente, esse código baseado em modelo deve ser tão bom.

É hora de postar uma resposta sobre RVO , eu também ...

Se você retornar um objeto por valor, o compilador geralmente otimiza isso para que não seja construído duas vezes, uma vez que é supérfluo construí-lo na função como temporário e depois copiá-lo. Isso é chamado de otimização do valor de retorno: o objeto criado será movido em vez de ser copiado.

Um idioma comum pré-C ++ 11 é passar uma referência ao objeto que está sendo preenchido.

Então, não há cópia do vetor.

void f( std::vector & result )
{
  /*
    Insert elements into result
  */
} 

Se o compilador oferecer suporte a Otimização de valor de retorno nomeado ( http://msdn.microsoft.com/en-us/library/ms364057(v=vs.80).aspx ), você poderá retornar diretamente o vetor, desde que não haja:

1. Caminhos diferentes retornando objetos com nomes diferentes
2. Vários caminhos de retorno (mesmo se o mesmo objeto nomeado for retornado em todos os caminhos) com estados EH introduzidos.
3. O objeto nomeado retornado é referenciado em um bloco asm embutido.

NRVO otimiza o construtor de cópia redundante e chamadas de destruidor e, portanto, melhora o desempenho geral.

Não deve haver nenhuma diferença real em seu exemplo.

vector<string> getseq(char * db_file)

E se você quiser imprimir em main (), você deve fazer em um loop.

int main() {
     vector<string> str_vec = getseq(argv[1]);
     for(vector<string>::iterator it = str_vec.begin(); it != str_vec.end(); it++) {
         cout << *it << endl;
     }
}

Por melhor que seja "retorno por valor", é o tipo de código que pode levar a um erro. Considere o seguinte programa:

    #include <string>
    #include <vector>
    #include <iostream>
    using namespace std;
    static std::vector<std::string> strings;
    std::vector<std::string> vecFunc(void) { return strings; };
    int main(int argc, char * argv[]){
      // set up the vector of strings to hold however
      // many strings the user provides on the command line
      for(int idx=1; (idx<argc); ++idx){
         strings.push_back(argv[idx]);
      }

      // now, iterate the strings and print them using the vector function
      // as accessor
      for(std::vector<std::string>::interator idx=vecFunc().begin(); (idx!=vecFunc().end()); ++idx){
         cout << "Addr: " << idx->c_str() << std::endl;
         cout << "Val:  " << *idx << std::endl;
      }
    return 0;
    };

• P: O que acontecerá quando o acima for executado? R: Um coredump.
• P: Por que o compilador não detectou o erro? R: Porque o programa é sintaticamente, embora não semanticamente, correto.
• P: O que acontece se você modificar vecFunc () para retornar uma referência? R: O programa é executado até a conclusão e produz o resultado esperado.
• P: Qual é a diferença? R: O compilador não precisa criar e gerenciar objetos anônimos. O programador instruiu o compilador a usar exatamente um objeto para o iterador e para a determinação do ponto de extremidade, em vez de dois objetos diferentes, como faz o exemplo quebrado.

O programa errôneo acima não indicará erros, mesmo se alguém usar as opções de relatórios GNU g ++ -Wall -Wextra -Weffc ++

Se você deve produzir um valor, o seguinte funcionaria no lugar de chamar vecFunc () duas vezes:

   std::vector<std::string> lclvec(vecFunc());
   for(std::vector<std::string>::iterator idx=lclvec.begin(); (idx!=lclvec.end()); ++idx)...

O acima também não produz objetos anônimos durante a iteração do loop, mas requer uma possível operação de cópia (que, como alguns observam, pode ser otimizada em algumas circunstâncias. Mas o método de referência garante que nenhuma cópia será produzida. Acreditando que o compilador será executar RVO não substitui a tentativa de construir o código mais eficiente possível. Se você pode questionar a necessidade de o compilador fazer RVO, você está à frente do jogo.

   vector<string> func1() const
   {
      vector<string> parts;
      return vector<string>(parts.begin(),parts.end()) ;
   }