Manera eficiente de devolver un std :: vector en c ++

Cuántos datos se copian, cuando se devuelve un std :: vector en una función y qué tan grande será la optimización para colocar el std :: vector en free-store (en el montón) y devolver un puntero en su lugar, es decir, es:

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

más eficiente que:

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

?

En C ++ 11, esta es la forma preferida:

std::vector<X> f();

Es decir, retorno por valor.

Con C ++ 11, std::vectortiene movimiento semántica, lo que significa el local de vector declarado en su función se trasladó a la entrega y en algunos casos incluso el movimiento puede ser elidido por el compilador.

Debería devolver por valor.

El estándar tiene una característica específica para mejorar la eficiencia de la devolución por valor. Se llama "copia elisión", y más específicamente en este caso la "optimización del valor de retorno con nombre (NRVO)".

Los compiladores no tienen que implementarlo, pero de nuevo los compiladores no tienen que implementar la función de alineación (o realizar ninguna optimización). Pero el rendimiento de las bibliotecas estándar puede ser bastante pobre si los compiladores no optimizan, y todos los compiladores serios implementan inlining y NRVO (y otras optimizaciones).

Cuando se aplica NRVO, no habrá copia en el siguiente código:

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

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

Pero el usuario puede querer hacer esto:

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

Copiar la elisión no impide una copia aquí porque es una asignación en lugar de una inicialización. Sin embargo, aún debe devolver por valor. En C ++ 11, la asignación se optimiza mediante algo diferente, llamado "semántica de movimiento". En C ++ 03, el código anterior causa una copia, y aunque en teoría un optimizador podría evitarlo, en la práctica es demasiado difícil. Entonces myvec = f(), en lugar de , en C ++ 03 debes escribir esto:

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

Existe otra opción, que es ofrecer una interfaz más flexible al usuario:

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

Luego, también puede admitir la interfaz existente basada en vectores además de eso:

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

Esto podría ser menos eficiente que su código existente, si su código existente se usa reserve()de una manera más compleja que solo una cantidad fija por adelantado. Pero si su código existente básicamente llama push_backal vector repetidamente, entonces este código basado en plantillas debería ser tan bueno.

Es hora de que publique una respuesta sobre RVO , yo también ...

Si devuelve un objeto por valor, el compilador a menudo lo optimiza para que no se construya dos veces, ya que es superfluo construirlo en la función como temporal y luego copiarlo. Esto se denomina optimización del valor de retorno: el objeto creado se moverá en lugar de copiarse.

Un modismo común anterior a C ++ 11 es pasar una referencia al objeto que se está completando.

Entonces no hay copia del vector.

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

Si el compilador admite la optimización de valor devuelto con nombre ( http://msdn.microsoft.com/en-us/library/ms364057(v=vs.80).aspx ), puede devolver directamente el vector siempre que no haya:

1. Diferentes rutas que devuelven diferentes objetos con nombre
2. Varias rutas de retorno (incluso si se devuelve el mismo objeto con nombre en todas las rutas) con estados EH introducidos.
3. El objeto con nombre devuelto se referencia en un bloque asm en línea.

NRVO optimiza las llamadas redundantes al constructor y destructor de copias y, por lo tanto, mejora el rendimiento general.

No debería haber una diferencia real en tu ejemplo.

vector<string> getseq(char * db_file)

Y si desea imprimirlo en main (), debe hacerlo en un bucle.

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 más agradable que pueda ser el "retorno por valor", es el tipo de código que puede llevar a uno a error. Considere el siguiente 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: ¿Qué pasará cuando se ejecute lo anterior? R: Un volcado de núcleo.
• P: ¿Por qué el compilador no detectó el error? R: Porque el programa es sintácticamente, aunque no semánticamente, correcto.
• P: ¿Qué sucede si modifica vecFunc () para devolver una referencia? R: El programa se ejecuta hasta su finalización y produce el resultado esperado.
• P: ¿Cuál es la diferencia? R: El compilador no tiene que crear ni administrar objetos anónimos. El programador ha indicado al compilador que use exactamente un objeto para el iterador y para la determinación del punto final, en lugar de dos objetos diferentes como lo hace el ejemplo roto.

El programa erróneo anterior indicará que no hay errores incluso si se utilizan las opciones de informes GNU g ++ -Wall -Wextra -Weffc ++

Si debe producir un valor, lo siguiente funcionaría en lugar de llamar a vecFunc () dos veces:

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

Lo anterior tampoco produce objetos anónimos durante la iteración del bucle, pero requiere una posible operación de copia (que, como algunos señalan, podría optimizarse en algunas circunstancias. Pero el método de referencia garantiza que no se producirá ninguna copia. Creer que el compilador realizar RVO no sustituye a intentar construir el código más eficiente que puedas. Si puedes discutir la necesidad de que el compilador haga RVO, estás por delante del juego.

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