Discussion :

[maeiky]

@Neckara : J'ai un peu de mal à voir les avantages de ton moteur Last Engine, si j'ai bien compris tu veux forcer l'utilisation de DLL pour les développeurs, donc chacun fait ses DLL de son coté puis ont essai de merger tout ça plus facilement avec ce moteur.

-Le principal inconvénient de cette manière de faire, est la portabilité, si tu veux par exemple compiler sur Android tu fais comment? Il te faut une version différente pour chaque OS de tes .dll, .elf .so, etc. Compilation 32bit/64bit. Alors qu'il est tout simple d'écrire un code universelle. J'imagine déjà de centaines de petit DLL pour un seul projet, et si tu veux une version sur un système différent, il te faudra que chacun des devs compile une version spécialement pour ça.

-Plein de problème de version peu survenir, quelqu'un sort une nouvelle version et tout plante, il est impossible de modifier le code directement, de visionné le code et faire des testes pour détecter le problème ou bien faire une petite patch rapidement et de proposé la solution au dev.

-Impossible de compiler avec un compilateur différent, profité de nouvelles optimisations sur Clang par exemple, ou bien de nouvelles version plus performante.

-Adieu compilation conditionnel! La grande force du C++ vient de disparaitre avec toute ses optimisation possible à la précompilation, avec impossibilité d'avoir de multiples versions d'un programme, si on veut par exemple une version debug et une version release.

-Impossibilité de faire de petit programme léger, normalement on peut compiler uniquement les fichiers nécessaire d'une lib sans la compiler au complet, une dll nous oblige d'avoir le code entier inutilement.

-Éviter d'avoir à recompiler les libs? Normalement on ne recompile pas tout à chaque fois, de plus rien n’empêche à un IDE de recompiler par section.

Il y a tout de même un réel avantage à cette façon de faire, c'est parfait pour les licences LGPL et même qu'on peut rende le code totalement inaccessible, parfait pour ceux qui on peur de se faire piquer leur code.

[Neckara]

-Le principal inconvénient de cette manière de faire, est la portabilité, si tu veux par exemple compiler sur Android tu fais comment?

Android est dérivé de Linux, il a apparemment aussi dlopen et compagnie.
Je ne vois pas où est le problème.

Il te faut une version différente pour chaque OS de tes .dll, .elf .so, etc. Compilation 32bit/64bit. Alors qu'il est tout simple d'écrire un code universelle. J'imagine déjà de centaines de petit DLL pour un seul projet, et si tu veux une version sur un système différent, il te faudra que chacun des devs compile une version spécialement pour ça.

Je ne vois pas ce que cela change par rapport à un exécutable, c'est exactement le même problème.
D'ailleurs, je ne vois pas ce qui te pose problème, c'est comme utiliser des bibliothèques dynamique pourtant cela ne te gêne pas, non ?

-Plein de problème de version peu survenir, quelqu'un sort une nouvelle version et tout plante, il est impossible de modifier le code directement, de visionné le code et faire des testes pour détecter le problème ou bien faire une petite patch rapidement et de proposé la solution au dev.

Les versions sont versionnée.
Rien n'empêche aussi de distribuer le code si on le souhaite.

De plus, c'est plus un problème closed vs open source, c'est au choix de son auteur et je respecte cela. Je pense donc qu'on est HS ici.
Je rappelle aussi que je distribuerais des fichiers pour des tests unitaires.

-Impossible de compiler avec un compilateur différent, profité de nouvelles optimisations sur Clang par exemple, ou bien de nouvelles version plus performante.

Pour la distribution, il n'y a pas de problèmes pour changer de compilateur entre deux versions.
Mais rien n'empêche la recompilation de l'ensemble du projet pour un utilisateur averti.

De plus, n'est-ce pas la même problématique pour les bibliothèques C++ ?

