Hola fran, me encantan tus videos, yo en lugar de memcpy usé copy de la librería estándar de c++ y por otra parte si se define un contructor de movimiento en lugar de definir un constructor copia (dejamos al compilador que lo haga) arreglamos el ub del double free, me gustaría saber que opinas, saludos
La diferencia entre copy y memset es el nivel al que trabajan. std::copy hace copias de objetos, de modo que llama a constructores de copia en su caso. std::memcpy solo copia bytes de memoria. En este caso, el efecto es el mismo porque copiamos bytes de un array de tipo básico, y aunque probablemente el ensamblador generado pueda terminar siendo el mismo (habría que comprobar), me fío más de que std::memcpy vaya a ser vectorizado por el compilador más fácilmente y en más casos. Respecto al move constructor, te adelantas a explicaciones que doy en vídeos posteriores. Me parece bien, por supuesto, aunque las soluciones dependen siempre de los usos. La tuya es tan valida como muchas otras aproximaciones. Me alegro que te gusten los vídeos :)
Teniendo en cuenta la regla de los tres, ¿se consideraría un error definir el destructor a la vez que el constructor copia y el operador de asignación son definidos como delete en una clase? pues he tenido ocasiones en que me interesa no permitir copias ni asignaciones entre objetos de una misma clase pero que si tiene su destructor definido.
La regla de los 3 te dice que si defines uno de los 3 métodos, definas los 3. Sin embargo, no te dice que debas definirlos para que obligatoriamente hagan algo. Definir que copia y asignación no están permitidos para tu tipo de datos es una forma de definirlos. Por tanto, si defines un destructor y marcas copia y asignación como eliminados ( = delete) estás definiendo los 3 para tu tipo de datos, cumpliendo la regla de los 3.
@@ProfesorRetroman Cierto, no había caído en cuenta de que es posible definirlos, pero que no implementen ninguna lógica, es decir, vacíos, y no sabía que se definen aun marcándolos con delete y pensándolo bien, creo que tiene sentido porque como va a saber qué método está marcado con delete si no se define como tal en la declaración.
profesor, su explicación me es espectacular.
saludos desde Argentina
Uno de los mejores canales en RUclips para aprender el C++ y por general, la programación.
Saludos desde Chipre.
Muchas gracias excelente clase.
Muy buena explicación. Conocía la regla de los tres, pero después de ver la clase realmente la entiendo. Muchas gracias.
Muchas gracias Fran por compartir tu conocimiento! Esperando la clase de los rvalues :)
Gracias de nuevo Profe... esperando lo de los RValues, que aunque he leído como que no me aclaro demasiado...
buen video, saludos de irak
Hola Profesor, ahí te dejo el Me Gusta
Hola fran, me encantan tus videos, yo en lugar de memcpy usé copy de la librería estándar de c++ y por otra parte si se define un contructor de movimiento en lugar de definir un constructor copia (dejamos al compilador que lo haga) arreglamos el ub del double free, me gustaría saber que opinas, saludos
// asi lo hice yo
GameObject(GameObject &&x)
{
spr = std::move(x.spr);
spr = nullptr;
}
La diferencia entre copy y memset es el nivel al que trabajan. std::copy hace copias de objetos, de modo que llama a constructores de copia en su caso. std::memcpy solo copia bytes de memoria. En este caso, el efecto es el mismo porque copiamos bytes de un array de tipo básico, y aunque probablemente el ensamblador generado pueda terminar siendo el mismo (habría que comprobar), me fío más de que std::memcpy vaya a ser vectorizado por el compilador más fácilmente y en más casos.
Respecto al move constructor, te adelantas a explicaciones que doy en vídeos posteriores. Me parece bien, por supuesto, aunque las soluciones dependen siempre de los usos. La tuya es tan valida como muchas otras aproximaciones.
Me alegro que te gusten los vídeos :)
Teniendo en cuenta la regla de los tres, ¿se consideraría un error definir el destructor a la vez que el constructor copia y el operador de asignación son definidos como delete en una clase? pues he tenido ocasiones en que me interesa no permitir copias ni asignaciones entre objetos de una misma clase pero que si tiene su destructor definido.
La regla de los 3 te dice que si defines uno de los 3 métodos, definas los 3. Sin embargo, no te dice que debas definirlos para que obligatoriamente hagan algo. Definir que copia y asignación no están permitidos para tu tipo de datos es una forma de definirlos. Por tanto, si defines un destructor y marcas copia y asignación como eliminados ( = delete) estás definiendo los 3 para tu tipo de datos, cumpliendo la regla de los 3.
@@ProfesorRetroman Cierto, no había caído en cuenta de que es posible definirlos, pero que no implementen ninguna lógica, es decir, vacíos, y no sabía que se definen aun marcándolos con delete y pensándolo bien, creo que tiene sentido porque como va a saber qué método está marcado con delete si no se define como tal en la declaración.