Los algoritmos de la STL están diseñados para operar sobre iteradores, pero a menudo necesitamos que esa operación no solo modifique el valor en una posición de memoria, sino que cambie el tamaño del contenedor o transfiera la propiedad de los datos. Para lograr esto, la STL utiliza adaptadores de iteradores. Los adaptadores de inserción, como std::back_inserter [C++11], std::front_inserter [C++11] y std::inserter [C++11], no son simples punteros; son objetos que, al ser desreferenciados, invocan métodos del contenedor como push_back(), push_front() o insert(). Esto permite que algoritmos de propósito general como std::copy funcionen con contenedores que crecen dinámicamente.

Por otro lado, para la navegación en sentido contrario, existen los iteradores inversos (std::reverse_iterator [C++11]). Estos envuelven a un iterador normal y transforman las operaciones: un ++ sobre el iterador inverso se traduce en un -- sobre el iterador original. Un detalle técnico fundamental es su relación con el método base(); este retorna el iterador subyacente, pero debido a cómo funciona rend(), base() apunta a la posición inmediatamente después de la que el iterador inverso parece estar señalando.

Finalmente, para optimizar el rendimiento en objetos pesados, utilizamos los iteradores de movimiento (std::move_iterator [C++11]). Mediante std::make_move_iterator, transformamos el resultado de la desreferenciación de un iterador: en lugar de devolver una lvalue reference (T&), devuelve una rvalue reference (T&&). Esto permite que los algoritmos utilicen la semántica de movimiento en lugar de la copia, algo vital cuando trabajamos con vectores de std::string o std::vector complejos.

Si usas un iterador de inserción con un contenedor que no soporta la operación requerida (por ejemplo, un std::back_inserter en un contenedor que no tiene push_back), obtendrás un error de compilación. Si intentas usar un iterador de movimiento en un contenedor y luego intentas acceder a sus elementos originales, caerás en un estado de “objeto movido” (valid but unspecified state), lo cual es un error lógico común que suele derivar en basura o crashes.

#include <iostream>
#include <vector>
#include <list>
#include <string>
#include <algorithm>
#include <iterator>
#include <utility>

int main() {
    // Datos de entrada con recursos pesados para observar el beneficio del movimiento
    std::vector<std::string> origen = {"Alfa", "Beta", "Gamma", "Delta"};
    
    // 1. Uso de std::back_inserter para expandir un contenedor
    // Transformamos los datos originales en una lista, expandiendo la lista dinámicamente.
    std::list<std::string> lista_intermedia;
    std::copy(origen.begin(), origen.end(), std::back_inserter(lista_intermedia));

    // 2. Uso de iteradores inversos
    // Queremos procesar la lista en orden inverso y añadir un prefijo.
    std::vector<std::string> invertida;
    std::transform(lista_intermedia.rbegin(), lista_intermedia.rend(), 
                    std::back_inserter(invertida),
                    [](const std::string& s) {
                        return std::string("(") + s + ")";
                    });

    // 3. Uso de std::make_move_iterator para transferencia de propiedad
    // En lugar de copiar los strings de 'invertida' a 'final_container',
    // move_iterator permite que se usen las semánticas de movimiento.
    std::vector<std::string> final_container;
    std::copy(std::make_move_iterator(invertida.begin()), 
              std::make_move_iterator(invertida.end()), 
              std::back_inserter(final_container));

    // Verificación de la salida
    // El resultado debería ser: (Delta) (Gamma) (Beta) (Alpha)
    for (const auto& str : final_container) {
        std::cout << str << " ";
    }
    std::cout << std::endl;

    return 0;
}

Para entender lo que ocurre bajo el capó, analicemos el flujo del programa:

  1. En std::copy(origen.begin(), origen.end(), std::back_inserter(lista_intermedia)), el algoritmo llama a *it = value. Como it es un std::back_insert_iterator, este operador de asignación no escribe en una posición existente, sino que invoca lista_intermedia.push_back(value). Esto es lo que permite que lista_intermedia crezca de tamaño cero a cuatro.
  2. Al usar lista_intermedia.rbegin(), estamos operando con un std::reverse_iterator. Cuando el algoritmo llega al final con rend(), el iterador subyacente (obtenido mediante base()) es lista_intermedia.end(). Esto es necesario porque el “final” de un recorrido inverso es el “inicio” del recorrido normal, pero desplazado una posición.
  3. La operación más crítica es el std::copy con std::make_move_iterator. Sin este adaptador, std::copy realizaría copias de los std::string de invertida hacia final_container. Con std::make_move_iterator, la expresión *it dentro de std::copy devuelve un std::string&&. Esto provoca que el constructor de asignación del nuevo elemento en final_container sea el de movimiento, extrayendo el puntero interno del string original en lugar de realizar una asignación de memoria y copia de caracteres.
  4. Es importante notar que, tras el std::copy con move_iterator, el contenedor invertida queda en un estado válido pero con sus strings “vaciados” (movidos). Intentar acceder a invertida[0] después de esto es un error lógico.

El error frecuente

Un error clásico ocurre al intentar “ahorrar” memoria usando std::make_move_iterator sobre un contenedor que necesitas reutilizar después.

std::vector<std::string> datos = {"grande", "y", "pesado"};
std::vector<std::string> destino;

// Error: Estamos moviendo el contenido de 'datos'
std::copy(std::make_move_iterator(datos.begin()), 
          std::make_move_iterator(datos.end()), 
          std::back_inserter(destino));

// El error: Acceso a objetos en estado "moved-from"
std::cout << datos[0] << std::endl; // Undefined Behavior / Cadena vacía

Si intentas usar datos[0] después de este proceso, el comportamiento es indefinido según el estándar, aunque en la práctica (como en la implementación de std::string en MSVC o GCC) obtendrás una cadena vacía. Si compilas con -fsanitize=undefined en Clang, podrías detectar inconsistencias si el objeto resultante ha violado alguna propiedad interna, pero lo más común es que el bug sea silencioso y solo se manifieste cuando la lógica del programa dependa de la integridad de datos.

N° 70