-Adieu compilation conditionnel! La grande force du C++ vient de disparaitre avec toute ses optimisation possible à la précompilation, avec impossibilité d'avoir de multiples versions d'un programme, si on veut par exemple une version debug et une version release.

Pourquoi ne pourrait-on pas avoir plusieurs versions du programme ?

Après oui, je vais sauter quelques optimisations, mais il n'y a pas de quoi se donner des boutons verts :

• optimisation prématurée, c'est le mal ;
• ce sera toujours plus rapide que du Lua et pourtant on peut faire de jolis jeux en Lua.

-Impossibilité de faire de petit programme léger

Si on veut vraiment un programme léger, on peut tout compiler statiquement et changer le module manager, rien n'est impossible.

normalement on peut compiler uniquement les fichiers nécessaire d'une lib sans la compiler au complet, une dll nous oblige d'avoir le code entier inutilement.

Et ?

Je ne vois toujours pas le problème. Si tu n'utilise pas une fonction, qui te dis que plus tard tu ne l'utiliseras pas ou qu'on autre ne l'utilisera pas ?

-Éviter d'avoir à recompiler les libs? Normalement on ne recompile pas tout à chaque fois, de plus rien n’empêche à un IDE de recompiler par section.

Mais tu seras forcé de faire une édition de lien.

Déjà que pour Mme Michu, copier un fichier dans un répertoire peut s'avérer difficile, alors si en plus on lui dit :
Et bien maintenant, va falloir faire une édition des liens. Pas super pour distribuer son module…



Je pense que tu te poses des problèmes pour rien ^^
Au final, c'est comme avoir une édition de lien dynamique avec une bibliothèque.
Peut-être préfères-tu les éditions de liens statiques dans tes projets, mais c'est un autre débat.


Pour les avantages :

• modularité (remplacement/ajout/(dés)activation) d'un module très simple pour un utilisateur ;
• on force la réduction du couplage et on renforce la cohésion d'un module, on se force à faire du code propre ;
• création ou modification d'un module très facile ;
• on peut créer aussi des plugins très facilement (module spécial).
• pour la portabilité, on peut facilement changer de bibliothèques si non-supportée grâce à la modularité.

[maeiky]

Je ne dis pas que ton projet n’a pas d’utilité, au contraire pour faire des plugins ça peu être très pratique et je dirais même que pour toute dll, il serait mieux d’utilisé ton système. Sauf c’est à faire attention, tout n’est pas que plugin.

On a rarement plus de 3 dll dans un projet, ces dll sont souvent un moteur graphique, un moteur audio, réseau. Le problème, la plupart du temps, c’est que ces projets deviennent tellement gros, codé dans tout les sens et ont tellement de dépendance qu’il devient presque impossible, mis à part l’auteur de compiler le tout. Donc un dll est générer, mais ce n’est pas la meilleure philosophie de tout faire en dll, je considère ça comme un workaroud, c’est plus quelque chose à éviter.

Un algorithme reste un algorithme, tu peux inclure du code et le compiler sur n’importe quel plateforme, que ça sois 32bit, 64bit ou même 8bit. Si tu inclues des dll précompiler il te faut avoir chaque version disponible de chacune des dll pour la plateforme cible, Android en est qu’une parmi tant d’autre.
Est-ce que chacun des développeurs pour chacun de ses modules vont prendre la peine d’exporter pour chacune des plateformes existante avec en option différent compilateur et différentes releases (debug ou autre)?

Jusqu’où veux-tu utilisé la modulation en dll?

Donc, je me demande en quoi ton projet se considère comme un moteur? Ça ressemble plus à un « utilitaire », pour chargé des dll?

Je ne vois pas ce que cela change par rapport à un exécutable, c'est exactement le même problème.

C'est tout le contraire, le même code source peut être compiler vers plusieurs exécutable sur différente plateforme, pas les dll.

D'ailleurs, je ne vois pas ce qui te pose problème, c'est comme utiliser des bibliothèques dynamique pourtant cela ne te gêne pas, non ?

