Rapidement, parce qu'après l'on va dire que c'est trop long (mes excuses pour le 72 colonnes fixe, naïvement je pensais que la saisie "html" ferait des retours à la ligne au niveau des doubles retours à la ligne et ignorerait les simples, trop d'année sous vim et trop de rst ;)
Agree pour boost python, c'est un peu fastidieux, mais cela fait le boulot (Mais je suis tellement fan de la simplicité de cytpes...)
Pour les 30 minutes de compilation, je suis d'accord c'est un cas extrême. Mais même 1 minute, quand t'es en pleine phase d'essais/erreurs, c'est trop. Après cela ne veut pas forcement dire que ton programme python prendra des heures à se lancer. L'import d'un module python qui sera utilisé N fois ne se fait qu'une fois. L'instanciation d'un template qui sera utilisé par N différents types par M différents fichiers .cpp se fait un nombre compris entre N et N*M fois.
Pour les [] versus .at() versus C/python, oui, j'avoue, en effet, at sera toujours plus rapide en C++ qu'en python, rien à dire la dessus. Ce que je voulais soulever c'est qu'a force d'ajouter des couches en C++ pour faire comme en Python (ou ruby, ou autre chose), cela à un cout de performance. Si l'on est près à payer ce cout de performance (qui n'est pas négligeable, je récite mon exemple sur les fonctions virtuelles qui pouvent détruire les performances d'un programme), pourquoi ne pas utiliser python (ou ruby, ou...).
Mon problème n'est pas forcement le C++, mais plutôt le mauvais usage de celui-ci. Il est vrai qu'il y a des cas particuliers qui nécessitent l'utilisation du C++ et je ne suis pas en guerre contre les gens qui ont fait ce choix de façon raisonnée, j'essaye plutôt d'ouvrir les yeux à ceux qui le font sans réfléchir, ou avec de faux arguments. C'est comme le débat Maya/Blender (ou Windows/Linux). Je n'ai rien contre celui qui utilise Maya parce que celui-ci est plus pratique pour certains cas de figure. J'ai quelque chose contre celui qui crache sur Blender en disant que Maya est mieux parce que c'est professionnel et puis de tout manière je m'en cogne, je le pirate.
Pour ton assertion "C++ plus facile pour travailler en entreprise". Je dirais que oui, sur un CV cela le fait mieux (par contre python ou ruby ça peut faire de toi l'élément qui se démarque dans la masse de +/- bon développeurs C++). Pour l'efficacité du travail, cela dépend à mon sens de savoir si tu bosses avec des gens compétents et avec de la rigueur ou pas ? Et je suis d'accord que quitte à faire des conneries, autant le faire avec un système à typage statique qui sera moins permissif. Maintenant, quand je bosse tout seul, je prend mes responsabilités et j'espère ne pas être mauvais. Et quand je m'entoure, j'essaye de m'entourer de gens compétents qui ne se laisseront pas avoir par le risque du typage dynamique et qui sauront profiter de ses avantages.
Pour ton problème d'encodage.
- Soit tu veux travailler sur des caractères et dans ce cas là il te faut faire une conversion et tu dois connaître le format d'entrée et de sortie (en l'imposant ou en demandant à l'utilisateur de le spécifier, si celui-ci ne suit pas cette règle, tu ne peux rien pour lui) et dans ce cas là rien ne t'empêches de convertir son iso-42 en unicode puis en iso-42 (en supposant qu'il existe une fonction de conversion ;)
- Soit tu n'as pas besoin de travailler sur les caractères, et tu peux travailler sur un bytes (le type python3 ~ char[]) et ainsi il n'y aura pas de caractère qui disparaît en sortie.
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++.
- Tu peux bidouiller tes chaînes à coup d'opérateurs de bit, après il faut voir si cela à un sens (sur une chaîne char[], certainement, et encore je ne vois pas grand chose à faire de plus que le changement de case avec ^ (1 << 5))
- Tu peux décharger des modules, après faut voir si cela à un sens
- Tu peux faire de la programmation de carte graphique en Python ;)
- Tu peux aussi te demander en C++ si les 30 lignes que tu as écris seront aussi rapide que du Python (Je pense par exemple au hashmap qui n'existent pas dans la STL). Je joue souvent un jeu marrant avec mes collègues, élèves ou autre qui me disent que python est lent, je leur demande de me fournir un bout de code C++ qui est selon eux rapide et un bout de code python qui est selon eux lent. Très souvent je peux récrire leur bout de python pour qu'il soit plus rapide que leur bout de C++ (bon, je peux aussi récrire le bout de C++ pour qu'il soit plus rapide que le bout de Python ;)
Si les mecs en école d'ingé. oublient des {}, je vois pas pourquoi ils n'oublieraient pas des espaces.
Je me demande aussi, mais figure toi que j'ai aussi ce problème. Je ne fais presque jamais d'erreur de syntaxe en Python, je passe mon temps à en faire en C++... Mais je suis certainement biaisé en C++ du fait de mon expérience python. (Enfin j'ai fais plus de C++ dans ma vie que de python...)
En plus, ça permet de ré-indenter facilement, avec un outil tel que GNU indent.
Ça c'est (à mon avis) un faux argument. Pourquoi ré-indenter ? Cela signifie que ton indentation n'a qu'une valeur cosmétique, donc cela ne sert a rien d'indenter. Si cela ne sert a rien, pourquoi le faire non ? Donc cela sert à quelque chose. Donc il faut indenter, et tous indenter de la même manière au sein d'un projet, donc l'indentation a un sens ? Tient, ce sens est vraiment proche des blocs que je délimite par des {} et ;. C'est meme tellement proche que je me demande pourquoi je duplique l'information... En fait l'indentation significative : "ça permet de remettre facilement les {}; avec un outil tel que GNU jemetlesaccollades"
[^] # Re: Une vraie question
Posté par Guillaum (site web personnel) . En réponse au journal QML: le futur des interfaces graphiques. Évalué à 0.
Agree pour boost python, c'est un peu fastidieux, mais cela fait le boulot (Mais je suis tellement fan de la simplicité de cytpes...)
Pour les 30 minutes de compilation, je suis d'accord c'est un cas extrême. Mais même 1 minute, quand t'es en pleine phase d'essais/erreurs, c'est trop. Après cela ne veut pas forcement dire que ton programme python prendra des heures à se lancer. L'import d'un module python qui sera utilisé N fois ne se fait qu'une fois. L'instanciation d'un template qui sera utilisé par N différents types par M différents fichiers .cpp se fait un nombre compris entre N et N*M fois.
Pour les [] versus .at() versus C/python, oui, j'avoue, en effet, at sera toujours plus rapide en C++ qu'en python, rien à dire la dessus. Ce que je voulais soulever c'est qu'a force d'ajouter des couches en C++ pour faire comme en Python (ou ruby, ou autre chose), cela à un cout de performance. Si l'on est près à payer ce cout de performance (qui n'est pas négligeable, je récite mon exemple sur les fonctions virtuelles qui pouvent détruire les performances d'un programme), pourquoi ne pas utiliser python (ou ruby, ou...).
Mon problème n'est pas forcement le C++, mais plutôt le mauvais usage de celui-ci. Il est vrai qu'il y a des cas particuliers qui nécessitent l'utilisation du C++ et je ne suis pas en guerre contre les gens qui ont fait ce choix de façon raisonnée, j'essaye plutôt d'ouvrir les yeux à ceux qui le font sans réfléchir, ou avec de faux arguments. C'est comme le débat Maya/Blender (ou Windows/Linux). Je n'ai rien contre celui qui utilise Maya parce que celui-ci est plus pratique pour certains cas de figure. J'ai quelque chose contre celui qui crache sur Blender en disant que Maya est mieux parce que c'est professionnel et puis de tout manière je m'en cogne, je le pirate.
Pour ton assertion "C++ plus facile pour travailler en entreprise". Je dirais que oui, sur un CV cela le fait mieux (par contre python ou ruby ça peut faire de toi l'élément qui se démarque dans la masse de +/- bon développeurs C++). Pour l'efficacité du travail, cela dépend à mon sens de savoir si tu bosses avec des gens compétents et avec de la rigueur ou pas ? Et je suis d'accord que quitte à faire des conneries, autant le faire avec un système à typage statique qui sera moins permissif. Maintenant, quand je bosse tout seul, je prend mes responsabilités et j'espère ne pas être mauvais. Et quand je m'entoure, j'essaye de m'entourer de gens compétents qui ne se laisseront pas avoir par le risque du typage dynamique et qui sauront profiter de ses avantages.
Pour ton problème d'encodage.
- Soit tu veux travailler sur des caractères et dans ce cas là il te faut faire une conversion et tu dois connaître le format d'entrée et de sortie (en l'imposant ou en demandant à l'utilisateur de le spécifier, si celui-ci ne suit pas cette règle, tu ne peux rien pour lui) et dans ce cas là rien ne t'empêches de convertir son iso-42 en unicode puis en iso-42 (en supposant qu'il existe une fonction de conversion ;)
- Soit tu n'as pas besoin de travailler sur les caractères, et tu peux travailler sur un bytes (le type python3 ~ char[]) et ainsi il n'y aura pas de caractère qui disparaît en sortie.
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++.
- Tu peux bidouiller tes chaînes à coup d'opérateurs de bit, après il faut voir si cela à un sens (sur une chaîne char[], certainement, et encore je ne vois pas grand chose à faire de plus que le changement de case avec ^ (1 << 5))
- Tu peux décharger des modules, après faut voir si cela à un sens
- Tu peux faire de la programmation de carte graphique en Python ;)
- Tu peux aussi te demander en C++ si les 30 lignes que tu as écris seront aussi rapide que du Python (Je pense par exemple au hashmap qui n'existent pas dans la STL). Je joue souvent un jeu marrant avec mes collègues, élèves ou autre qui me disent que python est lent, je leur demande de me fournir un bout de code C++ qui est selon eux rapide et un bout de code python qui est selon eux lent. Très souvent je peux récrire leur bout de python pour qu'il soit plus rapide que leur bout de C++ (bon, je peux aussi récrire le bout de C++ pour qu'il soit plus rapide que le bout de Python ;)
Si les mecs en école d'ingé. oublient des {}, je vois pas pourquoi ils n'oublieraient pas des espaces.
Je me demande aussi, mais figure toi que j'ai aussi ce problème. Je ne fais presque jamais d'erreur de syntaxe en Python, je passe mon temps à en faire en C++... Mais je suis certainement biaisé en C++ du fait de mon expérience python. (Enfin j'ai fais plus de C++ dans ma vie que de python...)
En plus, ça permet de ré-indenter facilement, avec un outil tel que GNU indent.
Ça c'est (à mon avis) un faux argument. Pourquoi ré-indenter ? Cela signifie que ton indentation n'a qu'une valeur cosmétique, donc cela ne sert a rien d'indenter. Si cela ne sert a rien, pourquoi le faire non ? Donc cela sert à quelque chose. Donc il faut indenter, et tous indenter de la même manière au sein d'un projet, donc l'indentation a un sens ? Tient, ce sens est vraiment proche des blocs que je délimite par des {} et ;. C'est meme tellement proche que je me demande pourquoi je duplique l'information... En fait l'indentation significative : "ça permet de remettre facilement les {}; avec un outil tel que GNU jemetlesaccollades"