Informatique

C++ manque cruellement de reflection qui serait utile pour implementer de la serialization. Le committee de standardization en a parle, mais ca ne sera pas dans C++20.

Pour les questions de serialization, les protocol buffer de google sont une approche, mais je ne suis pas super fan.
Perso, je prefere utiliser quelquechose comme rapidjson pour les choses qui ont besoin d'etre serialize, ca permet de choisir les attribut a serializer, des fois on a pas besoin de tout serializer.

[23:31:13] <blackapplex>

c'est le fait d'y accéder via des strings

c'est hashé donc je me suis dit que c'était pas problématique, mais..oui ça peut se tenter avec un enum. Mais si j'utilsie un const char* à la place c'est pas la même chose que l'enum ? Mais je comprends le surcoût d'avoir une string pour chaque propriété

Mon problème c'est pas le coup en performance, mais le risque d'erreur lors de l'accès aux variables.

Je comprends l'idée qui est d'avoir une compilation qui certifie l'exécution correcte, même si c'est rarement vrai quelque soit le cas d'usage.

Je sais que c'est pas possible d'avoir une compilation qui certifie à 100% l'exécution, mais pour moi c'est pas une raison de rendre le code encore plus sujet aux erreurs d'exécution que ce qu'il aurait pu être à la base. Genre c'est pas un "tout ou rien", c'est un "plus c'est sécurisé mieux c'est".

Après je donne juste mon avis sur ton code je cherche pas à le rabaisser ni rien, pour moi tu remplaces les string par des enums avec un type d'enum par type de variable et t'es sécurisé au niveau de l'accès à tes composants, que ce soit le type ou le nom du composant, tout en enlevant la redondance de devoir donner le type de la variable quand tu y accèdes, et ça me suffirait. Après côté performance je sais pas ce que ça vaudrait.

