Et? Je ne vois pas où tu veux en venir: si tu utilises, disons, Qt d'une part, et, par exemple, libpq (lib qui permets d'interroger postgresql) il va bien falloir qu'à un moment tu la fasses, cette conversion...
Du coup, si tu utilises au maximum les fonctionnalités fournies par le standard, c'est bien plus simple de combiner l'usage de différentes libs.
Si ce qui t'ennuies, c'est ce genre de choses: QString -> std::string -> QString -> std::string -> QString -> std::string -> QString pour une donnée unique, c'est que peut-être que les relations entre les classes de ton programmes sont mal faites? Peut-être qu'avec une meilleure architecture ce serait évitable?
Pas toujours, c'est vrai, mais j'ai parlé d'éviter, et de cas généraux. Si je dois, pour une raison ou une autre, manipuler en permanence un type non-standard dans un code, alors tant pis. Mais ça arrive assez rarement, et quand ça m'arrive je constate qu'en général, il est intéressant de l'encapsuler. Du coup, j'utilise toujours du non-standard, c'est vrai, mais seule l'encapsulation est dépendante de la lib externe.
Conséquence, s'il faut porter le projet, ou changer de techno sous-jacente, il y à moins de code à revoir.
[^] # Re: A defaut de GNU, il y a Linux
Posté par freem . En réponse au journal CPP Con sur Youtube. Évalué à 3.
Et? Je ne vois pas où tu veux en venir: si tu utilises, disons, Qt d'une part, et, par exemple, libpq (lib qui permets d'interroger postgresql) il va bien falloir qu'à un moment tu la fasses, cette conversion...
Du coup, si tu utilises au maximum les fonctionnalités fournies par le standard, c'est bien plus simple de combiner l'usage de différentes libs.
Si ce qui t'ennuies, c'est ce genre de choses: QString -> std::string -> QString -> std::string -> QString -> std::string -> QString pour une donnée unique, c'est que peut-être que les relations entre les classes de ton programmes sont mal faites? Peut-être qu'avec une meilleure architecture ce serait évitable?
Pas toujours, c'est vrai, mais j'ai parlé d'éviter, et de cas généraux. Si je dois, pour une raison ou une autre, manipuler en permanence un type non-standard dans un code, alors tant pis. Mais ça arrive assez rarement, et quand ça m'arrive je constate qu'en général, il est intéressant de l'encapsuler. Du coup, j'utilise toujours du non-standard, c'est vrai, mais seule l'encapsulation est dépendante de la lib externe.
Conséquence, s'il faut porter le projet, ou changer de techno sous-jacente, il y à moins de code à revoir.