Cita:
Iniciado por dehm 
Así es recomendable usar qint8 en lugar de char, qint32 en lugar de int, QList<> en lugar de std::list<>, etc....
A ver, depende del uso que le vayas a dar a los datos.
En cuanto a tipos básicos, qint32, por ejemplo, te garantiza un entero de 32 bits independientemente de si estás trabajando con arquitecturas de 8 bits, de 128 bits, ... Es decir, debes usar este tipo si, por exigencias del diseño, la variable debe ser obligatoriamente de 32 bits, en caso contrario ( es decir, normalmente ), puedes hacer uso de los tipos propios de C++.
En cuanto a contenedores, también depende. Si necesitas hacer uso de la biblioteca de Qt, obviamente necesitas usar los mismos contenedores para poder llamar a las funciones y evitar conversiones continuas entre diferentes contenedores... si el contenedor lo usas dentro de tu propio código y no necesitas pasárselo a Qt, entonces tienes total libertad para utilizar el que más te convenga.
Quizás la única excepcion es "QString", que sí es recomendable usarla en toda tu aplicación. El motivo es que "QString" te permite trabajar con múltiples idiomas sin problemas, además de que dispone de multitud de métodos para trabajar en diferentes codificaciones ( ANSI, UTF8, ... )
Cita:
Iniciado por dehm ¿Qué estrategia usáis para portar las aplicaciones? ó ¿Directamente trabajáis en Qt?
¿Que véis que sea mejor?
Si tus desarrollos van a tener historia creo que lo mejor es integrar totalmente con Qt.
Integrar tu aplicación completamente en el entorno Qt te va a quitar muchos quebraderos de cabeza, como las comentadas conversiones. Además Qt va a un ritmo diferente del estándar de C++. Mantener tu aplicación integrada te permitirá aprovechar éstas mejoras sin problemas. Si sucede que alguna parte de tu aplicación necesita ser compatible con el estándar de C++ por algún motivo (plugins, librerías de terceros, etc), lo mejor es programar una interfaz que permita conectar ambos mundos sin problemas... este mecanismo además te ayudará a mantener tu núcleo protegido del código externo.
Además, el tiempo de desarrollo va a ser menor porque todo el código va a hablar "el mismo lenguaje".
Si resulta que en un futuro lejano te ves obligado a dejar Qt, el esfuerzo va a ser prácticamente el mismo que si no hubieses realizado la integración con Qt, te lo digo por experiencia.
Esto no quita para que tengas partes de tu código que, por comodidad, usen clases propias del estándar de C++, pero no suele ser buena idea tener que realizar mil conversiones en tu código para poder trabajar con Qt... eso quita mucho tiempo.
Un saludo.