Justement c'est le principal problème de portabilité des bibliothèques.

Rien n'empêche aussi de distribuer le code si on le souhaite.

Il est mieux d'avoir le code source accessible en tout temps pour pouvoir en comprendre le fonctionnement, déboguer et de pouvoir faire des modifications rapidement.

Mais rien n'empêche la recompilation de l'ensemble du projet pour un utilisateur averti.

Pourquoi ne pas faire ça dès le début?

optimisation prématurée, c'est le mal

Pour un algorithme peut-être, pas pour la compilation qui ne change rien au code.

De plus, n'est-ce pas la même problématique pour les bibliothèques C++ ?

Exactement, si tu fais chaque petite module en une nouvelle dll, ça ne fait qu'empirer les choses.

Mais tu seras forcé de faire une édition de lien.

Déjà que pour Mme Michu, copier un fichier dans un répertoire peut s'avérer difficile, alors si en plus on lui dit :
Et bien maintenant, va falloir faire une édition des liens. Pas super pour distribuer son module…

Tout dépend de comment tu conçois ta bibliothèque, qu'est-ce que l'édition de liens pour toi? Même pour une dll tu as des liens à configurer, les .h à cibler. C,est la même chose. Par contre certain IDE nous oblige à inclure chaque .cpp au projet, mais rien n’empêche de faire un .cpp qui inclue tout les autres donc un seul fichier à importer.
Il y a des bibliothèques comme CImg qui se résume à un seul fichier à importer.

pour la portabilité, on peut facilement changer de bibliothèques si non-supportée grâce à la modularité.

Il est très rare d'avoir 2 bibliothèques assez semblable pour ça, sinon la même chose est possible avec un petit #ifdef

[Neckara]

Tu confonds la distribution pour un développeur et un utilisateur.

Pour un développeur, on lui passe les sources et il compile lui-même.
Pour un utilisateur lamdba, il ne sait pas compiler et on est obligé de lui donner une version compilée. Mais rien n'empêche de lui donner les sources dans un dossier.
Comme je l'ai dit, c'est un débat closed/open sources, qui est indépendant de mon système de module.


Exécutables et dll, c'est la même problématique : tu peux compiler leurs sources pour n'importe quelle plateforme, mais tu ne peux pas utiliser leurs binaires sur n'importes quelle plateforme. C'est pour cela qu'on a généralement une personne qui compile tout pour des plateformes données et qui laisse les sources pour pouvoir compiler vers d'autres plateformes.
Après, c'est une problématique de distribution, qui compile ?

• le distributeur ?
• le dev du module qui doit s'adapter au compilateur pour sortir des release ?
• le dev du moteur ?
• un service en ligne pour compiler à la demande des versions officielles ?

Ceci est encore indépendant du système de plugin car pour les exécutables utilisant des bibliothèques dynamiques, c'est pareil.
De même pour les problématiques 32/64 bits ou les options du compilateur.


Tu parles de dll, donc je suppose que tu es souvent sous Windows, je peux donc comprendre ton aversion pour les dll.
La gestion sous Windows étant très crade, sous Linux, on a aucun problèmes.


Pour moi tout est module. Pour le moment, je n'ai qu'un système de module, mais petit à petit je vais ajouter des modules encapsulant des bibliothèques (2D, 3D, …).
Pas besoin d'édition des liens, pas besoin de ifdef, on peut changer les modules "à chaud".

Tout le monde peut ajouter, retirer, désactiver un module, même Mme Michu. C'est juste un fichier à déplacer.


Après, oui, on perd des performances, mais ce n'est pas énorme.
On peut choisir de mettre plusieurs modules dans un seul fichier si on le souhaite.

[maeiky]

Exécutables et dll, c'est la même problématique : tu peux compiler leurs sources pour n'importe quelle plateforme, mais tu ne peux pas utiliser leurs binaires sur n'importes quelle plateforme.

