moi1392 a écrit 730 commentaires

Si tu commences, je ne pense pas que cela soit le meilleur livre pour toi.

Je le trouve vraiment très bon, il me semble (mais je dis peut-être des bétises, car je l'ai lu en 2004…) que tout ce qu'il contient est compatible C++98, mais pour autant il y expose des techniques très intéressantes (au niveau implémentation de certains design pattern, et aussi certaines techniques algorithmiques) que j'utilise encore aujourd'hui dans mon travail.
Je le conseillerai à quelqu'un qui connais et a déjà un peu programmé en C++ (au moins un an, avec un petit background en programmation en général, et pourquoi pas avec lu "Design Patterns" avant)

Je ne connais pas beaucoup de bons livres pour débutant, mais je suis sûr que d'autres sauront te renseigner.

Tout se fait à la compilation plutôt qu'à l'exécution.

C'est le constexpr qui permet cela, tu peux sans soucis écrire :

auto total = s(1) + min(12) + h(3);

après je suis d'accord que cela ajoute un peu de lisibilité à certains codes, et aussi cela à l'avantage de proposer un namespace vide, donc pas de risque de collision avec un suffixe "h" qui est déjà défini par l'utilisateur.

Mais ce qui est nouveau dans ton cas d'utilisation, c'est le constexpr qui permet l'évaluation à la compilation.

J'ai lu avec intérêt ton nouveau message, et en ce qui concerne l'utilisation de std::function et std::bind, j'ai plus l'impression qu'il s'agit d'aides pour simplifier l'écriture de functors.

J'utilise déjà des functors sur des méthodes de classe depuis 2005 dans une version très proche (puisqu'inspirée) du livre "Modern C++ Design" de Andrei Alexandrescu.
Qui est d'ailleurs un excellent livre que je conseille à tous ceux qui veulent s'initier à la programmation générique en C++.

Pour ce qui est des littéraux, je ne m'étais jamais penché sur cette spec, et je trouve ça sympa, mais mais je me demande quelle est la différence entre cela et utiliser une fonction normale.
J'ai peut-être raté un truc mais j'ai l'impression que ça n'apporte qu'une nouvelle syntaxe sur des fonctionnalités déjà existantes.

Par contre, les 14 types de containers suivant que tu gères un ensemble ordonné ou non, itérable ou pas, dans un sens ou dans les deux, ça c'est sur que c'est hyper utile en pratique !

heeuuu… les conteneurs sont tout de même le support de base de l'algorithmique…
Combien d'algo chez nous j'ai "optimisé" juste en changeant le conteneur utilisé parce que le "bon" développeur qui l'a écrit ne voyait certainement pas l'intérêt de 14 conteneurs différents…

Tu peux déjà tenter de créer un nouvel utilisateur, juste pour voir si cela règle tes soucis.
Si c'est le cas, au lieu de faire une installation qui t'effacera toutes tes préférences, tu peux te contenter de ne perdre que la config de KDE en supprimant le dossier ~/.kde

Cette phrase m'a paru bizarre : "il se permet donc d'écrire des blocs moins prioritaire, si c'est sur son chemin."

