mais C++ est un language qui reste extremement complexe.
Là-dessus, je suis hyper d'accord. Un des atout majeurs de Qt à mon avis est qu'il permet de se restreindre à un très petit sous-ensemble de C++, et de pouvoir quand même faire des trucs très bien. Et le modèle Qt participe beaucoup à cette simplification [1]
J'avoue que bien que j'ai fait du C++/Qt pendant des années, j'ai jamais vraiment compris les template en C++, et que les itérateurs façon std++ sont une acquisition récente. Certains se désoleraient de ma fausse connaissance du C++; je me réjouis pour ma part d'avoir écrit de code lisible et performant en échappant à cette ignominie. Et je ne ressens nul besoin de savoir faire du template meta-programming, pas plus que de savoir dans quels cas je peux lever une exception dans un constructeur appelé par un autre thread et savoir si mon objet sera détruit correctement (objet avec un héritage multiple et destructeur virtuel sur plusieurs étages de classes évidemment).
De mon expérience, le combo C + GObject + Glib + GTK+ n'est pas plus difficile à appréhender ni à utiliser que C++ + Qt
C'est pas réellement plus difficile à appréhender. C'est juste plus pénible, plus sujets à des erreurs, moins lisible.
Petite question au passage, tu trouves pas que #include est surfait et que pour tous les include système, il vaudrait mieux faire des copier coller du code que tu rajoutes pour vraiment savoir comment il fonctionne ? Parce que c'est important de savoir comment tout fonctionne, non ?
[1] C'est aussi d'ailleurs ce qui heurte les puristes: comment, vous utilisez pas la fonctionnalité machin-truc-chose qu'on a introduit la semaine dernière dans le standard C++ qui vous fait ça en une ligne ?
Ben non, Qt fournit du code maison qui fait ça depuis maintenant 20 ans, sur des compilateurs qui supportaient à peine le C++ à l'époque. Et ça marche très bien, c'est lisible et performant. Mais pas de problème, dès que Visual Studio 2024 sort et que j'ai compris comment votre truc marche, je l'utilise.
[^] # Re: Qt > Gtk
Posté par Philippe F (site web personnel) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 3.
Là-dessus, je suis hyper d'accord. Un des atout majeurs de Qt à mon avis est qu'il permet de se restreindre à un très petit sous-ensemble de C++, et de pouvoir quand même faire des trucs très bien. Et le modèle Qt participe beaucoup à cette simplification [1]
J'avoue que bien que j'ai fait du C++/Qt pendant des années, j'ai jamais vraiment compris les template en C++, et que les itérateurs façon std++ sont une acquisition récente. Certains se désoleraient de ma fausse connaissance du C++; je me réjouis pour ma part d'avoir écrit de code lisible et performant en échappant à cette ignominie. Et je ne ressens nul besoin de savoir faire du template meta-programming, pas plus que de savoir dans quels cas je peux lever une exception dans un constructeur appelé par un autre thread et savoir si mon objet sera détruit correctement (objet avec un héritage multiple et destructeur virtuel sur plusieurs étages de classes évidemment).
C'est pas réellement plus difficile à appréhender. C'est juste plus pénible, plus sujets à des erreurs, moins lisible.
Petite question au passage, tu trouves pas que #include est surfait et que pour tous les include système, il vaudrait mieux faire des copier coller du code que tu rajoutes pour vraiment savoir comment il fonctionne ? Parce que c'est important de savoir comment tout fonctionne, non ?
[1] C'est aussi d'ailleurs ce qui heurte les puristes: comment, vous utilisez pas la fonctionnalité machin-truc-chose qu'on a introduit la semaine dernière dans le standard C++ qui vous fait ça en une ligne ?
Ben non, Qt fournit du code maison qui fait ça depuis maintenant 20 ans, sur des compilateurs qui supportaient à peine le C++ à l'époque. Et ça marche très bien, c'est lisible et performant. Mais pas de problème, dès que Visual Studio 2024 sort et que j'ai compris comment votre truc marche, je l'utilise.