clairement ne pas utiliser de string et utiliser un enum a la place serait un peu mieux. Masi le probleme de performance profond vient de la table de hashage. Note qu'en utilisant un enum c'est vachement plus difficile de faire de la serialization. Parceque la cle devient un entier qui change quand change la definition de la classe. Donc c'est fatiguant pour les questions de versionnement de donnee.
(Note que c'est toujours complique le versionement de donnee.)

Je vais profiter de votre discussion. J'arrive à la fin de mon M2 (il me reste que le stage) et je n'ai jamais vu l'ECS en cours du coup j'ai quelques questions dessus. Après de rapide renseignement, ça a l'air très pratique et utilisé, plus flexible que de l'héritage de classes et donc je me demandais quels étaient les désavantages de ce type d’architecture par rapport à de l'héritage comportemental ? Ca me surprend qu'on l'ai pas vu en cours car ça a l'air très puissant.

J'arrive à la fin de mon M2 (il me reste que le stage) et je n'ai jamais vu l'ECS en cours

Je ne sais pas si c'est tres utiliser en dehors du jeu video. Donc c'est pas forcement etonnant que tu ne l'ai pas vu.

quels étaient les désavantages de ce type d’architecture par rapport à de l'héritage comportemental ?

Ca donne des systemes sans vrai type. Et ca peut etre une source de probleme assez fatiguante. Un exemple simple est que si une entite a un composant "Deplacable", ca suppose qu'elle a aussi un composant "Position". Et du coup le systeme de type ne peux pas assurer ca.
Tu n'as pas vraiment de relation "est un" qui soit facilement implementable au sein du systeme. Il te faut une mecanique externe pour implementer ca.
Si tu as un comportement complexe a travers de plusieurs composant pour certaines entite, c'est super chiant a ecrire parceque les comportement se retrouvent exploser dans different composant au lieu d'etre dans un objet unique.

Ok loki je voyais pas ça dans ce sens.

Techno Moi non plus je l'ai pas vu en cours, tu dis que c'est très utilisé mais en pratique moi je ne l'ai jamais vu implémenté dans des projets d'entreprise, ma conclusion était que c'était peu connu en France
Après j'ai pas non plus fait de C++ avancé en cours, ni de design pattern à un niveau très élevé (tout appris tout seul ). L'ECS ça demande un certain niveau, faut maitriser la base des design pattern, les templates, bref faut déjà avoir fait un cours de C++ et quand t'en as fais un c'est pas systématique qu'on t'en propose un deuxième en mode avancé. Moi je sais que mon école me proposait un cours de Java avancé, mais typiquement il avait été annulé parce qu'il n'y avait qu'un intervenant pour le faire et qu'il s'était désisté.

Les désavantages? Je n'ai pas beaucoup pratiqué l'ECS mais j'en vois pas. Tout comme t'as pas de désavantage à utiliser l'héritage classique et les designs habituels sur des petits projets simplistes. There is no silver bullet, plusieurs façons de faire la même chose, je pense que pour de gros projets évolutifs l'ECS est particulièrement adapté. Mais l'ECS c'est très orienté composant, en pratique on fait un compromis héritage / composant qui est peut-être plus intuitif que de tout penser en terme de composant

Un exemple simple est que si une entite a un composant "Deplacable", ca suppose qu'elle a aussi un composant "Position". Et du coup le systeme de type ne peux pas assurer ca.

Et on peut pas trouver une façon flexible de dire les composants prérequis au système? Du genre si je donne un composant "déplaçable" alors forcément le système obtient aussi, s'il n'en a pas un, un composant "position".

Tu n'as pas vraiment de relation "est un" qui soit facilement implementable au sein du systeme. Il te faut une mecanique externe pour implementer ca.

Mais si on reprend mon code. Je peux dire que VerreBleu est un Verre simplement en faisant "auto verrebleu = verre", il copiera les pointeurs vers ses fonctions et ses propriétés un peu comme un héritage.

Si tu as un comportement complexe a travers de plusieurs composant pour certaines entite, c'est super chiant a ecrire parceque les comportement se retrouvent exploser dans different composant au lieu d'etre dans un objet unique.

Ouais après ça c'est un problème de conception qui est pas spécifique à l'ECS je crois. Avec l'héritage c'est pareil t'éparpilles tes fonctions et tu te rends compte au final qu'il faut tout mettre dans un seul objet.

Un exemple simple est que si une entite a un composant "Deplacable", ca suppose qu'elle a aussi un composant "Position". Et du coup le systeme de type ne peux pas assurer ca.

Et on peut pas trouver une façon flexible de dire les composants prérequis au système? Du genre si je donne un composant "déplaçable" alors forcément le système obtient aussi, s'il n'en a pas un, un composant "position".

Ca pose quand meme les questions d'initialization. Quand tu initialise ton composant "deplacable", tu ne sais pas comment initialiser ton composant "position". Il n'y a pas de valeure par defaut inteligente pour le composant "position". Ca veut dire qu'il faut un mecanisme externe au systeme qui assure la coherence du tout.

Tu n'as pas vraiment de relation "est un" qui soit facilement implementable au sein du systeme. Il te faut une mecanique externe pour implementer ca.

Mais si on reprend mon code. Je peux dire que VerreBleu est un Verre simplement en faisant "auto verrebleu = verre", il copiera les pointeurs vers ses fonctions et ses propriétés un peu comme un héritage.

Encore une fois, ca veut dire que tu reposes sur une mecanique externe qui va assurer que quand le composant est cree, il est creer de facon coherente.

D'une certaine facon la question de l'ECS est assez similaire a comment on fait l'implementation physique d'une base de donne modeliser au format entite-relation. Il y a plein d'implementation physique, certaines qui ont plus de besoin de mecanique externe que d'autre pour assurer que les contraintes de la base sont valides..

Si tu as un comportement complexe a travers de plusieurs composant pour certaines entite, c'est super chiant a ecrire parceque les comportement se retrouvent exploser dans different composant au lieu d'etre dans un objet unique.

Ouais après ça c'est un problème de conception qui est pas spécifique à l'ECS je crois. Avec l'héritage c'est pareil t'éparpilles tes fonctions et tu te rends compte au final qu'il faut tout mettre dans un seul objet.

Ce que je veux dire c'est que dans un modele objet. Un objet qui implemente 50 interfaces differentes voit toutes les interfaces en meme temps. Alors que dans un modele ECS, un objet qui a plein de composant doit avoir un comportement coherent au travers de plein de systeme deconnecte. Donc c'est un peu plus complique.
Ce qui fait que souvent les entites complexe se retrouve a avoir un seul composant et un systeme specialise pour simplifier l'ecriture du code. Mais ca rajoute des systemes.

Mais en effet, c'est un probleme d'ingenerie qui existe dans d'autre modele de conception.

Ouais je comprends, faudrait que j'essaie l'ECS propre pour me faire une idée

https://www.reddit.com/r/ProgrammerHumor/comments/b5g3mv/true_story/

Vous pensez quoi de ça vous ? C'est quand même super basique d'inverser un arbre binaire, je connais pas les conditions dans lesquels il était donc peut-être que dans son cas c'était un peu difficile quand même (genre 5 minutes pour réfléchir au problème et écrire un code compilable sans erreur en C avec les flags -Wall -Wextra -Werror), mais bon même sans avoir jamais bossé avec des arbres binaires il faut pas plus de 10 minutes pour résoudre ça je dirais. Et je trouve pas que le fait d'avoir réalisé un logiciel populaire soit à lui seul un motif valable pour embaucher quelqu'un, l'important c'est plus la qualité du code que celle du logiciel en lui-même.

Ca ne m'etonne pas que tu trouves des ingenieurs competent qui ne savent pas inverser un arbre binaire. C'est pas super difficile, mais il faut gerer pas mal de cas bord qui peuvent etre fatiguant a ecrire.

Apres les methodes de recrutement de google sont relativement stupide. En pratique beaucoup de gens vont bosser chez google pour y etre 2 ans et apres se barrent ailleurs. Ils ont compris que avoir Google sur son CV leur assurent un poste a peu pres partout ailleurs.

Prends des problemes simples que tu n'as jamais regarde et tu vera que bien que ca ne soit pas fondamentallement difficile, a froid c'est pas evident. Meme un probleme bateau: je te donne deux rectangles, est ce que les rectangles sont disjoint? C'est pas super difficile, mais il y a moyen de se planter quand c'est au milieu d'une saison stressante d'entretien et que c'est le 4 eme probleme a la con qu'on te pose dans la journee.

Donc l'ECS permet quelque chose d'ultra-flexible mais qui demande au développeur de "réfléchir" aux interactions entre les composants qui ont une mécanique complexe ? Et il y a une raison pour que ça soit plus utilisé dans le jv qu'ailleurs ? Sur de la programmation d'interface, ça pourrait être pas mal non plus non ?

Sur de la programmation d'interface, ça pourrait être pas mal non plus non ?

Encore une fois l'ECS c'est pas toute la doctrine d'usage de la composition. Les interfaces utilisent beaucoup de composition mais n'ont pas besoin d'ECS, si tu regardes Qt ils ont un système ingénieux d'héritage et de composition: les objets héritent de QObject, si ce sont des objets à peu près physique ça hérite de QWidget avec davantage de propriétés et sinon c'est des QLayout typiquement qui font de la composition, que tu peux mettre dans des Widgets et qui peuvent contenir des widgets. Je sais pas si ça leur rapporterait de passer à l'ECS.
Tiens et en parlant de Qt, eux utilisent aussi des Variant pour leurs propriétés "génériques" : https://doc.qt.io/qt-5/properties.html

Inverser un arbre binaire? Euh...je vais surement dire une bêtise mais il suffit pas de faire un DFS et puis de retenir pour chaque noeud final le chemin fait pour y accéder ? Un ptit algo récursif M'enfin là je pourrai le dire à haute voix mais si on me demande de l'écrire en 5min j'envoie les gens balader ils iront recruter des gens qui apprennent tout par coeur si ça les amuse. En plus les exams du genre sont bourrés d'effets de seuil où pour 2min de retard ou 1 nuit où tu dors mal tu peux passer de 5/20 à 18/20, plus jamais j'en ferai

Inverser un arbre binaire? Euh...je vais surement dire une bêtise mais il suffit pas de faire un DFS et puis de retenir pour chaque noeud final le chemin fait pour y accéder ?

Bah non, tu fais juste un swap entre la branche gauche et droite d'un noeud pour chaque noeud et c'est tout. La fonction c'est juste un swap et deux appels récursifs, l'ordre d'appel a même pas d'importance, il y a 0 cas particulier à gérer hors "le nœud n'existe pas", c'est vraiment basique je trouve (ou alors j'ai pas compris un truc).

