Pazns a écrit 72 commentaires

Pourquoi ne pas proposer un changement de palette par défaut au projet, si cela est selon vous si abominable ?

Merci de l'éclaircissement à tous les deux :-)

Merci de l'éclaircissement à tous les deux :-)

J'avais lu la définition, bien sûr.
Mais comment cela s'inscrit concrètement dans un cadre réel ?
Un poste de "devops" à part entière ? Ou est-ce plutôt une ligne de conduite pour un administrateur, voire une ligne de conduite pour tout le monde à la fois ?

Pourquoi "devops", en fait ?
Je ne connais pas ce terme.

Elle ne l'est pas moins non plus.

En passant, je trouve ça curieux de dire qu'on a refusé une liberté aux débianistes ou je ne sais quoi, alors même que j'entends régulièrement des échos sur la relative autocratie qui règne dans la tête de certains patrons de cette communauté.
Des impressions injustifiées, peut-être, je n'en sais rien, en tout cas je m'interroge sérieusement…

Je crains qu'un dysfonctionnement de clavier a malheureusement écorché le mot "CentOS" dans ce message.

Est-ce ici une manifestation de La Cathédrale et Le Bazar, en quelque sorte ?

Est-ce que systemd ne se comporterait pas sur certains aspects "contre" le chaos qui apprécie régir le monde linuxien ?

Au passage j'ai pas vu le montant de la facture que le tribuable va devoir payer pour les licences.

Dans ce thème, j'ai parfois le sentiment que ces décideurs sont tout simplement irresponsables, du point de vue collectivité.

À noter que cette version 2.0 est d'ailleurs normalement déjà disponible et fonctionne, même si à considérer comme instable. Le principal reste maintenant des bugfixes à ce que j'ai compris.
Je verrai bien ce qu'il en est.

Merci de cette réponse.
Je vais essayer de creuser un peu plus dans ces voies.

Par contre, une chose :

Comme indiqué, c'est difficile voire non-souhaitable de le faire, à partir du moment où la bibliothèque externe est assez haut niveau (comme un moteur de jeu complet). En revanche, pour des bibliothèques bas niveau (comme les moteurs physiques, ou les bibliothèques multimédias), c'est un travail d'encapsulation assez classique.

Ogre3D n'est pas un moteur de jeu !
C'est seulement un moteur de rendu 3D, certes complexe et d'une certaine lourdeur. Il est impossible de faire un jeu uniquement avec lui.
La "difficulté" à le relier à un système à entités vient du fait que par sa nature même il impose une certaine organisation des données autour du spatial et du graphique, inévitablement.

Par contre, maintenant que j'y pense, Ogre 2.0 (à venir d'ici 6 mois, je suppose ; il semble y avoir pénurie de développeurs sur le projet Ogre3D, c'est un peu triste) devrait changer la conception de certaines briques importantes, donc le SceneManager. Je ferais mieux d'y jeter un coup d'œil avant de continuer, du coup.

Quand on passe une référence, inutile de préciser (dans la documentation, p.ex.) qu'on reste propriétaire de l'objet. C'est ce que je veux dire. Les pointeurs eux, ne disent rien sur la propriété mais je parle des références.

Hm… tu veux parler du fait que, logiquement parlant, les pointeurs signalent de façon claire qu'on travaille sur un objet vivant dans une portée distante ?
Le flou peut exister dans le cas des références, pour un œil non-attentif (l'opérateur . au lieu de ->). Avec un pointeur c'est plus évident de rester attentif sur les effets de bords. Surtout avec unique_ptr / std::move j'imagine.

c'est une fonctionnalité du pointeur qui n'est pas autorisée par une référence

Ah bah, oui, puisque la référence est un objet ! En fait je ne comprends pas vraiment ce qui te chagrine avec les références sur ce plan-là. Ce n'est qu'une manière de reproduire un objet sans copie, ni affectation, ni déplacement.
Personnellement, je vois ça comme quelque chose de cosmétique, de confort. Ça revient au même qu'un pointeur déréférencé, un peu enjolivé.
Bon, j'avoue que je ne sais pas encore sur quoi me fixer, 100% pointeur ou mixte pointeurs références. Après tout les références n'apportent rien qui n'existe pas déjà, dans l'absolu.

ça sent l'UB à plein nez

Probablement. Mais bon, de toute manière, un pointeur invalide aussi respire l'UB à plein poumon, et on a assez vite plein de pointeurs invalides partout.

Byzanterie

Une façon de commencer à les résoudre est de faire, comme tu les suggères, du C with classes mais ce n'est pas forcément la plus intéressante.
Ce que je reproche à C++ est d'être un langage complètement byzantin, absolument illisible, et où il y a 36 réponses à chaque problème d'organisation

Complètement d'accord.
De toute évidence le C++ n'est pas une réussite, et ses nombreux besoins de rétrocompatibilités l'enchaînent encore plus. Trop tard pour lui, dommage.

Mais est-il vraiment à jeter pour autant ? N'est-ce pas là tout simplement le prix à payer pour avoir à la fois puissance et abstraction ?

Références et pointeurs

les références implémentent les pointeurs sans transfert de propriété

Les pointeurs purs non plus n'ont pas d'information de propriétés, non ?
Ce sont de simples adresses de mémoire.

En réalité la seule véritable différence de fonctionnalité entre un pointeur et une référence c'est que le pointeur permet de déconstruire l'objet et pas la référence.

Euh, j'ai un doute là, du coup. La condition pour faire un delete propre est d'avoir allouer sur le tas avec un new la mémoire pointée par le pointeur donné en argument de delete.

On peut parfaitement delete l'adresse d'une référence crée depuis un objet allouée sur le tas si ça nous amuse. Puisqu'au fond c'est un pointeur pur déguisé.
Ou bien peut-être que mon GCC 4.8 (en c++11) est permissif sur ce point ? J'avoue ne pas avoir lu la spéc' officielle. Trop chiant.

D'ailleurs, j'ai même le droit de delete un objet alloué sur la pile.

Référence ou pointeur ?

Un pointeur indique un emplacement mémoire. Il peut être nul (nullptr). Une référence indique un objet. Elle ne peut pas être nulle.
Certes, on peut maladroitement produire des références à partir de pointeurs invalides ou nuls, donc dans le fond ce n'est qu'un déguisement.
Néanmoins l'information est bien là. C'est un peu comme un argument de fonction qui serait un uint et pas un int.
De plus, cela permet techniquement un maniement un peu plus fin sur les lvalue, rvalue, prvalue du programme, comme avec l'opérateur && (qui n'est pas une référence de référence : quel agréable choix de symbole…) .
Un pointeur est un outil assez bourrin. Efficace mais peut-être trop direct ?

