Hoy fui a ver tarnation. Es de esas películas en que estás al filo de tu asiento. Pero no por la emoción, sino por indecisión: no sabes en qué momento largarte indignado, molesto, azorado... pero la curiosidad y el mismo azoro te mantienen. La película es odiosa y fascinante; exhibicionista e introspectiva; es una película que detestas, pero que al mismo tiempo, te hubiera gustado hacer; es una película que choca contigo mismo, y por ello te hace preguntarte sobre tus prejuicios; es una película que contrasta tu realidad con la del director; enfrenta tu egoísmo y tu fortuna. Me recordó, no por el tema sino por las emociones que se volcan, a Dogville.

Estoy contento porque hoy me salió, en DASF mode, la reproducción de PCM, con mi versión recortada de los OMX test. Ya creo estar entendiendo mejor la orientación a buffers del IL del OMX. FelipeC hizo un gran trabajo con el video encoder. Con un par de componentes de recorte, ya tendré una buena noción para hacer abstracciones y probablemente patrones de diseño.

Sobre el problema que enfrento con DAOGen, creo que encontré la solución en un artículo: PostgreSQL/libpqxx Class Generator. Esa cosa hace algo similar que DAOGen, pero orientado a la API de Microsoft.

La magia la hace estas directivas de compilador:

1
2

#define NULLINT 0x80000000
#define NULLDBL ((double)0xFFFFFFFFFFFFFFFF)

Lo que me pregunto es ¿habrá algún tipo de prueba matemática que asegure que en ningún caso habrá un valor que caiga en esos números? Creo que no. Esta es una solución totalmente Ad-Hoc, por lo que la hace una solución temporal. Siguiendo con ese orden de ideas, podemos hacer que NULLSTR sea "<null/>". Sin embargo la solución canónica seguirá siendo mantener meta atributos, y eso sólo se conseguirá integrando libpqxx y cambiando radicalmente la estructura de los DTOs. Hacer esto también implica cambiar la clase PGDBConn, lo que significa que hize mal al no hacerla una interfaz.