Que es Ownership en Rust ? Parte 2

Seguimos con Rust. 

Ya hemos visto literales de cadena, donde un valor de cadena está codificado en nuestro programa. Los literales de cadena son convenientes, pero no son adecuados para cada situación en la que deseemos usar texto. Una razón es que son inmutables. Otra es que no todos los valores de cadena se pueden conocer cuando escribimos nuestro código: por ejemplo, ¿qué pasa si queremos tomar la entrada del usuario y almacenarla? Para estas situaciones, Rust tiene un segundo tipo de cadena, String. Este tipo se asigna en el Head y, como tal, puede almacenar una cantidad de texto que no conocemos en el momento de la compilación. Puede crear una cadena a partir de un literal de cadena usando la función from, de esta manera:

let s = String::from("hello");

Los dos puntos (::) permiten obtener un string de la palabra. 

Este tipo de cadena se puede mutar:

    let mut s = String::from("hello");

    s.push_str(", world!"); // push_str() appends a literal to a String

    println!("{}", s); // This will print `hello, world!`

Entonces, ¿cuál es la diferencia aquí? ¿Por qué String puede mutar pero los literales no? La diferencia es cómo estos dos tipos manejan la memoria.

En el caso de un literal de cadena, conocemos el contenido en tiempo de compilación, por lo que el texto se codifica directamente en el ejecutable final. Es por eso que los literales de cadena son rápidos y eficientes. Pero estas propiedades solo provienen de la inmutabilidad del literal de cadena. Desafortunadamente, no podemos poner una gota de memoria en el binario para cada fragmento de texto cuyo tamaño se desconoce en el momento de la compilación y cuyo tamaño puede cambiar mientras se ejecuta el programa.

Con el tipo String, para admitir una parte de texto mutable y ampliable, necesitamos asignar una cantidad de memoria en el Head, desconocida en el momento de la compilación, para contener los contenidos. Esto significa:

La memoria debe solicitarse al asignador de memoria en tiempo de ejecución.

Necesitamos una forma de devolver esta memoria al asignador cuando hayamos terminado con nuestra cadena.

Nosotros hacemos la primera parte: cuando llamamos a String :: from, su implementación solicita la memoria que necesita. Esto es bastante universal en los lenguajes de programación.

Sin embargo, la segunda parte es diferente. En lenguajes con un recolector de basura (GC), el GC realiza un seguimiento y limpia la memoria que ya no se usa, y no tenemos que pensarlo. Sin un GC, es nuestra responsabilidad identificar cuándo ya no se usa la memoria y llamar al código para devolverlo explícitamente, tal como lo hicimos para solicitarlo. Hacer esto correctamente ha sido históricamente un problema de programación difícil. Si lo olvidamos, desperdiciaremos memoria. Si lo hacemos demasiado pronto, tendremos una variable no válida. Si lo hacemos dos veces, eso también es un error. Necesitamos emparejar exactamente una asignación con exactamente una libre.

Rust toma un camino diferente: la memoria se devuelve automáticamente una vez que la variable que la posee queda fuera de alcance. Aquí hay una versión de nuestro ejemplo de alcance usando una Cadena en lugar de una cadena literal:

    {

        let s = String::from("hello"); // s is valid from this point forward

        // do stuff with s

    }

Hay un punto natural en el que podemos devolver la memoria que nuestro String necesita al asignador: cuando s sale del alcance. Cuando una variable queda fuera de alcance, Rust llama a una función especial para nosotros. Esta función se llama soltar, y es donde el autor de String puede poner el código para devolver la memoria. Las llamadas de Rust caen automáticamente en el corchete de cierre.

Nota: En C ++, este patrón de asignación de recursos al final de la vida útil de un elemento a veces se denomina Adquisición de recursos es inicialización (RAII). La función de caída en Rust le resultará familiar si ha utilizado patrones RAII.

Este patrón tiene un profundo impacto en la forma en que se escribe el código Rust. Puede parecer simple en este momento, pero el comportamiento del código puede ser inesperado en situaciones más complicadas cuando queremos que múltiples variables usen los datos que hemos asignado en el Head.