De ce que j'en avais compris à l'époque des disques dur (avec de vrais morceaux de disque à l'intérieur), quand on parlais de "sur le chemin", il s'agit du chemin de la tête de lecture.
Mais puisque qu'un ssd n'a plus de tête de lecture qui se promène, cela ne correspond plus à rien.

Il y a un truc que je n'ai pas compris dans l'histoire ?

C'est un problème mal compris de l'offre et de la demande: certains comme Zenitram pensent que s'il y a une demande, une offre va magiquement apparaître.

Je suis d'accord, mais dans le cas présent c'est un peu différent, les offres étaient déjà là.
Et je pense (et je peux me tromper, c'est bien là le point de désaccord) que si le pipe fixe avant encore une demande raisonnable (= siffisament forte), quelques moteurs existant y seraient resté.

Après, le point que tu soulignes à l'air d'être vrai aussi. Quand la demande est faible et qu'elle va en se réduisant, en dessous d'une certaine limite, comme l'offre disparait, cela "force" un peu à se mettre à niveau si on veut utiliser ce qui sort.

Mais prends l'exemple de kwin, ils on gardé jusqu'à présent (à voir pour la version 5) du code de gestion de pipe fixe pour la composition. Ils auraient pu le virer en disant qu'il marche aussi sans, et que les gens ayant de vieille carte n'ont qu'à pas utiliser d'effets.
Donc s'il y a une demande assez forte pour quelque chose de déjà là, souvent cela reste.

nanim ?

Et la puissance implique aussi un marché! Dans les conseils donnés aux indies, on retrouve souvent faites un jeu pour des machines peu puissantes, ça représente beaucoup de clients.

Peut-être, mais quand tu développe ton cadriciel, tu le fais pour les jeux qui ont besoin de peu de puissance ET ce qui en veulent plus.
après, il y a peut-être un marché pour des cadriciel de rendu 3D pour des machines à pipe fixe, mais j'ai l'impression qu'il est très faible, sinon ils seraient très utilisés, surtout dans du logiciel libre ou la maintenant coûte beaucoup moins cher que l'évolution/la réécriture.
S'ils évoluent tous et que (peu de) personne ne conserve les anciennes versions, c'est que la demande doit être vraiment très faible, tu ne penses pas ?
Après, tu fais parti de cette demande, et je comprends que ça te fasse chier, ça m'embêterai sûrement aussi.

Enfin, aujourd'hui, machine peu puissante != pipe fixe ou programmable.
On considère que les pipes sont tous programmables et que les puces graphiques peu puissantes sont celles qui on peu de coeurs de calcul, peu de mémoire et une fréquence basse.

Ce qui m'embête dans cette histoire, c'est qu'on exclue des PC, pas pour des raisons de puissance (un GPU à pipeline fixe peut envoyer du polygones par seconde), mais de technologie.

Pour un cadriciel, la technologie implique la puissance, car tu ne sais pas dans quel contexte il va être utilisé.

C'est vrai que c'est dommage d'abandonner les vieilles cartes, et quand tu codes un nouveau truc qui n'as pas forcément besoin de beaucoup de puissance, tu peux te contenter d'OpenGL 1.x

Mais d'un autre coté, je ne blâme pas les dev, cela offre tellement de souplesse et ouvre tellement de possibilités de jouer avec le pipe de rendu, que je comprends qu'on y passe à un moment.
Moi même, dès que j'ai envie de faire un truc un poil pas simple, si je peux, je passe par des shader.

Tu peux aussi voir le coût en maintenance. Ajouter des fonctionnalités sur un pipe fixe, souvent ça complexifie beaucoup, ou alors il faut revoir en profondeur l'architecture de ton moteur.
Coté shader, dès fois ça se fait en une demi journée !

Ben moi le X, je préfère quand c'est tout nu !

Argument difficile à contrer.

Pas vraiment non… une arme à feu est faite pour tuer !
Pas un logiciel (en tous cas, pas un logiciel de compta…) ni un marteau, ni une voiture.

Après, effectivement, on peut tuer quelqu'un avec un marteau ou une voiture (ou un logiciel de compta pour chuck norris)

Mais vendre un objet dont le but est de tuer en disant que c'est pas la faute de cet objet mais des gens qui l'utilisent, et donc que sa vente ne pose pas de soucis en elle même, c'est un peu (sarcasme) se moquer du monde quand même…

Pour rebondir sur cette phrase :

Des logiciels qui disparaissent, ça arrive. Mais des logiciels qui s'ouvrent, se libèrent et deviennent très utilisés voire incontournables, cela est déjà arrivé. Winamp pourrait suivre le chemin tracé par, entre autres, Mozilla et Blender.

Je pense que Mozilla et Blender ont comblé de gros vides à leur époque, alors que là, des logiciels de lecture multimédia de qualité, il y en a déjà pas mal, et j'ai du mal à imaginer que winamp puisse remplacer vlc ou mplayer au moins dans mon utilisation quotidienne.

La langue que je préfère à l'écoute, le bon allemand, je trouve quel sonne bien à l'oreille.

Comment dire…
Les fauves sont souvent dressés en anglais et en allemand !
L'anglais parce que les mots sont courts et simple, plus facile à mémoriser et à comprendre, et l'allemand parce que les sonorités sont plus sèches et rudes, cela donne plus d'autorité !

Source, un reportage arte, mais on trouve aussi quelques références la dessus sur le web :
http://www.lefigaro.fr/cinema/2012/12/21/03002-20121221ARTFIG00572-l-homme-qui-murmure-a-l-oreille-des-fauves.php
http://www.lepetitnicois.fr/article/fr%C3%A9d%C3%A9ric-edelstein-un-lion-parmi-les-lions-46889.html

L'allemand, la langue qui fait peur aux lion…

ça dépends, si c'est 99% du driver ou 99% du code du driver qui est compatible, au final, aucun ne marche…

il y a des paquets garmin-ant-downloader et garmin-forerunner-tools au moins sous debian.
Remarque, la dernière fois que j'ai tenté de récuperer mes données, ça n'avais pas marché.
L'outil (qui utilise libusb en interne) n'arrivait pas à reconnaitre le dongle alors qu'il était reconnu avec lsusb.
Après une petite séance de débogage, j'ai compris que le bogue était dans l'utilisation de libusb et que la méthode de lsusb fonctionnait mieux, j'aivais entrepris de porter le bouzin, mais sans succes… (faut dire aussi que si j'y avait passé plus d'une heure, j'aurais eu plus de chances…)
Si tu as des nouvelles de ce front, ça m'intéressse (je referai peut-être une tentative un de ces 4)

Ça à l'air chouette ! du coup je m'y suis inscrit !
S'il y a des linuxéfairiens qui seront sur place on pourrait profiter de l'occasion de se croiser et découvrir un peu qui on moinsse à longueur de journée :)

