Je suis sûr que si, par exemple tu sais que tu fais des templates quand tu en fait (quand tu utilise <>).
Étant donné que c'est quand même du C++, je pense que la présence de templates n'a rien de surprenant...
Globalement pour me donner envie de lire les 50k SLOC (Source Lines Of Code) de code que constitue ton xdhdq, il faut quelque chose qui parle un peu plus aux gens. Moi perso je ne développe pas en C++ depuis pas mal de temps, j'ai pas un grand plaisir à bouffer autant de code.
De l'autre coté c'est dommage de ne pas s'intéresser à l'existant parce que ça constitue une source d'inspiration importante.
En fait, les prémices de mon framework datent d'une vingtaine d'année. A l'époque, je voulais utiliser la STL, mais il était fortement déconseillé dans la documentation de l'utiliser en production. Du coup, j'ai développé mes propres bibliothèques. Après, j'ai regardé l'existant, mais sans aller jusqu'à regarder les détails de l'implémentation, vu que, globalement, cet existant ne m'apportait rien de plus que ce que je n'avais déjà avec mon framework...
Personnellement je n'appellerais pas xdhdq un hello world. C'est plus une vitrine. Le hello world, c'est le code minimal qui permet d'utiliser le cas nominal de ton framework. Par exemple c'est ce qui permet d'avoir une fenêtre avec un bouton dessus et quand tu clique dessus le bouton change de couleur (ou le texte change). Je présume que ça tiens en 3 fichiers C++ et 2 fichiers XML/XSL.
Là, j'avoue, j'ai fauté. Le fait est que, lorsque je démarre le développement d'une nouvelle application, je lance un script qui me met en place une application avec quelques fonctionnalités de base. Ainsi, la première page de l'application permet, soit de créer un nouveau projet, soit de sélectionner l'un de ceux prédéfinis dans le fichier de configuration, soit d'ouvrir un fichier contenant un projet. La seconde page, dont le contenu est conditionné par le choix fait à la première page, permet, soit de continuer sans backend, soit d'en sélectionner un parmi ceux prédéfinis dans le fichier de configuration (ou du projet), soit de charger directement la bibliothèque dynamique correspondant au backend, soit encore de saisir l’adresse et le port du backend auquel l'application doit se connecter. L'essentiel du code de cette application correspond en fait à la gestion des ces fonctionnalités. Les fichiers C++ et XSL correspondant aux fonctionnalités au cœur de l'application sont ceux commençant par Fields (un .h, un .cpp, et deux .xsl).
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # Re: Un peu d'aide
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : le commencement. Évalué à 0. Dernière modification le 04 juillet 2016 à 17:57.
Étant donné que c'est quand même du C++, je pense que la présence de templates n'a rien de surprenant...
En fait, les prémices de mon framework datent d'une vingtaine d'année. A l'époque, je voulais utiliser la STL, mais il était fortement déconseillé dans la documentation de l'utiliser en production. Du coup, j'ai développé mes propres bibliothèques. Après, j'ai regardé l'existant, mais sans aller jusqu'à regarder les détails de l'implémentation, vu que, globalement, cet existant ne m'apportait rien de plus que ce que je n'avais déjà avec mon framework...
Là, j'avoue, j'ai fauté. Le fait est que, lorsque je démarre le développement d'une nouvelle application, je lance un script qui me met en place une application avec quelques fonctionnalités de base. Ainsi, la première page de l'application permet, soit de créer un nouveau projet, soit de sélectionner l'un de ceux prédéfinis dans le fichier de configuration, soit d'ouvrir un fichier contenant un projet. La seconde page, dont le contenu est conditionné par le choix fait à la première page, permet, soit de continuer sans backend, soit d'en sélectionner un parmi ceux prédéfinis dans le fichier de configuration (ou du projet), soit de charger directement la bibliothèque dynamique correspondant au backend, soit encore de saisir l’adresse et le port du backend auquel l'application doit se connecter. L'essentiel du code de cette application correspond en fait à la gestion des ces fonctionnalités. Les fichiers C++ et XSL correspondant aux fonctionnalités au cœur de l'application sont ceux commençant par
Fields(un.h, un.cpp, et deux.xsl).Zelbinium: pour la génération qui crée, pas celle qui scrolle...