He estado revisando el código de Etherdice y noté que algunas variables se declaran como
ParserResult memory result;
y no he encontrado la palabra clave "memoria" en ninguna documentación. Lo que encontré aquí fue esta explicación :
Son análogos a la memoria y al almacenamiento en el disco duro de una computadora. El contrato puede usar cualquier cantidad de memoria (siempre que pueda pagarla, por supuesto) durante la ejecución de su código, pero cuando la ejecución se detiene, todo el contenido de la memoria se borra y la siguiente ejecución comenzará de nuevo. El almacenamiento, por otro lado, persiste en la propia cadena de bloques, por lo que la próxima vez que el contrato ejecute algún código, también tendrá acceso a todos los datos que almacenó previamente en su área de almacenamiento.
¿La declaración de "memoria" realmente hace que el valor se almacene en "memoria"? ¿No se almacenan todas las variables locales dentro de una función solo en la memoria y las variables globales siempre se almacenan en la cadena de bloques? ¿Y cuál es la relación con esta explicación de "Memoria" aquí ?
Se recomienda encarecidamente leer las preguntas frecuentes de Solidity sobre "memoria" en su totalidad, y se proporciona un fragmento a continuación.
La máquina virtual Ethereum tiene tres áreas donde puede almacenar elementos.
El primero es "almacenamiento", donde residen todas las variables de estado del contrato. Cada contrato tiene su propio almacenamiento y es persistente entre llamadas de función y bastante costoso de usar.
El segundo es "memoria", se utiliza para almacenar valores temporales. Se borra entre llamadas de funciones (externas) y es más barato de usar.
El tercero es la pila, que se utiliza para contener pequeñas variables locales. Es de uso casi gratuito, pero solo puede contener una cantidad limitada de valores.
Para casi todos los tipos, no puede especificar dónde deben almacenarse, porque se copian cada vez que se usan.
Los tipos en los que la llamada ubicación de almacenamiento es importante son estructuras y matrices. Si, por ejemplo, pasa tales variables en llamadas a funciones, sus datos no se copian si pueden permanecer en la memoria o en el almacenamiento. Esto significa que puede modificar su contenido en la función llamada y estas modificaciones seguirán siendo visibles en la persona que llama.
Hay valores predeterminados para la ubicación de almacenamiento según el tipo de variable que se trate ( fuente ):
state variables are always in storage function arguments are always in memory local variables of struct, array or mapping type reference storage by default local variables of value type (i.e. neither array, nor struct nor mapping) are stored in the stack
Las preguntas frecuentes tienen ejemplos de código para ayudar a explicar más.
Un error común es declarar una variable local (de estructura, arreglo o mapeo) y asumir que se creará en memoria, aunque se creará en almacenamiento.
La explicación de las sutilezas de la memoria explica los costos de gas para usar la memoria, que es una matriz de bytes que "comienza en tamaño cero, pero se puede expandir en fragmentos de 32 bytes simplemente accediendo o almacenando memoria en índices mayores que su tamaño actual".
uberlaufer
ética
mdmb
uintsin la ubicación de los datos. Entiendo que es necesario para matrices/asignaciones/estructuras (como se indica en los documentos + su respuesta), pero ¿por qué el código se queja destring?ética
mdmb
memorycuando se juega con ellas, por ejemplo, funciones internas :)