Les smart pointers ont un objectif assez différent, plutôt orienté gestion mémoire partagée. Je ne suis pas convaincu qu'on puisse les faire rentrer dans une question autour de la pertinence des références.

Liberté

Dans le fond, ce que tu reproches à C++, c'est de ne pas assez restreindre le développeur, c'est ça ?

Même si des aspects de C++ comme les exceptions ou les templates sont objectivement maladroits, dans le fond, est-ce vraiment grave ?
On peut toujours s'en passer et coder uniquement avec des codes de retour d'erreur et des pointeurs, s'en tenir à du "C Objet".

Parce qu'après tout une exception sécurisée est assez peu rentable.
Et comme on aura toujours moyen de bousiller un programme malgré des références, autant utiliser des pointeurs pour garder un programme simple. Et ce serait pertinent.

Un développeur maladroit fera toujours de la merde, même avec un langage prison.
Y aura toujours moyen de corrompre un jeu de données, outrepasser la limite d'un conteneur, faire une division par zéro… Peu importe le langage !

C++ est une drôle de connerie inutilement compliquée, mais il ne faut pas non plus lui mettre sur le dos l'éventuelle incompétence des programmeurs.

Bonjour ! Je m'adresse ici notamment à @rewind , mais évidement tout le monde est invité à m'éclairer =) .

Je m'intéresse en ce moment aux systèmes à entités, et je me heurte à plusieurs problèmes que je ne me souviens pas avoir vu évoqués dans ces articles de ce journal de bord sur Akagoria.
Il est probable que j'ai mal compris certains aspects d'un système à entités =P
Je rajoute que je conçois le système à entités moi-même, pour pouvoir mieux en comprendre les mécanismes.

En premier lieu, comment gérer la surcouche "matérielle" entre les composants de son propre système à entités et une bibliothèque externe ?