Tu confonds la distribution pour un développeur et un utilisateur.

C'est plutôt toi qui confond, il y a deux type d'utilisateur, ceux qui vont utiliser le moteur afin de créer un exécutable, et ceux qui vont simplement utilisé l’exécutable (Ces utilisateurs se moquent un peu s'il y a du linkage dynamique).
Les utilisateur qui nous intéresse sont ceux vont utiliser le moteur et pour eux le linkage dynamique change tout.

Après, c'est une problématique de distribution, qui compile ?

le distributeur ?
le dev du module qui doit s'adapter au compilateur pour sortir des release ?
le dev du moteur ?
un service en ligne pour compiler à la demande des versions officielles ?

Idéalement l'utilisateur des sources/modules, pour les raisons cités précédemment.

J'ai l'impression que pour toi un module = bibliothèque dynamique
Donc tu force les devs de module à précompiler des versions qui ne sont pas nécessairement les plateforme cible des utilisateurs de ceux-ci.

Alors que si tu distribue simplement du code, la plateforme cible est universelle. Donc dans le meilleurs des monde, un module = des fichiers .cpp/.h

Ceci est encore indépendant du système de plugin car pour les exécutables utilisant des bibliothèques dynamiques, c'est pareil.
De même pour les problématiques 32/64 bits ou les options du compilateur.

Non, ceci nécessite une bibliothèques dynamique précompiler différente pour chaque cible.

Tout le monde peut ajouter, retirer, désactiver un module, même Mme Michu. C'est juste un fichier à déplacer.

Même chose avec du code, probablement un define à changer

Pour moi tout est module. Pour le moment, je n'ai qu'un système de module, mais petit à petit je vais ajouter des modules encapsulant des bibliothèques (2D, 3D, …).

Tu veux insérer des bibliothèques à a fois 2D et 3D ... ? Normalement une seule de ces bibliothèques suffit, pourquoi en mettre plusieurs qui seront probablement incompatible?

Exécutables et dll, c'est la même problématique : tu peux compiler leurs sources pour n'importe quelle plateforme, mais tu ne peux pas utiliser leurs binaires sur n'importes quelle plateforme. C'est pour cela qu'on a généralement une personne qui compile tout pour des plateformes données et qui laisse les sources pour pouvoir compiler vers d'autres plateformes.

Retour à la case départ, donc ont doit se taper la compilation de chacun des petits modules indépendants (si on a les sources) pour changer la plateforme cible? Pourquoi ne pas directement publier le code alors?

Tu parles de dll, donc je suppose que tu es souvent sous Windows, je peux donc comprendre ton aversion pour les dll.
La gestion sous Windows étant très crade, sous Linux, on a aucun problèmes.

Ça ne change rien à la problématique et puis ton "moteur" ne sera que pour Linux?

Pas besoin d'édition des liens, pas besoin de ifdef, on peut changer les modules "à chaud".

C'est quoi pour toi l'édition de liens? Si la bibliothèques en question est bien construite, il n'est pas plus difficile de l'inclure avec ses sources, que d'importer un dll/so. Par contre je t’accorde que pour la plupart ce n'est pas le cas et que l'on a droit, pour ceux-ci, à un jolie dll/so.

Bon, tu fais ce que tu veux, je veux juste te mettre en garde des désavantages.

[Neckara]

C'est plutôt toi qui confond, il y a deux type d'utilisateur, ceux qui vont utiliser le moteur afin de créer un exécutable

Pas vraiment, ce qu'ils vont créer, c'est un .so/.dll dans un dossier /games.
Je l'ai dit, tout est module.

Ainsi si un utilisateur a plusieurs jeux, il n'a pas 20 fois les mêmes modules.

Idéalement l'utilisateur des sources/modules, pour les raisons cités précédemment.

Pour le dev, il n'y a pas de problèmes, mais pour l'utilisateur final ?
S'il doit compiler, il faut que je lui intègre un g++ et un cmake dans l'archive. Ce serait très intéressant pour les mises à jours, mais je ne sais pas si cela risque d'être trop lourd .

J'ai l'impression que pour toi un module = bibliothèque dynamique

Oui, on peut voir comme cela.

Donc tu force les devs de module à précompiler des versions qui ne sont pas nécessairement les plateforme cible des utilisateurs de ceux-ci.

Non.
Dans l'idéal, il faudrait 3 versions (Linux, Mac, Windows), mais il peut compiler pour la(les) plateformes qu'il souhaite.

Alors que si tu distribue simplement du code, la plateforme cible est universelle. Donc dans le meilleurs des monde, un module = des fichiers .cpp/.h

Pour la nième fois, je n'empêche pas la distribution du code.

Non, ceci nécessite une bibliothèques dynamique précompiler différente pour chaque cible.

Oui, tout comme pour l'exécutable.

Même chose avec du code, probablement un define à changer

NON
Tu peux changer un module sans rien recompiler.

Tu veux insérer des bibliothèques à a fois 2D et 3D ... ? Normalement une seule de ces bibliothèques suffit, pourquoi en mettre plusieurs qui seront probablement incompatible?

Je me vois mal gérer de la 2D avec Irrlicht ou de la GUI avec la SFML .
Pour la compatibilité, je n'ai aucuns problèmes, je passe par des contextes openGL.

Retour à la case départ, donc ont doit se taper la compilation de chacun des petits modules indépendants (si on a les sources) pour changer la plateforme cible? Pourquoi ne pas directement publier le code alors?

Mais qu'est-ce qui te dis que nous publions pas le code ???

ton "moteur" ne sera que pour Linux?

Non, c'est juste que pour montrer que lorsqu'on a un environnement cohérent, on a aucun problèmes.

C'est quoi pour toi l'édition de liens?

Il n'y a pas 36 000 éditions des liens.
L'éditions des liens, c'est lorsque tu as tous tes .o, .a, .dll et que tu les lies pour créer ton exécutable.

Si la bibliothèques en question est bien construite, il n'est pas plus difficile de l'inclure avec ses sources, que d'importer un dll/so.

Mais si on inclut un .so, il va falloir le compiler. Ce que l'utilisateur final, encore une fois, ne sait pas faire.

Bon, tu fais ce que tu veux, je veux juste te mettre en garde des désavantages.

Je pense qu'il vaut mieux que tu attendes la version 0.2 où je vais écrire des tutoriels sur les modules, je pense que tu y verras un peu plus clair.

Là, tu ne parles pas des problèmes du système de module, mais de la distribution des binaires, c'est autre chose.
Pour cela, j'ai plusieurs choix :

• créer un service de compilation en ligne ;
• récupérer les sources et les compiler moi même pour des versions officielles ;
• donner les spécifications et laisser les devs s'adapter pour être compatibles ;
• ajouter un cmake + g++ dans l'archive ;
• désigner des personnes pour faire office de distributeurs.

Chacune de ces solutions sont viables, mais je n'en suis pas encore là.
Cela viendra très certainement avec les modules de màj.

[Invité]

Oui, documente ton moteur s'il te plait car, là, je ne vois pas du tout en quoi ça peut servir, et j'ai l'impression que tu te perds dans tes idées et que tu ne sais plus très bien ou aller comme je te l'ai déjà dit.
C'est bien d'avoir des idées mais encore faut t'il pouvoir les exploiter et finir ses projets.

Si tu fais une interface commune pour tout les modules et que tu décides d'instancier une instance de cette interface qui importe un .dll d'un module SFML, et que après tu veux changer en instanciant une instance qui importe la .dll de SDL, tu va devoir de toute façon recompiler!

Il n'y a pas de magie!

Bref, un bête #define fera exactement la même chose!

Et puis bonne chance pour mélanger des librairies qui sont incompatible entre elle, le système de signaux et de slots de Qt, n'est pas du tout le même que le celui de boost par exemple, bonne chance pour faire une interface commune pour ses différents libs.

Au niveau du graphisme je pense que les incompatibilités sont moindre car, on peut très bien choisir de créer un contexte opengl dans lequel on dessinera tout avec des interfaces qui utiliseront des fonctions d'opengl. (ou bien direct X ?)

C'est la seule bonne idée que j'ai pu tiré des tiennes. (Avec les tests unitaires sans doute)

Bref, je vais m'arrêter là, la flemme de toujours répéter 36 000 fois le même pendant que toi ou bien tes camarades continuent à me "moinser".

[Neckara]

tu va devoir de toute façon recompiler!

Il n'y a pas de magie!

Écoute, je sais quand même ce que je fais.
Si je te dis que je n'ai pas besoin de recompiler, c'est que je n'ai pas besoin de recompiler.


On est ici sur un sujet de présentation, je ne peux pas vous expliquer tout son fonctionnement de A à Z ici.
Non seulement, je finirais par achever Vetea et Dabou en les traumatisant à vie du forum projets, mais en plus, cela prendrait plusieurs paragraphes.
Il faudrait que j'organise le tout, que j'ajoute des images ou des schémas avec des exemples de code. Cela me prendrait un temps fou et j'ai d'autres priorités.


Cependant, j'essaye de répondre du mieux que je peux aux questions qui me sont posées, j'ai même avancé la sortie de la release pour pouvoir vous fournir une documentation bien structurée au plus tôt. Alors oui, les explications ne sont pas toujours très claires, j'en suis bien conscient.
Mais ne dites pas que "je me perds dans mes idées" ou que "je ne sais plus très bien où aller".

Déjà, ce ne sont pas que des idées, j'ai du concret. Le système de module, cela fait des mois que j'ai des preuves de concepts, les tests unitaires, c'est fini.
Mais on ne distribue pas cela en claquant des doigts, il faut du temps pour faire du refactoring, pour écrire une documentation, etc…
De plus, je n'ai aucun screen à montrer, c'est tout en console. Rien de vraiment passionnant en somme.

Oui, mes débuts ont été un peu cafouilleux, oui je n'avance pas très vite, oui je n'avais pas prévu de faire les tests unitaires au tout début.
Mais on a tous débuté quelque part, et ce sont ces cafouillages qui m'ont donnés mon expérience.
Après, j'ai aussi des cours, donc je ne peux pas coder autant que je le souhaiterais, c'est d'ailleurs un miracle que j'arrive à me trouver autant de temps pour coder.
Bon, ça n'a pas été trop dur, je me contente juste de dormir un peu moins .

Pour les tests unitaires, c'est justement parce que je sais où je vais que j'ai décider de faire un détours. Seul un fou continuerait à escalader la montagne après qu'on lui ai dit qu'il a oublié sa corde.
Je n'ai pas la prétention de tout savoir sur tout, loin de là. Dès le départ, j'avais un besoin de tests. Tests que je voulais dans un premier temps intégrer directement au interfaces des modules avec des systèmes de define, mais ce n'était pas vraiment viable. Comme je ne trouvais pas de solutions, j'ai décidé de passer outre.
Mais lorsque j'ai pu trouver une solution, et bien j'ai décide de l'exploiter.

Alors oui, cela prend du temps et retarde le projet. Mais ceci ne fait que le rendre plus riche et original et me permettra même de gagner du temps dans le futur.
Vous trouvez peut-être que cela était inutile ? Je m'en contre-fiche. Je m'éclate et c'est tout ce qui compte.
Je n'arriverais jamais à sortir mon moteur au rythme auquel j'avance ? Et alors ? Est-ce pour autant une perte de temps ? Les émotions que j'ai éprouvés en le codant, l'expérience que j'ai acquis, … tout ceci n'est pas une perte de temps au contraire.
Si vous voulez que j'avance plus vite, montez votre boîte et proposez-moi un stage de 6 mois sur ce sujet.
Personne n'utilisera mon moteur ? Qu'est-ce que j'en ai à faire ? Je l'utiliserais, c'est déjà ça le plus important.


Je parie que je peux descendre une bonne partie des projets présentés ici, je parie que le code est parfois dégueulasse, peu évolutif, peu maintenable, peu lisible ou pas documenté. En creusant bien, je serais toujours capable de trouver quelque chose à critiquer ou à redire (merci à mes gènes de contrariant).
Pourquoi je ne le fais pas ? Parce que j'en ai rien à faire.
Certains ont fait le choix d'avancer, au détriment parfois de la qualité du code, c'est leur choix. Certains ont aussi peu d'expériences et ont sûrement des codes que je trouverais, personnellement, dégueulasse (si en plus c'est écrit en Java alors c'est le pompon) et pourtant ils ont des projets qui sont parfois géniaux. On ne peut pas juger la qualité de leurs projets à la qualité de leur code, au final, on se moque de leur code, ce qui compte avant tout c'est leur jeux.
Moi j'ai fais un autre choix, j'attache une grande importance à la qualité de mon code, et j'avance moins vite. Qui a raison ? Qui a tord ? Cette question ne se pose même pas, nous avons chacun nos propres objectifs.

Pour certains, l'objectif est juste de créer un jeu fonctionnel, pour d'autre d'apprendre un nouveau langage, d'autre juste de se détendre, etc.
Moi, c'est de m'éclater, d'apprendre, de réfléchir à me taper la tête contre les murs, d'acquérir de l'expérience, et je fais ce qu'il me plaît.

Bon ok, cela ne m'empêche pas de vanner EODE.

Bref, un bête #define fera exactement la même chose!

Je pense avoir été assez clair là dessus, NON !
Je n'ai pas envie de me fatiguer à revenir dessus, d'autant plus que je t'ai déjà fait pas mal d'explications. Si je n'ai pas été assez clair, vous attendrez la documentation.

@maeiky : ce n'est pas contre toi
Notre échange était plutôt intéressant, mais je pense qu'il faudrait que je finisse ma doc avant que l'on puisse en parler en étant sûr de se comprendre.

[Invité]

Ok, je te conseillerai plutôt de finir ta doc alors, moi ça m'a à peine pris une semaine pour faire la mienne. (Sans rien à côté bien évidemment)

Mais il me semble que ça fait déjà depuis plusieurs mois que je t'ai demandé de la faire. (Juste histoire qu'on se comprenne mieux et que tu arrêtes un peu de nous assommer. (moi, vetea et dadou)

Et personnellement il faudra que tu m'expliques un jour pourquoi tu es parti sur un algorithme de tests unitaires, pour le moment tout ce que je vois ce sont des bouts de code postés à l'arrache sur le forum mais je ne suis même pas sûr que il y en ai un qui tourne.

Avais tu vraiment besoin de tests unitaires pour implémenter ton système de module ?

Finalement, que veux tu, coder dans ton coin pour le fun ou bien unifier nos deux projet ?

Encore faudrait t'il déjà que j'ai autre chose qu'un simple code source sur git-hub sans documentation, pour pouvoir instancier mes interfaces avec ton moteurs pour les tests mais en attendant je continue à faire des jeux avec mon moteur pour éviter d'aller trop vite à faire des interfaces non testée et au risque que ça ne fonctionne pas. (Je déteste écrire tout le code d'une coup et puis tester, je préfère tester au fur et à mesure en même temps ça me permet de voir si les développeurs avec qui je travaille sont sérieux ou pas)

Bref, je vois que je commence à t'irriter donc sur ce, je m'en vais. ^^

[Neckara]

Mais il me semble que ça fait déjà depuis plusieurs mois que je t'ai demandé de la faire.

J'ai des cours, je n'ai pas autant de temps que je le souhaiterais.
Là j'ai développé les tests unitaires en quelques jours en travaillant dessus la nuit, sur mon temps de sommeil en sommes.

Et personnellement il faudra que tu m'expliques un jour pourquoi tu es parti sur un algorithme de tests unitaires

Avais tu vraiment besoin de tests unitaires pour implémenter ton système de module ?

On se met d'accord sur une interface :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
class StringVector
{
     const std::string & operator[] ( std::size_t i) const;
     std::string & operator[] ( std::size_t i);
 
     std::size_t size(void) const;
};

Que doit faire ce code : sv[ sv.size() + 5 ]; ?

• lancer une exception ?
  
  • si oui, quelle exception ?
  
  
• retourner un std::string vide ?
• planter ?
• déclencher un assert ?
• augmenter la taille de sv ?

Il va donc nous falloir, en plus de l'interface, spécifier son comportement.
C'est assez long à faire en français et plus simple/explicite/universel de le faire via des tests unitaires.

Ensuite, pendant que tu développes, tu peux avoir des doutes, les tests unitaires seront là pour te guider.
Et enfin, une fois le module terminé, il va falloir le vérifier pour s'assurer qu'il correspond bien aux spécifications, la encore les tests unitaires seront très utiles.

, pour le moment tout ce que je vois ce sont des bouts de code postés à l'arrache sur le forum mais je ne suis même pas sûr que il y en ai un qui tourne.

Que je poste ou non du code, sans documentation, cela ne servirait à rien.
Et je ne peux pas commencer de documentation avant d'être sûr que mon système est stable.

[skeud]

Bonjour,

Pour avoir bosser sur un système modulaire en entreprise, je suis entièrement d'accord avec neckara.
Le principe d'un programme chargeant des modules est le suivant:
Un programme maitre, qui possède l'interface du module (l'utilisateur ne peut donc changer l'interface).
Cette interface doit contenir (en général):
Une méthode d'initialisation.
Une méthode d'entrée.
Une méthode de sortie.

Et grace à ce système, peut importe la dll (ou le .so) qu'il y a derrière, le programme de base ne sera pas à recompiler afin de rajouter le module.
L'utilisateur (le codeur utilisant le programme) devra en revanche compiler sa librairie (module) de manière à respecter l'interface en héritant de celle-ci.

C'est aussi le principe de mod qui est utilisé dans pas mal de jeux vidéo à l'heure actuelle. Le code n'est pas distribué, seule une API est accessible à partir du module pour permettre l'échange entre le module et le programme de base.
.

Avais tu vraiment besoin de tests unitaires pour implémenter ton système de module ?

En général quand on développe un truc complexe, faisant appel à plétors de méthode, d'abstraction, d'API, ou meme un programme orienter serveur (un moteur graphique peut etre interpréter comme un serveur), on fait des tests unitaire, pour plusieurs raisons:
_ Test de non régression facile
_ Test de respect des spec
_ Test de KO limite
_ Test de performance.
_ Test d'utilisation (savoir si ce qu'on fait est pratique ou non, c'est souvent via les test unitaire que l'on se rend compte de ça).

Ensuite bien sur il faut faire les tests transverse qui vont pouvoir tester le programme dans la globalité, pour un moteur graphique, les tests transverse sont souvent des mini-jeu ou des rendu de scène qui vont permettre de mettre en évidence les problème de conception, ou de relation hiérarchique entre les classes (voir meme les problème de communication au sein des modules).

Autrement dis, sur ce genre de projet, les tests unitaire sont obligatoire. Car un tel programme ne doit jamais crashé ou tomber sur un cas d'erreur non prévu. Les tests unitaire sont justement là pour vérifier surtout la gestion des erreurs et de tout les cas possible et non nominaux.