Exelente clase me costo un poco entenderla, pero ya quedo, aunque para poder entenderla le hice unas modificaciones agregando colores a donde inicia cada dato para no confundirme y encontre 2 erroes, en auto c = (mem[i]>31&& mem[i]
Alrededor de 44:50 Con (size & 0xF) te estás quedando con únicamente los 4 últimos bits de size. Si uno (o varios) de de esos 4 últimos bits fuese uno, ya se cumpliría la condición de ser distinto de cero y se devolvería lines+1 en lugar de lines. Creo que esa comprobación sería equivalente a calcular el módulo en base 16 de size. Es decir, algo más "amable a la vista" como (size % 16) imagino que haría lo mismo... lo que no sé es si cuando el compilador traduce eso a ensamblador un caso tendrá más o menos coste que el otro, pero desde luego a la vista a mi me resulta más sencillo el segundo :-) Cómo siempre, un vídeo estupendo y que se entiende perfectamente. Muchas gracias por compartirlo.
Totalmente correcto. Muy bien :) Técnicamente, siendo constantes, el ensamblador debe traducir exactamente igual ambas versiones. En ambos casos, realizará un AND, que es mucho más rápido que realizar una división. Puedes comprobarlo aquí (godbolt.org/z/d3Eo6objq). En el código ensamblador verás un AND EAX, 15, que es justo lo mismo que he mi (size & 0x0F) :). Si realmente te sientes más cómodo con size % 16, debe ser que estás más acostumbrado a trabajar en alto nivel :). Cuando se trabaja a menudo en ensamblador, la versión con AND resulta más natural ;).
Para hacerlo general, habría que tener eso en cuenta. Dejé el 0xF porque a efectos de lo que quería mostrar no era eso lo relevante (solo la exploración de la memoria) y así me valía. Pero sí, habría que hacerlo para líneas de los tamaños válidos, si es lo que se quiere.
Estimado profesor, No he podido ver el tutorial al completo todavía pero quería saber si tienes en cuenta el tema de serialización... estoy intentando montarme un sistema de carga de datos en binario y definir un formato de fichero correspondiente, preferiblemente volviendo al C98 si es necesario...
No, no he tratado la serialización aún en clase de forma detallada. La he mencionado en algunas clases sueltas, pero sin profundizar. Lo que no entiendo es por qué querrías C++98. Es un estándar completamente en desuso, y solamente está para dar soporte a software antiguo. Usar ahora C++98 por decisión propia no es buena idea.
Hola profe,que pena quitarle tiempo pero me gustaria saber que libros para ensamble son buenos para un principiante?. Muchas gracias por su tiempo profe
Ha faltado decir que si se usan vectores al hacer resize habría que crear la lista de freelist para el nuevo trozo en el vector de indices, o no habra forma de encontrar bloques libres después del resize.
Si el crecimiento se hace con resize, sí, tendrías toda la razón. En realidad, la operación habitual es grow: resize implica que se crean nuevos objetos dentro de un vector, mientras que grow sólo cambia el tamaño, aumentando el capacity. Con eso en mente, hay 2 formas de gestionar los índices: con un vector, cuando está lleno, se hace push_back y no es necesario inicializar freelist (porque siempre añades un único elemento, aunque haya capacidad para más). O bien con un resize, donde sí estás añadiendo muchos nuevos elementos que, como dices, deberían ser inicializados puesto que formarían parte de la freelist :).
es difícil seguir sus videos en windows, como que le heap es distinto entre compiladores Y_Y, bueno para no hacerla mas larga en vc++ obj.capacity()* sizeof(int)
El problema no es Windows sino que no hay la operacion multiplicar punteros , si lo que quieres es obtener la direccion final de la memoria reservada para el vector seria int* p = &v[0] + v.capacity[0] suponiendo que sea un vector de enteros
Esta clase vale oro.
Exelente clase me costo un poco entenderla, pero ya quedo, aunque para poder entenderla le hice unas modificaciones agregando colores a donde inicia cada dato para no confundirme y encontre 2 erroes, en auto c = (mem[i]>31&& mem[i]
Alrededor de 44:50
Con (size & 0xF) te estás quedando con únicamente los 4 últimos bits de size. Si uno (o varios) de de esos 4 últimos bits fuese uno, ya se cumpliría la condición de ser distinto de cero y se devolvería lines+1 en lugar de lines. Creo que esa comprobación sería equivalente a calcular el módulo en base 16 de size. Es decir, algo más "amable a la vista" como (size % 16) imagino que haría lo mismo... lo que no sé es si cuando el compilador traduce eso a ensamblador un caso tendrá más o menos coste que el otro, pero desde luego a la vista a mi me resulta más sencillo el segundo :-)
Cómo siempre, un vídeo estupendo y que se entiende perfectamente. Muchas gracias por compartirlo.
Totalmente correcto. Muy bien :)
Técnicamente, siendo constantes, el ensamblador debe traducir exactamente igual ambas versiones. En ambos casos, realizará un AND, que es mucho más rápido que realizar una división. Puedes comprobarlo aquí (godbolt.org/z/d3Eo6objq). En el código ensamblador verás un AND EAX, 15, que es justo lo mismo que he mi (size & 0x0F) :).
Si realmente te sientes más cómodo con size % 16, debe ser que estás más acostumbrado a trabajar en alto nivel :). Cuando se trabaja a menudo en ensamblador, la versión con AND resulta más natural ;).
Y... ¿Por qué & 0xF a piñón si el ancho de las líneas puede cambiar? (Se recibe como parametro)
Para hacerlo general, habría que tener eso en cuenta. Dejé el 0xF porque a efectos de lo que quería mostrar no era eso lo relevante (solo la exploración de la memoria) y así me valía. Pero sí, habría que hacerlo para líneas de los tamaños válidos, si es lo que se quiere.
Ojalá mis profesores de universidad hubieran sido remotamente parecidos a Profesor Retroman
Estimado profesor,
No he podido ver el tutorial al completo todavía pero quería saber si tienes en cuenta el tema de serialización... estoy intentando montarme un sistema de carga de datos en binario y definir un formato de fichero correspondiente, preferiblemente volviendo al C98 si es necesario...
No, no he tratado la serialización aún en clase de forma detallada. La he mencionado en algunas clases sueltas, pero sin profundizar.
Lo que no entiendo es por qué querrías C++98. Es un estándar completamente en desuso, y solamente está para dar soporte a software antiguo. Usar ahora C++98 por decisión propia no es buena idea.
Hola profe,que pena quitarle tiempo pero me gustaria saber que libros para ensamble son buenos para un principiante?. Muchas gracias por su tiempo profe
Ha faltado decir que si se usan vectores al hacer resize habría que crear la lista de freelist para el nuevo trozo en el vector de indices, o no habra forma de encontrar bloques libres después del resize.
Si el crecimiento se hace con resize, sí, tendrías toda la razón. En realidad, la operación habitual es grow: resize implica que se crean nuevos objetos dentro de un vector, mientras que grow sólo cambia el tamaño, aumentando el capacity. Con eso en mente, hay 2 formas de gestionar los índices: con un vector, cuando está lleno, se hace push_back y no es necesario inicializar freelist (porque siempre añades un único elemento, aunque haya capacidad para más). O bien con un resize, donde sí estás añadiendo muchos nuevos elementos que, como dices, deberían ser inicializados puesto que formarían parte de la freelist :).
es difícil seguir sus videos en windows, como que le heap es distinto entre compiladores Y_Y, bueno para no hacerla mas larga en vc++ obj.capacity()* sizeof(int)
El problema no es Windows sino que no hay la operacion multiplicar punteros , si lo que quieres es obtener la direccion final de la memoria reservada para el vector seria
int* p = &v[0] + v.capacity[0] suponiendo que sea un vector de enteros
Hps todos