Dans mon cas, j'utilise Ogre3D, moteur de rendu 3D.
Voici un exemple :
Un SceneNode (un nœud dans l'espace) et une Entity (comportant notamment texture et mesh) sont produits à partir d'un SceneManager, d'une part.
D'autre part, on aura besoin d'effectuer une opération du type "sceneNode.attach(entity)" pour reproduire correctement les mouvements du nœud sur l'entité graphique.
On doit pouvoir également attacher des nœuds entre eux.

La relation de dépendance entre la composante spatiale et la composante graphique est nette, tout comme la dépendance entre ces deux-là est le SceneManager, et enfin celle possible entre deux nœuds.
Cependant, ça parait un peu étrange de fusionner ainsi deux composantes assez différentes dans le principe. Par exemple on aura à modifier l'animation actuelle d'une entité graphique, sans avoir à s'occuper de son nœud spatial.
On peut aussi imaginer le cas d'un objet intangible mais situé dans l'espace (une zone, par exemple) qui n'a aucune utilité d'informations graphiques ou physiques.
Est-ce que je prends le problème de travers et devrais fusionner ces deux objets ?
J'ai l'impression que rapidement je finirais par obtenir un énorme composant "OgreComponent" avec tout dedans. Après tout pourquoi pas…

Mais même ainsi je n'échappe pas au problème de l'antériorité, ou dépendance logique en d'autres mots. Comme suit :
Une boite de collision produite par la bibliothèque Bullet (moteur physique) n'a a priori pas de sens si elle est un composant d'une entité qui ne comporte pas de composant avec des coordonnées spatiales, donc qui n'existe pas de façon tangible. Ce serait comme essayer d'appliquer la gravitation à une quête.
Peut-on ignorer ce cas de figure, ou est-il raisonnable de penser qu'un composant doit être accompagner d'informations d'antériorité qui doivent être satisfaits pour permettre son existence ? Est-ce hors-sujet pour un système à entités ?
On a pourtant bien ce genre d'informations dans les systèmes, dans le prototype : la liste des composants qu'une entité doit avoir pour être traitable par ce système. Et donc également dans les composants et les entités, puisque ceux-ci sont donc typés (dans mon cas c'est un typage à l’exécution, manuel à base de std::string).

Enfin, dernier thème, toujours au sujet des composants :
J'illustrerai ce chapitre avec ma preuve de fonctionnement que voici :
J'ai 400 petits cubes sur un même plan horizontal, en un quadrillage carré. Sont appliqués deux traitements : le rendu graphique, et une oscillation verticale décrivant une onde sinusoïdale.
(Pratique pour tester la solidité du programme en augmentant fortement la quantité de cubes, par exemple.)

On sait que le traitement pour le sinus est dans un système des dizaines de fois par seconde.
Mais qui doit s'occuper de la "préparation" de ces cubes, c'est-à-dire notamment créer les objets Ogre à l'intérieur, puis placer correctement tous les cubes selon une scène pré-déterminée d'un fichier de sauvegarde ?
Qui doit s'occuper du nettoyage lorsque les composants seront déconstruits (fuite mémoire, notamment) ?
Si un composant n'est qu'une structure de donnée sans logique (dans la limite du C++), qui doit s'occuper de ce genre de traitements préparatoires et terminaux ?
Un système ? Mais qui l'appellera et quand ? A priori on ne peut pas insérer pareil système préparatoire dans le circuit de la boucle infinie de l'application.

Par extension, c'est tout le thème du "traitement ponctuel" qui est en jeu.
Mettons que deux objets qui réagissent l'un avec l'autre se rencontrent (de l'eau + du feu = de la vapeur).
Comment implémenter ce genre de traitement de façon efficace ?
Un système qui parcourt l'intégralité des objets du jeu pour effectuer un calcul de proximité, ça serait a priori très lent.
J'ai sans doute dû omettre un point important dans le thème de la communication entre éléments d'un système à entités, je suppose.

J'ai du mal à voir comment implémenter le concept de "chose à faire ponctuellement".
Comment dire à un système de modifier un composant *précis *de telle manière *une seule fois ?

Je sais que cela fait beaucoup pour un seul message, mais ces questions me tournent dans la tête depuis un moment déjà, cela devient quelque peu fatiguant =P

Cordialement.

Merci du lien :-)

Est-ce que cette conférence sera enregistrée et disponible au visionnage sur Internet ?

"La version 4.0 renforce se positionnant en offrant :"
->
"La version 4.0 renforce ce positionnement en offrant :"

Je vais tester F19 avec Gnome3 en Live Desktop pour le fun, mais je pense bien rester sur XFCE. Ou tester MATE, je ne sais pas trop.

Quelqu'un a des conseils rapides à propos de ce sujet ?

Gnome3 a vraiment fait des progrès depuis Gnome3.2 ?
MATE vaut-il le coup par rapport à un XFCE bien rodé (surtout que je m'y suis habitué, en quelques mois) ?

Surtout que pour le coup anaconda est vraiment tout neuf.

Au point qu'avec F18, j'ai eu un petit gros problème à l'installation, à partir de l'installeur DVD, sur un ordinateur portable équipé de la technologie Optimus de Nvidia-SATAN.

-> Un bug du pilote graphique par défaut, "Nouveau", avec Optimus, a empêché purement et simplement Anaconda de démarrer en mode graphique. Et le mode console texte était vraiment pauvre pour le coup. Je ne pouvais pas sélectionner proprement XFCE pour installation, ou en tout cas j'ai pas trouvé comment.
J'ai été obligé de passer par l'option d'installation déportée via VNC, ayant un second poste avec Fedora.
Oui, puisque avec le même poste sous Windows, je n'ai pas trouvé comment joindre le portable en réseau. En effet, impossible de configurer le module réseau du système minimal d'Anaconda, la CLI étant vraiment pauvre/absconse. Et je ne connais peu cette partie de Windows, je l'avoue.

BREF.
Ce fut pour ainsi dire une installation carrément catastrophique :-P
Ceci étant dit, j'ai adoré mon utilisation de F18 avec XFCE sur mon portable (et mon fixe !), c'est un bilan plutôt positif. Et comme ça j'aurai appris des trucs x)

La nouveauté c'est bien, mais des fois c'est fatiguant.

Du peu que j'ai vécu jusqu'ici, c'est pas loin d'être le cas, dans les premières semaines d'une sortie Fedora x)

Surtout que récemment, on a à la fois l'immaturité de Gnome 3 jeune (il est installé par défaut), et l'immaturité d'Anaconda (le programme d'installation) tout neuf, ce qui peut rebuté.

Et à propos de Wayland ?

On peut commencer à s'en servir sérieusement ou est-ce encore trop expérimental/instable/peu-supporté ?