Je pense surtout qu'on y arrive naturellement en codant le chose et en apprenant de ses erreur et projets passés.
Quand j'ai lu ton message sur le entity system, beaucoup de choses mon paru naturelles alors que je ne m'étais jamais renseigné sur le sujet.
Le truc qui est cool par contre, c'est d'arriver à la formaliser, à comprendre ce qu'il y a d'intéressant, à voir aussi les défauts, pour ne pas l'utiliser à toutes les sauces (un peu comme quand tu découvres l'héritage ou les templates… j'en ai mis partout et nimporte comment moi :D)

tu sais que si tu arrives à me faire me lancer dans un projet, je te maudirai jusqu'à la 1392ème génération ?

si tu veux on se fait une séance de code revue un de ces 4 et je te dit ce que j'en pense.
Sans trop rentrer dedans ni trop connaitre, ça sera plutôt des considérations esthétiques, mais c'est toujours ça de pris !

En fait, c'est plus le projet en lui même qui m'embete.
Comme je l'ai déjà écrit dans un message sur une de tes dépêches, j'ai écrit un petit moteur de RPG quand j'étais étudiant qui faisait des trucs sympa. Les graphismes étant honteusement pompés de jeux proprios et libres (secret of mana, the mana world et rpg maker 95)
Mais je me suis fait avoir car il me manquait la partie screenbord et plan de ce que je voulais vraiment. Et je sais que là, je n'ai pas plus avancé là dessus.

Ce qui me motiverai plus, ça serait un projet plus petit, genre un moteur de defense tower assez customizable pour que les gens puissent faire leur propre lvl et modifiant la difficulté, voir certaines règles de base.
Là je serait partant ! Mais l'autre soucis est que je suis très stricte et exigeant sur la qualité du code, du coup ça serait trop chiant de bosser avec moi et je me ferais jeter de la team illico :D

tu utilises debian !!
Je savais que tu étais quelqu'un de bien, malgrès tes déviances java :D

ha, tu parles de ton nouveau project, moi je pensais à newton adventure !

C'est ce que j'ai cru comprendre et je me suis à un moment posé la question :)
Et je me suis trouvé une autre excellente excuse pour eviter d'entrer dans un projet qui me prendra beaucoup de temps.
Reste plus qu'à me souvenir laquelle !

(hum.. je suis crédible là ?)

nickel alors :)

Juste une question que je me suis posé en lisant la dépêche sur les entity système.
Pourquoi ne pas juste les ranger les composants dans des listes et les faire réferencer par les entités ?
Comme ça, pour processer un type de composant, tu attaques directement la liste sans te soucier de quelle entité est connectée dessus (ça rejoins un peu l'idée du scene graph en fait), et tu n'as pas besoin de faire une lourde requete sur des associations entre entités et composants !

Pour le coup de battre un bon driver, détrompe toi ! quand on sait ce que l'on fait, on est toujours meilleur que les optimisations générales d'un sous sytème.
L'exemple simple est de ne pas faire une opération quand elle est déjà faite ou inutile car tu n'en auras plus besoin (genre appeler sort sur un tableau que tu sais déjà trié). Ça, aucun sous système ne peut le décider à ta place, et tu gagnes un facteur temps infini ;)