je croyais que mimetype était une commande courante… bon je vais regarder ça, merci.
Courante ne veux pas dire commune (pas dans le sens de la rareté, mais dans le sens ou tout le monde l'a). Sous un système libre, il est très peu probable que tout le monde ait les mêmes commandes, et c'est encore pire quand on parle de l'environnement d'un logiciel portable… je suis bien placé pour le savoir, je suis tombé plus d'une fois sur des bugs de logiciels/paquets dus à un système minimal*:
Sinon, pour répondre à la question de l'auteur de ce fil, sous Debian, avec le paquet "command-not-found":
~$ mimetype
The program 'mimetype' is currently not installed. To run 'mimetype' please ask your administrator to install the package 'libfile-mimeinfo-perl'
mimetype: command not found
*: dans l'ordre: install de Debian avec aucun outil coché, nettoyage des paquets non essentiels installés malgré tout (une bonne 30aine l'air de rien), désactivation de l'installation automatique des paquets recommandés, et enfin installation de ma sélection de logiciels… et par la suite, ça bouge régulièrement machine de dev oblige, avec parfois des purges manuelles du système. Je n'ai jamais plus de 1200 paquets installés sur une machine perso (à cause des libs de dev, surtout (mention spéciale pour la SDL d'ailleurs), sinon sur une machine «normalle» j'avoisine les 800).
Chez moi (azerty sous Debian 7), AltGr-Maj-8 donne ceci: '¯' (underscore en haut… sais pas à quoi ça sert mais bon :) ). Je viens de tester les autres combo AltGr-Shift et AltGr, et rien… à moins que je n'aie raté une touche, bien sûr.
Si tu veux un autre site pour la pub, et pour des code review, je pense que www.developpez.com pourrait être une piste. En plus, la bas, aucun risque de se faire démolir pour cause de non-respect des 4 libertés ;) (oui je sais, tu as ouvert depuis…)
PS: vu que j'ai la flemme de faire 2 posts pour si peu: pour synchro ton git sur github (ou bitbucket, ou savannah, ou sourceforge, ou… peu importe il y en a une pléthore) tu peux tout bêtement faire un hook sur ton git principal pour qu'à chaque commit (sur la branche master, peut-être? À toi de voir) ça envoie direct sur tes miroirs.
Ta méthode pour les string n'existe pas en C++ (pas en standard en tout cas, puisque quelqu'un à pointé vers une implem boot) ;)
Je t'avoue que dès que je peux éviter de ramener une dépendance externe à un projet, je le fait. Pour ça que je suis très content de l'accélération qu'à prise le C++ pour ses nouvelles versions, franchement on y à gagné pas mal. Y'a plus qu'a mettre à jour les sources des softs, mais pour ça faut qu'on MaJ les cibles aussi :p
L'usage me paraît un peu space aussi, mais c'est normal j'imagine, je ne suis pas habitué au Java et son tout-objet (autre sujet, vaste).
Pour le find, j'imagine que le C++ hérite d'une plus grande habitude des classes/fonctions génériques, ça doit aider pas mal. Si je ne m'abuse, Java n'à implémenté la généricité que bien après C++.
Même si la STL est très pauvre comparé aux lib standard java, elle à quand même le mérite d'être puissante, et depuis 2011 d'être utilisable (un peu tard, je sais).
Je ne connaissais pas guava, mais à en croire wikipedia, ça à été motivé par l'introduction de la généricité dans java (2007?), du coup ça deviens logique que ça fasse bien les choses: c'est tellement moins chiant de n'implémenter qu'une fois les algo, puis de les optimiser en fonction du conteneur sous-jacent…
Je note, surtout qu'il y à un fort risque (c'est au niveau de la certitude en fait, sauf si je trouve un taf ailleurs) que je sois affecté à une vieille usine à gaz (intérêt technique faible, code sale --j'y ai déjà perdu un œil--, dépendance au Flex 3 et à postresql 8.X. Ça risque d'être mon rôle principal que de MaJ ce truc… snif… d'ailleurs, si quelqu'un connaît un moyen d'utiliser Flex Builder 3 aka eclipse+flash sous linux, suis preneur… je n'ose rêver d'une conversion du code en truc plus moderne permettant de se passer de flash) codée en Java.
sur des cas particuliers, C++ peut être plus rapide que C
Me semble avoir vu un papier sur l'utilisation de la fonction C sort, contre je ne sais plus quel algo générique C++ ou le C++ était effectivement supérieur. Mais supérieur à mon avis uniquement à l'implémentation standard C.
Le troisième niveau, le "vrai" niveau,
Je vois. Arguments intéressants, en effet, l'usage des fonctionnalités supplémentaires du C++ risque d'alourdir le programme en terme de performances. La RTTI, les exceptions (quoique, dans ce cas précis, je me demande quel est le plus lourd dans le chemin non-exceptionnel, entre un programme C++ et un programme C qui vérifie tout) et surtout, surtout les méthodes virtuelles… tout ça coûte cher.
Appeler du code sans en faire exprès est également simple. Trop simple même, et c'est probablement pour ce genre de raisons que Bjarne Stroustrup à dit «C++ has indeed become too "expert friendly"».
Pour la STL, à fonctionnalité égale, c'est à dire avec une struct C et son ensemble de fonctions accompagnatrices, je suis déjà plus mitigé. Pour vector et array, je ne vois pas de raison (je pense que c'est égal), pour std::list par contre oui, parce que c'est une implem de liste chaînée non intrusive. Bien qu'on puisse la réimplémenter en intrusif, je doute que ce soit la première étape que prendra un développeur C++. Dans le cas de map et set, je n'en sais rien du tout.
une sorte de langage indéterminé qui mélange les idiomes des deux langages.
Je vois. Donc pour toi, mêler les deux langages résulte dans un code bâtard. Personnellement, je considère qu'il s'agit de C++ pur, parce qu'un des axes de C++ c'est de ne payer que pour ce que l'on utilise (que ce soit les classes, les algo standards, la RTTI, les exceptions… un code C qui n'utiliserait que std::array et les casts plus sûrs de C++ deviendrait à mes yeux du C++).
il n'existe pas encore de religieux intégristes du C++
Ce serait dommage, compte tenu du fait que le C++ est un langage qui me semble plutôt pragmatique, notamment rien n'empêche l'usage de GC ou de tout objet (ah, si, il faut obligatoirement créer une fonction main pour appeler une méthode statique main de la classe principale… mais à part ça, je vois pas)..
Mais personnellement je trouve que c'est dommage de perdre la sémantique (un std::string n'est pas un std::vector en C++)
C'est vrai. Par contre je me demande s'il y a beaucoup de différences entre les implem des deux.
sans compter qu'il n'est pas impossible que le compilo détecte les concaténation de chaines constantes, et que plus le code est clair, plus le compilo est efficace
Je ne sais pas si le compilateur est capable de détecter qu'un membre d'une classe n'est jamais accédé (cas d'un string jamais modifié, par exemple, qui pourrait être remplacé par un std::array). D'ailleurs, il ne vaudrait mieux pas: si, au cours d'une modification d'un programme, un string passe en const, le compilo le remplace à la compilation par un array, ça risque de péter l'ABI sans raison.
Et je ne suis pas non plus persuadé que l'efficacité du compilateur soit plus importante quand le code est clair: il peut être clair pour son auteur, mais pas pour le compilateur. Il n'y à rien de plus débile qu'un compilo quand il s'agit de deviner ce qu'un programmeur essaie de faire après tout.
Je me trompe peut-être, mais est-ce qu'on n'en demande pas trop parfois au compilateur? Certes, pour des trucs (un paramètre d'une fonction non nommé et donc jamais utilisé par la fonction ne sera pas mis dans le binaire par exemple) on peut lui faire confiance, mais à un moment faire toujours confiance aux autres pour faire son propre job, me paraît délicat.
Dans le cas du goto que j'ai mis en exemple, il y avait effectivement une meilleure implémentation, celle avec le while. Pas de goto, donc un risque en moins, pas de répétition de code, donc maintenance moins dangereuse, et on évite de coller un if qui sera peut-être, ou pas, optimisé par le compilateur. Qui sera peut-être même bugué d'ailleurs (qui n'à jamais fait de faute d'étourderie dans un if?).
D'ailleurs, ce if, il ne sera pas optimisé par le compilateur en débogage, je me trompe? C'est peut-être une micro optim, c'est vrai, mais est-elle illisible? Et si ce n'est pas le cas, pourquoi ne pas l'utiliser?
Non, il n'y a pas plus d'outils de dev sur Linux. Tout ce que tu trouves sur Linux je te le trouves sur Windows, et plus
Quand j'installe windows, je n'ai pas de compilo installé de base. Quand j'installe une lib sous windows, c'est pénible pour configurer l'environnement de dev pour qu'il la prenne en compte. Enfin, j'exagère, quand je l'installe ça va encore, là ou c'est très lourd, c'est quand il faut la compiler et la déployer sur la machine locale…
Sous linux, je trouve ça plus simple, moi.
Je ne parle pas de la lourdeur de VS, parce que le dernier que j'ai testé fêtera cette année ses 7 ans. Ça c'est peut-être amélioré depuis. Je ne dis pas que travailler avec VS est désagréable, au contraire, juste que la machine doit être assez musclée niveau accès disques. Du moins l'était. C'est d'ailleurs le principal reproche que je lui fait, parce que pour le reste il était plutôt bien foutu.
Certainement pas plus efficaces, j'en fait l'amère expérience cette année, Linux et C/C++ c'est la préhistoire comparé à Windows et Visual Studio. Je crois que je préférerais me prendre un waterboarding vu à quel point c'est douloureux.
Ah, ça, GCC c'est une perle… noire, c'est clair. Prends Clang, plutôt.
les man pages c'est comment dire… basique et sérieusement incomplèt. Tu prends MSDN t'as tout autant d'infos, mais t'as aussi des tas d'exemples, des graphiques et diagrammes, c'est facile de les garder en bookmark …
La dernière fois que j'ai eu à utiliser MSDN, il y avait tellement d'infos, non relatives à ce que je cherchais, que j'ai abandonné et pris duckduckgo pour trouver l'info.
D'ailleurs, je doute que la MSDN aie des informations sur les APIs linux? Ne pas oublier la cible: du temps réel sur linux.
D'un autre côté, un dev va pas faire tourner la version optimisée, mais la version de débogage, voire faire tourner des outils d'analyse en sus (gdb, valgrind) et franchement, la différence est la même qu'entre une nouvelle lune nuageuse et un midi ensoleillé du mois de juillet…
Chez moi quand j'avais essayé d'installer Xorg, il avait refusé à cause de problèmes de dépendances. Je n'ai pas pu aller plus loin, et j'avoue que l'expérience m'à échaudé.
Vu que ce journal est dédié aux FPS libres, je me permets un petit lien vers un autre FPS plutôt digne de ce nom.
Pour avoir joué à Nexuiz, le père de Xonotic, je sais que ça se qualifie vraiment dans le style de quake, très nerveux et de mémoire pas mal de tricks basés sur le rocket jump.
ET je connais pas mais je l'imagine dans le style classique réaliste, et si Unvanquished est très bon jeu, j'avoue ne pas trop avoir de catégorie tout faite ou de jeu pour le comparer.
Pour moi, redeclipse (basé sur le moteur de cube2) se positionne plutôt dans la direction d'unreal tournament, le rocket jump il faut oublier: le seul lance-rocket du jeu dégomme tout ce qui se trouve dans les 10-20m (à vue de nez, je n'ai jamais pris le temps de mesurer). Mais il faut le trouver, le prendre et il n'à qu'une seule charge… heureusement.
Pour le reste des armes, elles ont vraiment toutes leur utilité, et sont équilibrées (je n'en dirais pas autant de Nexuiz, soyons honnêtes).
Les mouvements sont par contre à la fois simples à utiliser mais complexes à maîtriser: il y à une touche qui permets de rebondir à atterrissage d'un saut ou de courir sur les murs (ça pompe dans la stamina par contre, donc temps limité).
Pas mal de gameplays différents et de mods intégrés officiellement au jeu, également.
Les bots, s'ils ne sont pas exceptionnels, sont respectables, ne se bloquent pas dans des endroits comme des cons, et ça aide à apprendre à jouer avant de s'aventurer sur la toile. D'ailleurs, il existe un mode de jeu humain vs bots, et l'on peut configurer le talent des bots (hum… je ne sais pas si ce n'est pas juste leurs caracts qui sont boostées… faudrait aller regarder tiens) et dans ce mode précis, le nombre de bots par joueurs (dans un fichier de conf, comme pour la difficulté). Franchement, à partir de 2 vs 1, ça deviens fun. Ah, et puisqu'il est fait mention d'un nouveau mode invasion dans nexuiz, il y à un modificateur du même style dans redeclipse. Sur certaines map c'est vite injouable, on passe son temps à frag (ou se faire frag) par des sortes de zombies sans croiser l'ennemi. Ça doit être configurable aussi, mais jamais cherché.
Niveau machine, il tourne sur des machines bien moins puissantes que Nexuiz (et donc je présume Xonotic) sans le moindre souci et sans être dégueu. Pour les graphismes, justement, il correspond à mes besoins, aussi laxistes soient-ils: pas de pixels sales, pas de couleurs tape-à-l'œil, des cartes pas toutes juste carrées… C'est pas sublime, mais c'est bien assez beau pour pourrir des adversaires.
Ah, et pour finir, il est intégré dans Debian, mais sur Wheezy c'est une vieille version. Il vaut mieux activer les backports pour avoir une version propre. Niveau licence, Debian le classe dans contrib pour le moteur, non-free pour les data, mais la FAQ indique, elle:
Red Eclipse itself and the Cube Engine 2 are under the zlib License.
All content in the game is Free, and no more strict than the Creative Commons CC-BY-SA license.
Du coup, je ne sais pas trop quoi croire. Je n'ai jamais pris la peine de vérifier non plus.
De toute façon, je pense que ce serait dommage d'essayer les 3 jeux du journal et de passer à côté de celui-ci ;)
Cet argument il est naze, Arch Linux m’a jamais pété
Chez moi ça marche TM?
L'avantage d'une distro non rolling-release, c'est que pendant un certain temps tu n'a que des MaJ de sécurité: pas d'ajout/suppression de fonctionnalités, ce qui rend les choses quand même plus simples à maintenir.
Dans une rolling release, j'aurai personnellement beaucoup de mal à mettre à jour, sauf si je sais que les dev du logiciel en question maintiennent officiellement une version stable.
On peut, c'est vrai, mais c'est parce que ce langage ambitionnes d'être compatible avec le C.
Moi, je vois un cast C-style en C++, je me dis "Hé merde… ça, ça pue". Si je vois un static_cast, je suis plutôt confiant, un dynamic_cast, je vérifie si il y à une gestion des exceptions ou de pointeur null, et reinterpret_cast, je relis le code à plusieurs reprises, mais au moins je sais que c'est dangereux.
Contrairement au cast C-style, ou je me dis que ça pue parce que ça peut être l'équivalent de n'importe quel autre cast.
Finalement, plus le temps passe, plus j'ai l'impression que le plus gros défaut de C++ est sa compatibilité avec le C… mais c'est aussi ce qui fait qu'on peut utiliser sans prise de tête des libs codées en C, à la qualité aléatoire.
Moi j'ai une préférence pour DRY.
C'est justement un principe pour éviter les coûts de maintenance.
Tu dis que l'on aura peut-être pas de problème de perf sur cet endroit. Moi je te répondrai donc qu'il y en aura peut-être. Sur de petits bouts de code fréquemment utilisés, j'ai tendance à penser que je préfère connaître une version optimisée, qui n'ajoute au fond pas grand chose niveau complexité de lecture (mais la version du while est nettement supérieure, clairement) mais qui me permette de ne pas avoir à me poser la question si oui ou non c'est un endroit qui risque d'alourdir.
Et en bonus : une implémentation de cette fonction par des gens qui connaissent un peut le C++ et bizarrement, pas de goto !
C'est une raison pour laquelle j'utilise dès que je le peux les algos de la STL.
Il y à la performance, et il y à la maintenance. C'est surtout le 2nd qui me pose problème: un code copié une fois, j'ai toujours peur que quelqu'un arrive, modifie un truc à un endroit et zape l'autre copie…
Sinon, c'est moi ou ton exemple ne gère que les string?
Comme vérifier qu'un conteneur contient bien un élément donné.
std::find, en C++. Fonctionne sur tous les conteneurs standards, du foo* au std::multi_map en passant par std::array. La STL à pas mal de ces petits algo qui sont devenus subitement utilisables depuis 2011, mais celui cité manque toujours.
Bah, tu as le choix entre une Ferrari et une berline
Si le C++ est une berline, qui est la Ferrari? Le C, ou l'assembleur?
Je ne vois pas vraiment de raison pour que le C++ soit plus lent que le C.
Je vois 3 corrections à faire dans mon code, si j'avais vraiment voulu l'utiliser dans un vrai programme:
vérifier que le tableau est pas vide (mais j'ai utilisé un array statique ici donc il n'y à aucun risque au runtime)
utiliser des char[] dans l'array, et pas des std::string
réserver correctement dès le début l'espace que le std::string occupera à la fin (on le connaît, puisque tout est statique, et au pire on pourrait le calculer) pour éviter les realloc.
Mais c'était censé être un code à la va-vite, rien de plus, pas un code parfait ;)
En tout cas merci pour ta solution.
Par curiosité, le compilo ne détecte pas la duplication de code quand tu fais quelque chose comme:
Aucune idée. Par contre je sais que le cerveau humain, lui, n'est pas toujours capable de fusionner un bout de copié/collé, surtout que tu peux avoir plus que quelques lignes de code. Encore une fois, ici, c'était un exemple trivial.
parfois j'ai des doutes… parce que certaines merdes que je vois nécessitent plus de motivation pour faire de la merde que du travail propre, ou alors ignorer qu'on peut faire proprement…
[^] # Re: Autre site pour la pub
Posté par freem . En réponse au journal [Trackgame] Jeu de course vectoriel au tour par tour. Évalué à 2.
Publicité, dans ce cas, parce que publication signifierai qu'il héberge non?
[^] # Re: ROX-Filer
Posté par freem . En réponse au journal Mes nautilus scripts. Évalué à 2.
Courante ne veux pas dire commune (pas dans le sens de la rareté, mais dans le sens ou tout le monde l'a). Sous un système libre, il est très peu probable que tout le monde ait les mêmes commandes, et c'est encore pire quand on parle de l'environnement d'un logiciel portable… je suis bien placé pour le savoir, je suis tombé plus d'une fois sur des bugs de logiciels/paquets dus à un système minimal*:
Sinon, pour répondre à la question de l'auteur de ce fil, sous Debian, avec le paquet "command-not-found":
~$ mimetype
The program 'mimetype' is currently not installed. To run 'mimetype' please ask your administrator to install the package 'libfile-mimeinfo-perl'
mimetype: command not found
*: dans l'ordre: install de Debian avec aucun outil coché, nettoyage des paquets non essentiels installés malgré tout (une bonne 30aine l'air de rien), désactivation de l'installation automatique des paquets recommandés, et enfin installation de ma sélection de logiciels… et par la suite, ça bouge régulièrement machine de dev oblige, avec parfois des purges manuelles du système. Je n'ai jamais plus de 1200 paquets installés sur une machine perso (à cause des libs de dev, surtout (mention spéciale pour la SDL d'ailleurs), sinon sur une machine «normalle» j'avoisine les 800).
[^] # Re: Debian fait partie du passé
Posté par freem . En réponse à la dépêche Debian 7.8, huitième mise à jour de Wheezy. Évalué à 3.
Chez moi (azerty sous Debian 7), AltGr-Maj-8 donne ceci: '¯' (underscore en haut… sais pas à quoi ça sert mais bon :) ). Je viens de tester les autres combo AltGr-Shift et AltGr, et rien… à moins que je n'aie raté une touche, bien sûr.
# Autre site pour la pub
Posté par freem . En réponse au journal [Trackgame] Jeu de course vectoriel au tour par tour. Évalué à 4.
Si tu veux un autre site pour la pub, et pour des code review, je pense que www.developpez.com pourrait être une piste. En plus, la bas, aucun risque de se faire démolir pour cause de non-respect des 4 libertés ;) (oui je sais, tu as ouvert depuis…)
PS: vu que j'ai la flemme de faire 2 posts pour si peu: pour synchro ton git sur github (ou bitbucket, ou savannah, ou sourceforge, ou… peu importe il y en a une pléthore) tu peux tout bêtement faire un hook sur ton git principal pour qu'à chaque commit (sur la branche master, peut-être? À toi de voir) ça envoie direct sur tes miroirs.
[^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..
Posté par freem . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 2.
J'ai déjà répondu à une autre solution que c'était nettement mieux.
[^] # Re: Debian fait partie du passé
Posté par freem . En réponse à la dépêche Debian 7.8, huitième mise à jour de Wheezy. Évalué à 3.
Plutôt un jeu de mots :)
[^] # Re: Debian fait partie du passé
Posté par freem . En réponse à la dépêche Debian 7.8, huitième mise à jour de Wheezy. Évalué à 3.
Et comment tu le saisis au clavier?
[^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..
Posté par freem . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 2.
Ta méthode pour les string n'existe pas en C++ (pas en standard en tout cas, puisque quelqu'un à pointé vers une implem boot) ;)
Je t'avoue que dès que je peux éviter de ramener une dépendance externe à un projet, je le fait. Pour ça que je suis très content de l'accélération qu'à prise le C++ pour ses nouvelles versions, franchement on y à gagné pas mal. Y'a plus qu'a mettre à jour les sources des softs, mais pour ça faut qu'on MaJ les cibles aussi :p
L'usage me paraît un peu space aussi, mais c'est normal j'imagine, je ne suis pas habitué au Java et son tout-objet (autre sujet, vaste).
Pour le find, j'imagine que le C++ hérite d'une plus grande habitude des classes/fonctions génériques, ça doit aider pas mal. Si je ne m'abuse, Java n'à implémenté la généricité que bien après C++.
Même si la STL est très pauvre comparé aux lib standard java, elle à quand même le mérite d'être puissante, et depuis 2011 d'être utilisable (un peu tard, je sais).
Je ne connaissais pas guava, mais à en croire wikipedia, ça à été motivé par l'introduction de la généricité dans java (2007?), du coup ça deviens logique que ça fasse bien les choses: c'est tellement moins chiant de n'implémenter qu'une fois les algo, puis de les optimiser en fonction du conteneur sous-jacent…
Je note, surtout qu'il y à un fort risque (c'est au niveau de la certitude en fait, sauf si je trouve un taf ailleurs) que je sois affecté à une vieille usine à gaz (intérêt technique faible, code sale --j'y ai déjà perdu un œil--, dépendance au Flex 3 et à postresql 8.X. Ça risque d'être mon rôle principal que de MaJ ce truc… snif… d'ailleurs, si quelqu'un connaît un moyen d'utiliser Flex Builder 3 aka eclipse+flash sous linux, suis preneur… je n'ose rêver d'une conversion du code en truc plus moderne permettant de se passer de flash) codée en Java.
[^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..
Posté par freem . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 3.
Me semble avoir vu un papier sur l'utilisation de la fonction C sort, contre je ne sais plus quel algo générique C++ ou le C++ était effectivement supérieur. Mais supérieur à mon avis uniquement à l'implémentation standard C.
Je vois. Arguments intéressants, en effet, l'usage des fonctionnalités supplémentaires du C++ risque d'alourdir le programme en terme de performances. La RTTI, les exceptions (quoique, dans ce cas précis, je me demande quel est le plus lourd dans le chemin non-exceptionnel, entre un programme C++ et un programme C qui vérifie tout) et surtout, surtout les méthodes virtuelles… tout ça coûte cher.
Appeler du code sans en faire exprès est également simple. Trop simple même, et c'est probablement pour ce genre de raisons que Bjarne Stroustrup à dit «C++ has indeed become too "expert friendly"».
Pour la STL, à fonctionnalité égale, c'est à dire avec une struct C et son ensemble de fonctions accompagnatrices, je suis déjà plus mitigé. Pour vector et array, je ne vois pas de raison (je pense que c'est égal), pour std::list par contre oui, parce que c'est une implem de liste chaînée non intrusive. Bien qu'on puisse la réimplémenter en intrusif, je doute que ce soit la première étape que prendra un développeur C++. Dans le cas de map et set, je n'en sais rien du tout.
Je vois. Donc pour toi, mêler les deux langages résulte dans un code bâtard. Personnellement, je considère qu'il s'agit de C++ pur, parce qu'un des axes de C++ c'est de ne payer que pour ce que l'on utilise (que ce soit les classes, les algo standards, la RTTI, les exceptions… un code C qui n'utiliserait que std::array et les casts plus sûrs de C++ deviendrait à mes yeux du C++).
Ce serait dommage, compte tenu du fait que le C++ est un langage qui me semble plutôt pragmatique, notamment rien n'empêche l'usage de GC ou de tout objet (ah, si, il faut obligatoirement créer une fonction main pour appeler une méthode statique main de la classe principale… mais à part ça, je vois pas)..
C'est vrai. Par contre je me demande s'il y a beaucoup de différences entre les implem des deux.
Je ne sais pas si le compilateur est capable de détecter qu'un membre d'une classe n'est jamais accédé (cas d'un string jamais modifié, par exemple, qui pourrait être remplacé par un std::array). D'ailleurs, il ne vaudrait mieux pas: si, au cours d'une modification d'un programme, un string passe en const, le compilo le remplace à la compilation par un array, ça risque de péter l'ABI sans raison.
Et je ne suis pas non plus persuadé que l'efficacité du compilateur soit plus importante quand le code est clair: il peut être clair pour son auteur, mais pas pour le compilateur. Il n'y à rien de plus débile qu'un compilo quand il s'agit de deviner ce qu'un programmeur essaie de faire après tout.
Je me trompe peut-être, mais est-ce qu'on n'en demande pas trop parfois au compilateur? Certes, pour des trucs (un paramètre d'une fonction non nommé et donc jamais utilisé par la fonction ne sera pas mis dans le binaire par exemple) on peut lui faire confiance, mais à un moment faire toujours confiance aux autres pour faire son propre job, me paraît délicat.
Dans le cas du goto que j'ai mis en exemple, il y avait effectivement une meilleure implémentation, celle avec le while. Pas de goto, donc un risque en moins, pas de répétition de code, donc maintenance moins dangereuse, et on évite de coller un if qui sera peut-être, ou pas, optimisé par le compilateur. Qui sera peut-être même bugué d'ailleurs (qui n'à jamais fait de faute d'étourderie dans un if?).
D'ailleurs, ce if, il ne sera pas optimisé par le compilateur en débogage, je me trompe? C'est peut-être une micro optim, c'est vrai, mais est-elle illisible? Et si ce n'est pas le cas, pourquoi ne pas l'utiliser?
[^] # Re: Debian fait partie du passé
Posté par freem . En réponse à la dépêche Debian 7.8, huitième mise à jour de Wheezy. Évalué à -1.
Tu devrais porter plainte, je suis sûr que les forces de l'ordre n'accepteront pas qu'Arch soit inefficace dans sa gestion de la police hehe
[^] # Re: Debian fait partie du passé
Posté par freem . En réponse à la dépêche Debian 7.8, huitième mise à jour de Wheezy. Évalué à 3.
Tu m'étonnes. Je suis sûr que d'ici 4 ans on trouera encore des serveurs sous windows 2003…
[^] # Re: Debian fait partie du passé
Posté par freem . En réponse à la dépêche Debian 7.8, huitième mise à jour de Wheezy. Évalué à 3.
Je sais pas faire les TM en apposé… Ou mieux, dans un cercle comme pour le ©, histoire d'être nickel :p
[^] # Re: installer Linux nativement
Posté par freem . En réponse au journal Besoin d'arguments pour obtenir une station de travail sous GNU/Linux ?. Évalué à 9.
Quand j'installe windows, je n'ai pas de compilo installé de base. Quand j'installe une lib sous windows, c'est pénible pour configurer l'environnement de dev pour qu'il la prenne en compte. Enfin, j'exagère, quand je l'installe ça va encore, là ou c'est très lourd, c'est quand il faut la compiler et la déployer sur la machine locale…
Sous linux, je trouve ça plus simple, moi.
Je ne parle pas de la lourdeur de VS, parce que le dernier que j'ai testé fêtera cette année ses 7 ans. Ça c'est peut-être amélioré depuis. Je ne dis pas que travailler avec VS est désagréable, au contraire, juste que la machine doit être assez musclée niveau accès disques. Du moins l'était. C'est d'ailleurs le principal reproche que je lui fait, parce que pour le reste il était plutôt bien foutu.
Ah, ça, GCC c'est une perle… noire, c'est clair. Prends Clang, plutôt.
La dernière fois que j'ai eu à utiliser MSDN, il y avait tellement d'infos, non relatives à ce que je cherchais, que j'ai abandonné et pris duckduckgo pour trouver l'info.
D'ailleurs, je doute que la MSDN aie des informations sur les APIs linux? Ne pas oublier la cible: du temps réel sur linux.
[^] # Re: développement n'est pas de la bureautique
Posté par freem . En réponse au journal Besoin d'arguments pour obtenir une station de travail sous GNU/Linux ?. Évalué à 2.
Vi, il y à aussi des con pétant… /me est déjà dehors
[^] # Re: Sérieux?
Posté par freem . En réponse au journal Besoin d'arguments pour obtenir une station de travail sous GNU/Linux ?. Évalué à 1.
Tout dépend de la fonction… même si j'imagine bien que c'est rarement les chefs qui se trimballent les poubelles.
[^] # Re: Sérieux?
Posté par freem . En réponse au journal Besoin d'arguments pour obtenir une station de travail sous GNU/Linux ?. Évalué à 8.
D'un autre côté, un dev va pas faire tourner la version optimisée, mais la version de débogage, voire faire tourner des outils d'analyse en sus (gdb, valgrind) et franchement, la différence est la même qu'entre une nouvelle lune nuageuse et un midi ensoleillé du mois de juillet…
[^] # Re: Debian fait partie du passé
Posté par freem . En réponse à la dépêche Debian 7.8, huitième mise à jour de Wheezy. Évalué à 2.
Chez moi quand j'avais essayé d'installer Xorg, il avait refusé à cause de problèmes de dépendances. Je n'ai pas pu aller plus loin, et j'avoue que l'expérience m'à échaudé.
# au autre FPS sympa: redeclipse
Posté par freem . En réponse à la dépêche Le plein de frags pour cette nouvelle année 2015 (Unvanquished, ET:Legacy, Xonotic). Évalué à 5. Dernière modification le 19 janvier 2015 à 16:46.
Vu que ce journal est dédié aux FPS libres, je me permets un petit lien vers un autre FPS plutôt digne de ce nom.
Pour avoir joué à Nexuiz, le père de Xonotic, je sais que ça se qualifie vraiment dans le style de quake, très nerveux et de mémoire pas mal de tricks basés sur le rocket jump.
ET je connais pas mais je l'imagine dans le style classique réaliste, et si Unvanquished est très bon jeu, j'avoue ne pas trop avoir de catégorie tout faite ou de jeu pour le comparer.
Pour moi, redeclipse (basé sur le moteur de cube2) se positionne plutôt dans la direction d'unreal tournament, le rocket jump il faut oublier: le seul lance-rocket du jeu dégomme tout ce qui se trouve dans les 10-20m (à vue de nez, je n'ai jamais pris le temps de mesurer). Mais il faut le trouver, le prendre et il n'à qu'une seule charge… heureusement.
Pour le reste des armes, elles ont vraiment toutes leur utilité, et sont équilibrées (je n'en dirais pas autant de Nexuiz, soyons honnêtes).
Les mouvements sont par contre à la fois simples à utiliser mais complexes à maîtriser: il y à une touche qui permets de rebondir à atterrissage d'un saut ou de courir sur les murs (ça pompe dans la stamina par contre, donc temps limité).
Pas mal de gameplays différents et de mods intégrés officiellement au jeu, également.
Les bots, s'ils ne sont pas exceptionnels, sont respectables, ne se bloquent pas dans des endroits comme des cons, et ça aide à apprendre à jouer avant de s'aventurer sur la toile. D'ailleurs, il existe un mode de jeu humain vs bots, et l'on peut configurer le talent des bots (hum… je ne sais pas si ce n'est pas juste leurs caracts qui sont boostées… faudrait aller regarder tiens) et dans ce mode précis, le nombre de bots par joueurs (dans un fichier de conf, comme pour la difficulté). Franchement, à partir de 2 vs 1, ça deviens fun. Ah, et puisqu'il est fait mention d'un nouveau mode invasion dans nexuiz, il y à un modificateur du même style dans redeclipse. Sur certaines map c'est vite injouable, on passe son temps à frag (ou se faire frag) par des sortes de zombies sans croiser l'ennemi. Ça doit être configurable aussi, mais jamais cherché.
Niveau machine, il tourne sur des machines bien moins puissantes que Nexuiz (et donc je présume Xonotic) sans le moindre souci et sans être dégueu. Pour les graphismes, justement, il correspond à mes besoins, aussi laxistes soient-ils: pas de pixels sales, pas de couleurs tape-à-l'œil, des cartes pas toutes juste carrées… C'est pas sublime, mais c'est bien assez beau pour pourrir des adversaires.
Ah, et pour finir, il est intégré dans Debian, mais sur Wheezy c'est une vieille version. Il vaut mieux activer les backports pour avoir une version propre. Niveau licence, Debian le classe dans contrib pour le moteur, non-free pour les data, mais la FAQ indique, elle:
Du coup, je ne sais pas trop quoi croire. Je n'ai jamais pris la peine de vérifier non plus.
De toute façon, je pense que ce serait dommage d'essayer les 3 jeux du journal et de passer à côté de celui-ci ;)
[^] # Re: Debian fait partie du passé
Posté par freem . En réponse à la dépêche Debian 7.8, huitième mise à jour de Wheezy. Évalué à 3.
Chez moi ça marche TM?
L'avantage d'une distro non rolling-release, c'est que pendant un certain temps tu n'a que des MaJ de sécurité: pas d'ajout/suppression de fonctionnalités, ce qui rend les choses quand même plus simples à maintenir.
Dans une rolling release, j'aurai personnellement beaucoup de mal à mettre à jour, sauf si je sais que les dev du logiciel en question maintiennent officiellement une version stable.
[^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..
Posté par freem . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 5.
En C++ on aurait pas utilisé de cast C-style.
On peut, c'est vrai, mais c'est parce que ce langage ambitionnes d'être compatible avec le C.
Moi, je vois un cast C-style en C++, je me dis "Hé merde… ça, ça pue". Si je vois un static_cast, je suis plutôt confiant, un dynamic_cast, je vérifie si il y à une gestion des exceptions ou de pointeur null, et reinterpret_cast, je relis le code à plusieurs reprises, mais au moins je sais que c'est dangereux.
Contrairement au cast C-style, ou je me dis que ça pue parce que ça peut être l'équivalent de n'importe quel autre cast.
Finalement, plus le temps passe, plus j'ai l'impression que le plus gros défaut de C++ est sa compatibilité avec le C… mais c'est aussi ce qui fait qu'on peut utiliser sans prise de tête des libs codées en C, à la qualité aléatoire.
[^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..
Posté par freem . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 0.
Moi j'ai une préférence pour DRY.
C'est justement un principe pour éviter les coûts de maintenance.
Tu dis que l'on aura peut-être pas de problème de perf sur cet endroit. Moi je te répondrai donc qu'il y en aura peut-être. Sur de petits bouts de code fréquemment utilisés, j'ai tendance à penser que je préfère connaître une version optimisée, qui n'ajoute au fond pas grand chose niveau complexité de lecture (mais la version du while est nettement supérieure, clairement) mais qui me permette de ne pas avoir à me poser la question si oui ou non c'est un endroit qui risque d'alourdir.
C'est une raison pour laquelle j'utilise dès que je le peux les algos de la STL.
[^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..
Posté par freem . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 1.
Il y à la performance, et il y à la maintenance. C'est surtout le 2nd qui me pose problème: un code copié une fois, j'ai toujours peur que quelqu'un arrive, modifie un truc à un endroit et zape l'autre copie…
Sinon, c'est moi ou ton exemple ne gère que les string?
std::find, en C++. Fonctionne sur tous les conteneurs standards, du
foo*austd::multi_mapen passant parstd::array. La STL à pas mal de ces petits algo qui sont devenus subitement utilisables depuis 2011, mais celui cité manque toujours.[^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..
Posté par freem . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 2.
Si le C++ est une berline, qui est la Ferrari? Le C, ou l'assembleur?
Je ne vois pas vraiment de raison pour que le C++ soit plus lent que le C.
Je vois 3 corrections à faire dans mon code, si j'avais vraiment voulu l'utiliser dans un vrai programme:
Mais c'était censé être un code à la va-vite, rien de plus, pas un code parfait ;)
En tout cas merci pour ta solution.
Aucune idée. Par contre je sais que le cerveau humain, lui, n'est pas toujours capable de fusionner un bout de copié/collé, surtout que tu peux avoir plus que quelques lignes de code. Encore une fois, ici, c'était un exemple trivial.
[^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..
Posté par freem . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 1.
Bien vu!
Pour la liste vide, j'ai fait juste un code simple… Ça n'à rien de compliqué de tester avant de se lancer dans une boucle, après tout.
[^] # Re: 3615 Ma vie
Posté par freem . En réponse au message Projets personnels et emploi comme programmeur. Évalué à 3.
parfois j'ai des doutes… parce que certaines merdes que je vois nécessitent plus de motivation pour faire de la merde que du travail propre, ou alors ignorer qu'on peut faire proprement…