Qt. Tipos nativos de Qt o estandar de C++?

[dehm]

Hola:

Otra duda existencial sobre Qt.
El caso es que se supone que lo más recomendable es usar los tipos propios de Qt si queremos garantizar la mejor compatibilidad entre plataformas.
Así es recomendable usar qint8 en lugar de char, qint32 en lugar de int, QList<> en lugar de std::list<>, etc....
El problema es que si se usan los tipos "propios", la aplicación es 100% Qt, con las garantías de que los tipos funcionarán bien en todas las plataformas en las que compila Qt.
Pero al mismo tiempo, la aplicación pierde la estandarización de ser C++.
En mi caso estoy haciendo una aplicación que primero he terminado (bueno,casi...) en C++. Toda ella se maneja por medio de un menú en el main.cpp hecho para la consola.

Ahora para portarla a Qt, es tan fácil, porque sólamente hay que cambiar cada opción del menú por su correspondiente equivalencia en Qt (cuadros de diálogo para entrada de datos, botones para acciones,en fin....equivalencia 100%)

En lo poco que llevo hecho, la estrategia ha sido convertir los tipos de Qt a los tipos C++.
Por ejemplo, si creo un documento nuevo, he de definir dos parámetros que luego llevará el constructor.
Dichos parámetros los recogen dos QLineEdit, por lo que se guardan en QString

Pero el constructor se inicia con:

Código C++:

(std::string Codigo,std::string Resumen)
 

En este caso, es fácil puesto que puedo convertir los datos que recoge el cuadro de diálogo y pasarlos a std:string

Código C++:

(cuadro->LeeCodigo().toStdString(),cuadro->LeeResumen().toStdString())
 

Pero ahora llego al momento de trabajar con ficheros. Y ahora me veo obligado a hacer una chapucilla para mantener el código original C++ y usar métodos de Qt para abrir ficheros:

Código C++:

QString filename = QFileDialog::getOpenFileName(this);
    NuevaInstancia.nombrefichero = filename.toStdString();
    QFile file(filename);
    std::ifstream ifs (NuevaInstancia.nombrefichero.c_str(), std::ios::in|std::ios::binary);
    if (file.open(QIODevice::ReadOnly|QIODevice::Text))
    {
.....................
 

Como se ve, hago uso de QFile y de std::ifstream, ya que la aplicación realmente lee desde un objeto ifstream. Y aqui no hay conversiones sobre la marcha. O leo desde un QFile o desde un std::ifstream. Si opto por lo primero, definitivamente debería de cambiar las funciones originales.
De este problema me ha venido la reflexión.

Total, después de tanto rollo, la pregunta es:
¿Qué estrategia usáis para portar las aplicaciones? ó ¿Directamente trabajáis en Qt?
¿Que véis que sea mejor?

Bueno, saludos y gracias!

[eferion]

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, ... )

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.

[dehm]

Vaya:
Me esperaba la respuesta en la otra dirección

Pero definitivamente, la realidad es la que es. Por si fuera poco, el tema del QString es suficientemente importante como para decantarse por enfocar la aplicación 100% Qt.
Otra cosa que había pensado y había olvidado comentar en el primer mensaje, era sobrecargar las funciones para que trabajen con ambos tipos, o incluso realizar plantillas.
No me entusiasma por el trabajo extra que requiere, pero ya puestos, si me das tu opinión (por lo que veo muy autorizada) al respecto te lo agradecería mucho.
Saludos y gracias!

[eferion]

Mantener una "semi-integración" supone lo siguiente:

• Múltiples conversiones entre tipos Qt y nativos del estándar de C++.
• Creación de diversas interfaces para conectar ambos sistemas.
• Problemas de portabilidad al cambiar la versión de C++ o de Qt

Todos los puntos suponen trabajo extra y ralentizan la aplicación, ya que suponen capas de código adicional y continuos accesos a memoria para copiar los datos nativos de Qt a propios del estándar de C++ y viceversa.

Además, no solo se complica la legibilidad del código, sino que supone una cantidad de código adicional a depurar.

No obstante, como todo en esta vida, depende de tu objetivo, de tu tiempo, de tus recursos y de tus limitaciones en cuanto a libertad de elección y requisitos.

[dehm]

Gracias por las respuestas!

[lareto]

Yo creo que conviene separar el código que tiene que ver con la interfaz gráfica del que tiene que ver con los datos y algoritmos, a la manera "MVC" (Model View Controller).

Si en algún momento, por cuestiones de licencias o lo que sea, mañana decides usar wxwidgets u otra cosa, sólo deberás modificar la capa gráfica, sin necesidad de tocar nada más.

[eferion]

El problema es que Qt no es únicamente una interfaz gráfica... Qt es un framework completo ( interfaz gráfica, acceso a disco, clases básicas, contenedores, sockets, ... )

Puedes intentar programar con Qt "a medias" pero ese planteamiento no te va a permitir sacarle todo el jugo.