Après oui comme je disais j'ai pas connaissance des conditions dans lesquelles il a passé ce test, j'imagine qu'effectivement dans un état de stress et tout c'est plus difficile d'avoir les idées claires c'est vrai.

Attends mais inverser dans quel sens Moi je pensais qu'il fallait donner le chemin d'un noeud Tu voulais dire inverser la gauche et la droite? ...Quel intérêt ?

Bah ça inverse le chemin de tous les nœuds, par exemple au lieu d'accéder à un noeud via droite->gauche->droite ça sera gauche->droite->gauche quoi.

L'intérêt j'en sais rien, c'était la question lors de l'interview c'est tout.

L'intérêt j'en sais rien, c'était la question lors de l'interview c'est tout.

Mmm Mouais ..

Bah j'invente rien, c'est dans le tweet, tu doutes de quoi ?

Le 26 mars 2019 à 23:34:24 lokilok a écrit :
Bah j'invente rien, c'est dans le tweet, tu doutes de quoi ?

De l'intérêt, c'est pas immédiat pour moi que c'est une bonne question à poser, m'enfin..
Je suis sûr que dans 80% des cas, les gens se posent des questions pour résoudre un problème d'une certaine façon, alors qu'une autre façon plus simple aurait permis de ne pas se poser cette question. Je me demande si c'est un de ces cas là c'est tout

Je vois, mais je pense pas que ce soit pour résoudre un problème particulier, j'imagine que c'est plus pour voir si la personne interrogée sait ce qu'est un arbre binaire.

https://www.mediapart.fr/journal/france/180419/l-ecole-42-de-xavier-niel-sexe-harcelement-arnaques-et-comptes-offshore

«l’intéressé [sadirac[ se targue d’un cursus universitaire brillant, dont on ne trouve trace nulle part. En particulier, parmi de nombreuses autres questions (on les trouvera sous l’onglet Prolonger associé à cet article), nous lui avons demandé où nous pouvions trouver la confirmation du diplôme de l’université de Californie à Los Angeles (UCLA) et du master en sciences physiques de l’université de Stanford en Californie, qu’il prétend avoir obtenus ; malgré nos nombreuses relances, l’intéressé n’a jamais voulu nous répondre.»

Hmmmmmmmmmmm