Pour lier du C++ avec python, boost python est vraiment très pratique.
Sinon, je trouve ton commentaire très intéressant, bien que l'on ne soit pas d'accord sur tout.
Alors, dans l'ordre:
30 minutes pour compiler un projet en C++, c'est un extreme. Je vois mal un tel projet en python (ou alors, faut aimer les lancements qui durent plusieurs minutes).
Si l'on utilise «correctement» la STL, en utilisant at au lieu de operator[] sur un vecteur par exemple, je ne pense pas que le C++ devienne presque aussi lent que le Python.
Si je me suis déjà amusé cette année (études) à remplacer les algorithmes de gestion mémoire par les miens, (et que j'ai constaté que malloc faisait beaucoup mieux son travail que mes algorithmes), je ne pense pas qu'il y ait besoin de programmer une fusée pour avoir besoin de gérer la mémoire. Je reste contre l'idée d'abandonner la gestion de la mémoire. Il suffit d'avoir une architecture organisée, et de réfléchir un peu à ce sujet, c'est tout.
J'avais lu un article d'un développeur sur ruby on rails, qui avait optimisé une partie du framework en s'occupant de la mémoire. Avec le ramasse miettes, ils ne s'étaient jamais occupés de la mémoire. En analysant les copies d'objets, il avait remarqué qu'un objet pouvait être copié plusieurs dizaines de fois par page. En changeant certaines petites portions du code, il a supprimé les copies, et il a amélioré les performances.
Et pourtant, ruby on rails, c'est pour des interface. Il y a une grosse base de données derrières, la latence du réseau, et tout le reste.
Sinon, je ne connaissais pas la décoration des arguments de fonction, je vais m'y mettre :-)
Pour l'exemple du bar, et le self, c'est des principes différents. Avant de commencer mes études, j'étais plus dans l'optique du python (je faisais du ruby), car c'est plus pratique. Mais maintenant, je vois que le C++ permet beaucoup plus facilement de travailler en entreprise.
Pour modifier une chaîne de caractère, ça m'est déjà arrivé, je ne sais plus pourquoi, donc on va dire que c'est rare.
Pour les exceptions des jeux de caractères, typiquement, j'attends une chaîne en utf8, de base en python3. Sauf que l'utilisateur me passe de l'iso-42, car il comprends rien. Se taper une exception pour ça me gonfle. Alors, à la place, j'utilise la librairie de base codecs, mais ça remplace les caractères non valides. Ça serait plus simple de stocker des caractères non valides. Si l'utilisateur passe de l'iso-42, il s'attend à avoir en retour de l'iso-42, pas un truc qui lui a bouffé tout ses accents.
L'impression que j'ai d'être limité à une utilisation en haut niveau, c'est psychologique. Sans aller jusqu'à programmer la carte graphique, j'aimerais bidouiller mes chaînes de caractères à coup d'opérateurs de bytes, pourvoir décharger les modules, ne pas penser que mes trois lignes de code sont 1000 fois plus lente que l'équivalent en 5 lignes de code en C++.
Si les mecs en école d'ingé. oublient des {}, je vois pas pourquoi ils n'oublieraient pas des espaces. Puis le ; oublié, en général, le compilateur l'informe assez clairement (à part celui après une struct ou une class, qui génère un lot d'erreurs qui n'ont rien à voir impressionnant).
En plus, ça permet de ré-indenter facilement, avec un outil tel que GNU indent.
[^] # Re: Une vraie question
Posté par yellowiscool . En réponse au journal QML: le futur des interfaces graphiques. Évalué à 2.
Sinon, je trouve ton commentaire très intéressant, bien que l'on ne soit pas d'accord sur tout.
Alors, dans l'ordre:
30 minutes pour compiler un projet en C++, c'est un extreme. Je vois mal un tel projet en python (ou alors, faut aimer les lancements qui durent plusieurs minutes).
Si l'on utilise «correctement» la STL, en utilisant at au lieu de operator[] sur un vecteur par exemple, je ne pense pas que le C++ devienne presque aussi lent que le Python.
Si je me suis déjà amusé cette année (études) à remplacer les algorithmes de gestion mémoire par les miens, (et que j'ai constaté que malloc faisait beaucoup mieux son travail que mes algorithmes), je ne pense pas qu'il y ait besoin de programmer une fusée pour avoir besoin de gérer la mémoire. Je reste contre l'idée d'abandonner la gestion de la mémoire. Il suffit d'avoir une architecture organisée, et de réfléchir un peu à ce sujet, c'est tout.
J'avais lu un article d'un développeur sur ruby on rails, qui avait optimisé une partie du framework en s'occupant de la mémoire. Avec le ramasse miettes, ils ne s'étaient jamais occupés de la mémoire. En analysant les copies d'objets, il avait remarqué qu'un objet pouvait être copié plusieurs dizaines de fois par page. En changeant certaines petites portions du code, il a supprimé les copies, et il a amélioré les performances.
Et pourtant, ruby on rails, c'est pour des interface. Il y a une grosse base de données derrières, la latence du réseau, et tout le reste.
Sinon, je ne connaissais pas la décoration des arguments de fonction, je vais m'y mettre :-)
Pour l'exemple du bar, et le self, c'est des principes différents. Avant de commencer mes études, j'étais plus dans l'optique du python (je faisais du ruby), car c'est plus pratique. Mais maintenant, je vois que le C++ permet beaucoup plus facilement de travailler en entreprise.
Pour modifier une chaîne de caractère, ça m'est déjà arrivé, je ne sais plus pourquoi, donc on va dire que c'est rare.
Pour les exceptions des jeux de caractères, typiquement, j'attends une chaîne en utf8, de base en python3. Sauf que l'utilisateur me passe de l'iso-42, car il comprends rien. Se taper une exception pour ça me gonfle. Alors, à la place, j'utilise la librairie de base codecs, mais ça remplace les caractères non valides. Ça serait plus simple de stocker des caractères non valides. Si l'utilisateur passe de l'iso-42, il s'attend à avoir en retour de l'iso-42, pas un truc qui lui a bouffé tout ses accents.
L'impression que j'ai d'être limité à une utilisation en haut niveau, c'est psychologique. Sans aller jusqu'à programmer la carte graphique, j'aimerais bidouiller mes chaînes de caractères à coup d'opérateurs de bytes, pourvoir décharger les modules, ne pas penser que mes trois lignes de code sont 1000 fois plus lente que l'équivalent en 5 lignes de code en C++.
Si les mecs en école d'ingé. oublient des {}, je vois pas pourquoi ils n'oublieraient pas des espaces. Puis le ; oublié, en général, le compilateur l'informe assez clairement (à part celui après une struct ou une class, qui génère un lot d'erreurs qui n'ont rien à voir impressionnant).
En plus, ça permet de ré-indenter facilement, avec un outil tel que GNU indent.
Envoyé depuis mon lapin.