Discussion :

[eva-axis]

Bonjour,

Ayant une bonen experience en C++. Je me suis lancer dans la creation d'un jeu (je vous rassure, c'est du serieu). A base de C++, Qt5 et DirectX.

Plus je m'avance dans le C++, plus il me parait bancale, avec plein de problemme et de bizarerie. Avec le temp j'ai ecris pas mal d'utilitaire pour le languege (classe de pointeur inteligent, wrapper pour les proprieter, wrapper pour les classes etc). Il m'est meme venue a l'idee de creer un precompilateur pour pouvoir ajouter des fonctionaliter en c++ (un peu comme qt).

Bien evidement tous ont quelque chose de plus que leurs analogues, je ne suis pas du genre a faire du code pour du code.

Sauf que apres pas mal de temp, je me retrouve avec un code plutot bien a moi. Avec pas mal de feature (j'essayer en gros de rendre le C++ plus C#, tous en gardant les performances).

Ma question est plutot simple, est ce que sa vaut le coup ? Je crain que ces module ne se font des miserer entre eux (les pointeur inteligent fonctionnent mal avec une classe sous singelton par exemple), et qu'au finale, sa fasse plus de mal que de bien.
J'aimerais avoir l'avis de quelqu'un ayant beaucoup d'experience en C++. Je doute que quelqu'un qui n'as jamais bosser sur de grans projet pourais bien saisire le problemme.

Amicalement.

[Klaim]

Avant tout: C++ est un des rares languages ou il te sera possible de faire ce que tu as fais, c'est a dire construire des abstractions autour de tes problemes recurents, qui sont suffisamment generiques pour tes cas d'utilisation.

Dis toi que c'est pareil pour tout le monde en C++ sur des gros projets. C++ est fait de maniere a permettre les abstractions les plus generiques possibles (avec des limites qui sautent au fur et a mesure des evolutions du language).

Ensuite, dis toi qu'avec d'autres languages, si le projet est effectivement gros, tu aurais le meme probleme, sauf si tu decides de faire du code qui n'utilise que ce qui est standard. C++, cote bibliotheque standard, ne peut pas encore lutter avec les autres languages tres utilises. C'est une des choses qui est en ligne de mire du c++17.

Bref, tout ca pour dire que ca ne devrait pas etre un souci lie au language. Si tu vois que tu utilises beaucoup de logique a la C# dans ton C++, c'est que:

1. tu ne fais pas du C++ idiomatique (par exemple je doute que tu exploites correctement RAII...);
2. peut etre que le C# est plus adapte a ta maniere de travailler ou tes projets specifiques?


En conclusion:

Dans tous les cas OUI on se retrouve toujours a ajouter des bibliotheques maisons ou pas sur les gros projets, c'est naturel, quel que soit le language.
En C++ tu as juste une bibliotheque standard moins fournie.
Par contre, si on omet la metaprogrammation en C++, si tu sens qu'il y a des regles du language lui meme (pas la bibliotheque standard) qui sont bizarre dans le C++ et que tu fais du bricolage pour le corriger, soit:

1. Tu ne comprends pas suffisamment bien le sujet en question (ce qui arrive souvent avec C++, quand on a pas l'habitude de verifier aupres du standard ou de quelqu'un qui sait le lire) - et donc tu t'y prends mal - tu ne fais pas du code idiomatique;
2. Tu as raison et c'est un problemes qui est en cours de correction (voir les prochaines versions du language) ou qui est connu pour ne pas avoir de solution dans le cadre vise par le language (comme definir une ABI standard...);
3. Tu reinventes la roue sans le savoir (meme si tu penses que c'est pas le cas);
4. Tu utilises des abstractions specifiques a un domaine ou il y a peu de bibliotheques accessibles, alors tu dois forcement t'en faire une (ce qui arrives souvent pour les gros projets innovants);

Mon conseil:

Si tu peux, mets ta bibliotheques de trucs utils du C++ quelque part de publique (sans forcement mettre une license libre, fais comme tu veux, l'idee est juste de nous permettre de voir le code) et on te diras si tu te trompes, si tu as raison, si tu reinventes la roue (le plus probable!), etc.

On peut pas dire grand chose sans que tu nous donnes des exemples concrets qui vont alors refleter a la fois le type de projet, de domaine et le type d'experience que tu as, ce qui peut changer pas mal de choses.

Par exemple j'ai un gros projet (open source, Qt) d'outil d'edition visuel, et a cote j'ai un gros projet (closed source, pas Qt) de jeu video. Dans les deux j'utilises des bibliotheques communes (notemment Boost et TBB), mais pour chacune j'ai une bibliotheque "utilite c++" qui se ressemble mais qui est legerement specifique parceque les deux projets n'ont pas les memes contraintes et le memes utilisations du tout.
Mais dans les deux j'ai ces trucs utils. Cela dis ils sont progressivement suprime parceque Boost et la bibliotheque standard fournis progressivement ce qui me manque.

Enfin, dans le cadre d'un gros projet, je le repete, c'est normal d'avoir des outils particuliers au projet. C'est pour ca qu'on fais de frameworks ou de smoteurs de jeux, mais que si tu en utilises un et bien ton code s'ecrire d'une maniere associee a ce moteur/framework.
C'est naturel.

EN REVANCHE: mefie toi de cette envie de faire comme un autre language dans ton language actuel. Ca peut souvent etre signe que tu ne comprends pas ce que tu fais, et c'est mon impression en te lisant. Mais c'est peut etre juste une meconnaissance des subtilite du C++, ce qui ne s'apprends qu'avec beaucoup de perseverance et de patience.

EDIT> Juste pour etre clair: les features que tu dis avoir ajoute pour combler ton C++ m'indique fortement que tu ne comprends pas comment il faut faire en C++ et qu'il y a de grandes chances pour que viennes du C# et que tu n'ais pas pris le temps de comprendre ce qu'est du C++ idiomatique. C'est l'impression que j'ai mais comme dis il faudrait voir le code pour etre sur.

[Flob90]

Je suis assez d'accord avec Klaim. (*)

Le langage a sa logique, et l'utilisation du langage ces idiomes. Tant que tu restes dans une utilisation "usuel" il est assez aisé de comprendre une certaine logique du langage, par contre quand tu sors de cette utilisation, là tu peux te retrouver avec une logique qui peut choquer un peu.

Et comme le dit Klaim dans on edit, ce que tu cites dans ton message comme utilitaire (pointeur intelligent en tête), me fait aussi pense que tu réinventes la roue, peut-être par connaissance trop superficielle du langage ?

(*) Le seul point sur lequel je ne suis pas d'accord c'est "si on omet la metaprogrammation en C++". Et que j'inclus boost dans l'utilisation idiomatique du C++ (d'où "l'absence" de problème, outre mesure, en méta-prog avec mpl).

[r0d]

En effet, c++ a ses limitations (comme n'importe quel langage). Mais avant d'en arriver à ce que ces limitations deviennent un réel problème, je pense qu'il faut le pousser vraiment très loin dans ses retranchements.

Enfin je sais pas, bien que j'ai travaillé sur d'énorme projets et malgré mes 10+ années d'expérience, je n'ai pas encore rencontré de problème insoluble. Parfois il faut faire une petite pirouette certes, mais il est toujours possible de le faire proprement.

Mais après je ne sais pas, je ne prétend pas non plus avoir "poussé le langage dans ses retranchements" justement. Il y a beaucoup de facettes du C++ que je ne maîtrise pas du tout.

[Klaim]

(*) Le seul point sur lequel je ne suis pas d'accord c'est "si on omet la metaprogrammation en C++". Et que j'inclus boost dans l'utilisation idiomatique du C++ (d'où "l'absence" de problème, outre mesure, en méta-prog avec mpl).

Si tu consideres l#utilisation de Boost comme idiomatique alors on est d'accord. Mais c'est une collection de bibliotheque, or je considerait les elements de language seulement. En particulier si on compare avec la meta programmation en D, le C++ a vraiment l'air d'un ancien prototype... (ce qu'il est pour D).
Note aussi le manque de reflection meme juste a genere a la compilation, mais c'est en cours de proposition a ce que j'ai compris.

Enfin je sais pas, bien que j'ai travaillé sur d'énorme projets et malgré mes 10+ années d'expérience, je n'ai pas encore rencontré de problème insoluble. Parfois il faut faire une petite pirouette certes, mais il est toujours possible de le faire proprement.

Pareil, les seuls veritables inconvenients du C++ sont finalement la lenteur du developpement (a cause de la compilation essentiellement...) et le manque de reflection statique ou de standardisation de la modularisation des bibliotheques. Les iterations sont plus lentes au moins au depart, ce qui peut etre tres tres impactant sur plein de domaine de la vie d'un projet.

Cela etant dis, le language n'est pas ou peu une barriere, mais le manque de bibliotheques standards ou a divers niveaux de genericite est bien relou. L'autre jour je me suis rendu compte qu'en terme de bibliotheques pour representer des graphs, on a le choix entre Boost.Graph, qui est bizarre parceque pense pour etre parcouru par des algorithmes au lieu d'etre base sur une notion de curseur (controle par un algorithm mais legerement different), et des bibliotheques qui font ca bien mais sont construites autour d'un seul algorithm (A*) et sont souvent sous-performantes. Pas etonnant que chaque moteur de jeux ai sa propre implementation de graphs generiques...

[Flob90]

@Klaim: Pour la réflexion, je suis d'accord que le C++ n'a rien pour

[r0d]

Il n'y a pas une lib de boost qui permet de faire de la réflexion?

[Flob90]

Si il y a une bibliothèque dans boost, et d'autre ailleurs qui permettent certains choses (castor). Je n'ai jamais vraiment eu l'occasion de les utiliser, mais je crois quand même que ça reste plus limité/contraignant que les langages qui l'offre directement.

[Klaim]

Non pas dans boost, castor il me semble ajoute effectivemetn de la reflection.

Mais le souci principal c'est qu'il faut soit passer par de l'abus de preprocesseur, soit par un programme externe (Google Protobuf, que j'utilises pas mal), soit par de la metaprog tres lourdes. Et dans tous les cas, il y a des tonnes d'infos qui ne peuvent tout simplement pas etre generees (sauf si tu les ajoutes a la main, ce qui detruit l'utilite du bordel).

Bref, c'est un domaine ou le C++ pose de serieux soucis, aussi parceque toutes les solutions sont, meme si simple, tres lourdes a mettre en place.

[eva-axis]

Merci pour les reponses.

Pas besoin d'aller dans les retranchement du c++ pour trouver des problemme. Un des plus simpliste est deja que on divises les fichier en .h et .c (heritage du C), sauf que si a la base l;idee etais bonne, des qu'on utilise des template on est obliger de fourer le code dans le .h, si on a des element static, sa va dans le .c. Alors je connais bien les raison qui on amener a sa, mais au finale, on a un code moin lisible, et 2 fois plus de fichier.

A la base j'etais dans le C++, puis j'ai connue le C#, le niveau de productiviter est grimpe en fleche. Mais je suis beaucoup plus habituer au C++ tous de meme.

Pour les SP (smart pointer), j'ai essayer de creer un systeme combinant les weak et les strong pointer, j'ai revisiter tous ce qu'il y'as dans la std, boost et qt. Comme je l'ai dit, je ne reivente pas la roue. Sa serais trop long pour en expliquer le fonctionement et se n'est pas le but du post.

Mais pour revenire au sujet tous en restant au SP. Ma question serais plutot, est ce que sa vaut le coup de les utiliser partous ou c'est possible (au regard de la productivite of course) au risque de rencontrer des problemme plus tard. Etant donner que ce n'est pas un simple feature mais plus un truck que tu rencontrera toute les 10 lignes.

[Klaim]

Merci pour les reponses.

Pas besoin d'aller dans les retranchement du c++ pour trouver des problemme. Un des plus simpliste est deja que on divises les fichier en .h et .c (heritage du C), sauf que si a la base l;idee etais bonne, des qu'on utilise des template on est obliger de fourer le code dans le .h, si on a des element static, sa va dans le .c. Alors je connais bien les raison qui on amener a sa, mais au finale, on a un code moin lisible, et 2 fois plus de fichier.

1. Le modele de compilation du C++ est un probleme oui, qui est une autre cible pour la prochaine revision majeure du C++ (c++17). Mais...

2. Je ne suis pas du tout d'accord que ca rends le code illisible, bien au contraire: ca separe les interfaces publiques des implementations.

3. Pour les template je suis a moitie d'accord: c'est vrai que ca fais plein de code dans les headers mais ca peut facilement etre organise pour rester clean. Le vrai souci c'est que techniquement il n'y a aucun moyen de ne pas avoir de code publique pour de la metaprog a-la-compilation.

4. Ca serait bien si on pouvait tout mettre dans un seul fichier mais quand meme separer interface et implementation (a la D). Les Modules vont faire ca mais visiblement ca sera imparfait parceque sinon il y aurait une incompatibilite trop violente avec le model actuel.

Bref, qu'est-ce que tu fais pour changer ca dans ton code? Ca n'a rien a voir avec ce dont tu parlais au debut...

A la base j'etais dans le C++, puis j'ai connue le C#, le niveau de productiviter est grimpe en fleche. Mais je suis beaucoup plus habituer au C++ tous de meme.

Je crois que ca corresponds a l'experience de tout le monde. C#, Java ou Python, la productivite grimpe en fleche, mais l'expressivite et les performances sont reduites (ce qui ne veut pas dire que ca n'est pas un bon compromis, evidemment). Cela dis, ce n'est pas le souci ici.

Pour les SP (smart pointer), j'ai essayer de creer un systeme combinant les weak et les strong pointer, j'ai revisiter tous ce qu'il y'as dans la std, boost et qt. Comme je l'ai dit, je ne reivente pas la roue. Sa serais trop long pour en expliquer le fonctionement et se n'est pas le but du post.

Ce que tu decris, c'est exactement std/boost::shared_ptr/weak_ptr (la version std est dispo depuis C++11, tous les compilos actuels le fournissent). Alors si, c'est justement la question que tu posais, il y a de fortes chances pour que au moins cette partie de ton boulot soit de la reinvention, pire il y a de fortes chances pour que ta versions sois a la fois moins safe et moins rapide que les versions standards.

Il va donc falloir nous expliquer (meme si c'est long) la difference entre tes SP et ceux de boost et de la bibliotheque standard, sinon ton argument ne passe pas.
Il peut y avoir des raisons precises pour faire des SP qui ne sont pas ceux du standard, mais franchement c'est des cas de niche, pas des cas comme tu sembles suggerer.

Note au passage que penser tout en pointeur en C++ est une tres mauvaise idee, ce qui peut etre le reflet de ton sentiment.

Mais pour revenire au sujet tous en restant au SP. Ma question serais plutot, est ce que sa vaut le coup de les utiliser partous ou c'est possible (au regard de la productivite of course) au risque de rencontrer des problemme plus tard. Etant donner que ce n'est pas un simple feature mais plus un truck que tu rencontrera toute les 10 lignes.

Dans tous types de projet, non. Franchement, le type de projet definis les besoins et contraintes ce qui fait qu'a part les elements standards, tu as mieux fait de composer chaque projet avec ce qui te semble necessaire pour ce projet precis.
Evite les generalizations du marteau: tous les projets ne sont pas montes avec des clous!

C'est deja tres suspicieux que tu ais eu a faire toi meme des SP (meme si ca peut etre necessaire dans des cas de niche, dont le jeu video peu ou pas faire partie, ca depends de la plateforme ciblee par le jeu je dirais). Alors a part si tu nous donnes de bonnes raisons, je pense qu'il est inutile de generaliser l'utilisation de ces outils supposes corriger du C++.

En revanche, si tu refais un jeu qui globalement pourrais commencer avec le meme type de code, ben oui reutiliser, c'est fait pour ca!

[eva-axis]

He bien pour les SP, la principale difference avec les weak/strong c'est que ce n'est pas deux SP mais un seul, qui selon le besoin, fonctionne comme l'un ou comme l'autre.
Plus precisement, il y'as deux compteur, un pour chaque type, chaque SP a une zone static (shared avec les autre pointeur vers le meme objet), Chaque SP peux etre "primary" (strong), il peux avoir acces au info et repond aussi de la durrre de vie, Il peux aussi etre "secondary" (weak) il a acces mais sa destruction n'influence pas les autres. La destruction de l'objet se fait quand le compteur des primary tombe a 0. Mais la partie shared entre les pointeur reste intacte, tanc que il reste des secondary, au cas ou ils essaye de contacter l'objet, on peux lancer un exeption, ce qui facilite le debogage.
Toute les copie par defaut, constructeur de copie et assignation sont par defaut "secondary".

De plus il est aise d'inclure un systeme de ramasse miete, pour que l'objet soit detruit a la fin du programme. (Bien evidement rien ne nous empeche de le faire ou bon nous semble).

Au final, on se casse plus la tete avec la durre de vie, les copie et les erreurs d'acces a une memoire desaloue sont plus facile a regler. L'utilisation de l'objet lui meme ne difere jamais d'un simple pointeur (sauf si on veux creer un pointeur "primary").

Bref j'ai deja travailliez avec boost et cette methode est bien moin intrusive et elegante a utiliser. Question optimisation mes pointeur sont (que) deux fois plus lourd (amortie), et tous les calcules sont compile-time.

Je ne vois pas tres bien a quelle projet ce systeme s'integre plus qu'a un autre. A pars certain cas extreme, ca me parait un outile utile pour la plupart des cas. Du moins je ne vois pas de raison de ne pas l'utiliser.

[Bousk]

Juste pour rebondir sur les smart pointer, si je vois l'intérêt qu'ils peuvent avoir, je n'adhère jamais au "tout smart".
A fortiori quand la raison évoquée est "on ne se soucie plus de la durée de vie", ou de la responsabilité de l'objet. C'est pour moi un très grave problème de conception et finalement un cache misère doré.

[eva-axis]

Et bien, il suffit de faire le bon choix.

Perso j'utilise les SP surtous pour les classe de base, le genre qui ne se creer qu'une fois et dure la plupart du temp, elles pesent une misere, ne se copie jamais. Ce genre de classe que tous ton programe utilise et que par malheur il arrive que tu copie, et/ou realloue et/ou detruit.

Il est evident que pour les classe lourdes ou largement creer sa ne marche pas. Le bon sens reste de mise hein. ^^

Edit: Et puis le ramasse miette est une fonctionalite a pars. Rien ne t'empeche de suprimer l'element quand bon te semble.

[Matthieu Brucher]

He bien pour les SP, la principale difference avec les weak/strong c'est que ce n'est pas deux SP mais un seul, qui selon le besoin, fonctionne comme l'un ou comme l'autre.
Plus precisement, il y'as deux compteur, un pour chaque type, chaque SP a une zone static (shared avec les autre pointeur vers le meme objet), Chaque SP peux etre "primary" (strong), il peux avoir acces au info et repond aussi de la durrre de vie, Il peux aussi etre "secondary" (weak) il a acces mais sa destruction n'influence pas les autres. La destruction de l'objet se fait quand le compteur des primary tombe a 0. Mais la partie shared entre les pointeur reste intacte, tanc que il reste des secondary, au cas ou ils essaye de contacter l'objet, on peux lancer un exeption, ce qui facilite le debogage.
Toute les copie par defaut, constructeur de copie et assignation sont par defaut "secondary".

Ca ressemble aux shared/weak normaux... La seule différence est que tu as la même classe pour les deux aspects.

[Klaim]

He bien pour les SP, la principale difference avec les weak/strong c'est que ce n'est pas deux SP mais un seul, qui selon le besoin, fonctionne comme l'un ou comme l'autre.
Plus precisement, il y'as deux compteur, un pour chaque type, chaque SP a une zone static (shared avec les autre pointeur vers le meme objet), Chaque SP peux etre "primary" (strong), il peux avoir acces au info et repond aussi de la durrre de vie, Il peux aussi etre "secondary" (weak) il a acces mais sa destruction n'influence pas les autres. La destruction de l'objet se fait quand le compteur des primary tombe a 0. Mais la partie shared entre les pointeur reste intacte, tanc que il reste des secondary, au cas ou ils essaye de contacter l'objet, on peux lancer un exeption, ce qui facilite le debogage.
Toute les copie par defaut, constructeur de copie et assignation sont par defaut "secondary".

Tu viens de nous decrire le fonctionnement de shared_ptr et weak_ptr sauf que tu n'as qu'un seul type ce qui est signe que c'est une tres tres tres tres mauvaise idee. Le compilateur ne t'empechera pas de faire des betises alors qu'avec shared_ptr et weak_ptr comme types separes, tu dis explicitement (au compilateur et au lecteur du code) quel genre de partage tu fais.

De plus il est aise d'inclure un systeme de ramasse miete, pour que l'objet soit detruit a la fin du programme. (Bien evidement rien ne nous empeche de le faire ou bon nous semble).

Alors, c'est la principale difference avec les pointeurs standard: tu ne desalloue pas les objets immediatement (ou sur demande). C'est effectivement le comportement d'un gc classique. C'est aussi un sacree perde de temps et d'energie en C++.

Vu que tu fais un jeu, tu as peut etre voulu tout manipuler par pointeur des objets alloues dans des pools? Dans ce cas tu n'as pas besoin de reinventer la roue, et encore moins d'un GC. Tu as besoin d'un pool et des smart pointer standard, rien de plus.

Pour moi c'est une tres mauvaise solution par rapport a ce que tu as de dispo. Mais tu as voulu copier le C# donc tu l'as voulu tu l'as eu
Il faudrait que tu revoies ton code apres avoir etudier du code plus idiomatique C++, qui utilises correctement les SP, qui utilise la stack au lieu de pointeurs etc.

Au final, on se casse plus la tete avec la durre de vie, les copie et les erreurs d'acces a une memoire desaloue sont plus facile a regler. L'utilisation de l'objet lui meme ne difere jamais d'un simple pointeur (sauf si on veux creer un pointeur "primary").

C'est pareil avec RAII et les SP standards. Sauf qu'ils sont deterministes (la destruction des objets est definie clairement) et dans ton cas non. Ce qui peut (mais c'est pas toujours visible ou un probleme) apporter pas mal de problemes de performance.

Bref j'ai deja travailliez avec boost et cette methode est bien moin intrusive et elegante a utiliser. Question optimisation mes pointeur sont (que) deux fois plus lourd (amortie), et tous les calcules sont compile-time.

Je ne vois pas en quoi les SP de boost sont plus intrusifs que ta solution. En plus tous les compilateurs actuels ont les meme SP (et plus, unique_ptr) de dispo dans la bibliotheque standard. Donc ce n'est meme pas un souci avec boost (cela dis si tu l'as utilise avant 2010 ca peut se comprendre).

Je ne vois pas tres bien a quelle projet ce systeme s'integre plus qu'a un autre. A pars certain cas extreme, ca me parait un outile utile pour la plupart des cas. Du moins je ne vois pas de raison de ne pas l'utiliser.

Bref,

1. tu as visiblement reinvente les SP standard mais en moins safe et moins performant (apapremment);
2. et en plus les desallocations ne sont pas deterministes...

C'etait pas une bonne idee de copier C#...

Mais pour resumer, admettons que demain tu commences un nouveau projet de jeu et que tu veuilles le minimum de dependences. Dans ce cas, si les seuls outils suplementaires que tu as utilise jusqu'ici sont ces SP, alors tu n'as pas besoin de reutiliser cette implementation. Il y en a de dispo dans le standard et boost, et ils font la meme chose en mieux. Ce qui devrait repondre globalement a ta question: a priori tu as peu d'utilisations qui "corrigent" le language, tu as juste besoin d'en savoir plus sur comment on fait en C++ Moderne.

Tu as un avantage par rapport a d'autres: en ayant implemente ton propre SP, tu as une idee de comment les SP standard peuvent marcher (sauf que le GC est totalement inutile...il n'y a qu'un cas ultra rare ou il est plus utile que les SP standard, cas qui n'arrive pas dans le jeu video). Donc une fois que tu auras mieu apris les idioms, tu vas aller encore plus vite a developper

[eva-axis]

Merci pour ta reponse.

Cela dis, je ne suis pas ici pour discuter de mes SP. Ca fait longtemp qu je code avec et j'ai de bonne raison de les garder.

Je comprend bien qu'il est tentant de critiquer mes competence, mais je ne veux pas lancer de polemique hors sujet.

Prenez comme axiome que je ne reinvente pas la roue.

A la base je voulais surtous savoir si il etait normale que un code creer par une equipe puissent fondamentalement etre different d'une autre (et donc difficilement aprehendable). Ce genre de problemme n'existe dans aucun autre language que je conaisse, ou du moin pas a ce point.

Et par pitier arreter de tenter de prouver que j'essaye de faire du C# en C++.

[Klaim]

Merci pour ta reponse.

Cela dis, je ne suis pas ici pour discuter de mes SP. Ca fait longtemp qu je code avec et j'ai de bonne raison de les garder.

Je comprend bien qu'il est tentant de critiquer mes competence, mais je ne veux pas lancer de polemique hors sujet.

Ce n'est pas le but, tes competences ne sont pas remises en cause (faut le vouloir pour faire des SP soit meme!) mais au dela des competences il y a quand meme la question de la generalisation d'un outil qui permets de facilement l'utiliser dans plusieurs cas.

Prenez comme axiome que je ne reinvente pas la roue.

Cet axiome est inacceptable pour repondre a ta question. Voir la suite.

A la base je voulais surtous savoir si il etait normale que un code creer par une equipe puissent fondamentalement etre different d'une autre (et donc difficilement aprehendable). Ce genre de problemme n'existe dans aucun autre language que je conaisse, ou du moin pas a ce point.

Bien sur que si.
Quand tu utilises C# ou Java ou Python, tu suis des idioms qui sont clairs parceque inscrits dans le language et lie a ce que tu fais comme type de projet.
Essaye un jour de faire une grosse appli web en C#, tu vas te retrouver a ajouter plein de bibliotheques et/ou ajouter des bouts tres utilise dans toute l'application mais qui sont idiomatique des developpement web.

C'est pareil en C++, ca depends juste du type de projet et de sa taille et des ses bibliotheques. Mais comme C++ a une bibliotheque standard plus petite que dans d'autres languages, tu te poseras juste plus de question sur les bibliotheques a ajouter.

Par contre tes exemples de rajouts pour "compenser" un manque de language demontre juste que tu ne fais pas vraiment du C++ (iodimatique, ou moderne), dans les cas precis exposes. Si tu faisais du C++ moderne et que tu avais compris comment marchent les SP de Boost ou de la SL, tu n'aurais pas eu besoin, par exemple, d'implementer tes propres SP.

Autrement dis, comme ta question tourne autour d'outils qui existent mais que tu ne savais pas, on ne peut pas repondre en prenant ton axiome.
Si on prends ton axiome alors on reviens a 1) tu ne comprends pas certains principes fondamentaux du language OU 2) tu fais quelque choses de tres tres specifique, et donc oui c'est normal.

Si tu as quelque chose de tres specifique a un domaine, c'est naturel d'en developper une bibliotheque et de la reutiliser dans divers projets lies a ce domaine. Mais jusqu'ici tu n'as donne que des exemples qui sont generaux et deja corriges.

Et par pitier arreter de tenter de prouver que j'essaye de faire du C# en C++.

On essaye pas de le prouver, c'est toi qui le demontre tout seul.

Pour le comprendre il faut comprendre les differences fondamentales entre C++ et C#, et je peux te dire que tous les programmeurs ne les comprennent pas.

Vraiment il ne faut pas le prendre mal. C'est beaucoup mieu de faire comme tu as fais que de faire du C en C++ par exemple...
Le seul souci c'est que tu aurais pu t'epargner pas mal de temps de dev si tu avais su.

[koala01]

Salut,

Mon idée de base est qu'il est, globalement, mauvais de vouloir "singer" en C# ce qui se fait en C++.

En effet, C# (comme java d'ailleurs) se base sur un héritage implicite avec un "god object" qui est nécessaire afin que tous les objets puissent être manipulés par le GC ou par la machine virtuelle qui "tourne" derrière l'application.

Cette seule approche ne va pas sans poser un certain nombre de problème ni sans être responsable de certaines restrictions propres à ces langages (comme l'interdiction de l'héritage multiple).

A partir de là, s'opère, fatalement, une espèce de "formatage" du système de pensée auquel il me semble important pour toi d'arriver à te soustraire si tu veux recommencer à développer en C++.

L'exemple des smart pointers est un symptôme intéressant de ce que je veux dire:

En C# ou en java, tu sais que tes objets sont garbage collectés, et tu t'orientes éventuellement vers un système de smart ptr "à tout faire", dans lequel tu ne sais pas déterminer si un pointeur peut être utilisé à un et un seul endroit, ou si la ressource peut être partagée.

En C++ (depuis C++11, sinon avec boost), on dispose essentiellement de deux types de pointeurs intelligents:
Les pointeurs dont la possession est unique: si un objet "prend possession" du pointeur sous jascent, l'ancien possesseur "perd la possession" de ce dernier. C'est ce qui arrive avec unique_ptr.
Les pointeurs sur des ressources partagées: dont on ne peut envisager de libérer la ressource que lorsqu'il n'y a plus un seul endroit qui utilise la ressource en question. C'est ce à quoi est destiné le couple shared_ptr weak_ptr.

Cela implique, évidemment, de savoir en permanence "qui est propriétaire" de la ressource et qui "peut l'utiliser", mais cela a, justement, l'énorme avantage de t'inciter à te poser la question

Quant à savoir si cela vaut le coup de les utiliser...

Je dirais oui, car ce sont des classes fortement RAIIsantes, qui permettent d'apporter une tolérance accrue aux exceptions, et car elles permettent, malgré tout, de déléguer bien d'avantage les tâches répétitives dues à la gestion dynamique de la mémoire, afin de les rendre totalement transparentes.

Bien sur, il faut quand même se garder un peu de latitude et garder en mémoire le fait qu'il vaudra, peut être, dans certains cas y renoncer

Pour le reste:

J'avouerai que je n'ai jamais vraiment compris l'avantage de disposer de la réflexion, sans doute parce que j'ai l'habitude de faire en sorte de savoir quel type je manipule à quel moment et que je n'ai jamais eu à travailler sur un projet sur lequel le besoin se faisait sentir.

Mais, si tu as vraiment besoin d'y recourir, je crois qu'il est bien préférable de travailler avec une bibliothèque externe, qui sera utilisée par "un grand nombre" que d'essayer de la mettre au point par toi même.

L'idée de base derrière ce point de vue est, simplement, qu'il s'agit d'un problème complexe et que plus il y aura de gens pour l'utiliser, plus il sera possible de mettre d'éventuels problèmes (dont on est d'ailleurs sur qu'il y en aura ) en évidence

Sinon, il est vrai que la bibliothèque standard est relativement pauvre comparé aux framework "de base" de langages comme C# ou java.

Il n'est donc pas vraiment surprenant de se rendre compte que tout développeur C++ dispose de sa "petite boite à outils" dans laquelle on trouvera sans doute la possibilité de travailler avec des chaines de caractères "case insensitive", un petit système de log rapide ou d'autre trucs du genre qui pourraient parfaitement être remis (correctement) au point en moins de cinq minutes, montre en main.

Pour tout le reste, il existe une grande quantité de bibliothèques connues et suffisamment utilisées que pour s'assurer que les inévitables problèmes sont repérés et résolus "le plus rapidement possible".

Ces bibliothèques sont souvent développées sur plusieurs années, par des équipes plus importantes que "par toi tout seul", et il y a donc fort à parier que tu aurais énormément de mal à atteindre le même niveau de qualité en un temps raisonnable si tu voulais les développer par toi même.

Je ne dis, évidemment, pas que c'est impossible, je dis juste que l'investissement que cela représente de le faire par toi même est sans doute fort élevé par rapport à l'avantage d'utiliser quelque chose d'existant

En conclusion, je vais peut etre faire une réponse de normand, mais, avant de décider de rajouter un élément personnel dans ta boite à outils, il faut très certainement te demander si l'investissement nécessaire à cet ajout est réellement intéressant par rapport à l'existant et au bénéfice retiré

[stbb94]

Je vais assez dans le sens de koala01 et Klaim, chercher à reproduire en C++ des concepts issus du monde managé ne me semble pas être une bonne idée. En effet, les langages managés sont extrêmement plus productifs (contre partie ils restent beaucoup plus lent même avec les meilleurs JIT et GC du monde).

Mais dire que c++ est bancale me semble dur. C'est à mon goût le plus beau, le plus puissant et le plus complet des langages.

La philosophie est incomparable, les langages managés sont en général designés dans l'idée de pouvoir exploiter au mieux le framework avec lesquels ils sont livrés et c'est génial pour beaucoup d'applications.

En revanche, C++ est plutôt brut de décoffrage sans framework d'où le besoin de se créer des utilitaires, mais la philosophie objet est franchement différente notament dûs à la puissance des templates C++ les problèmes ne doivent pas être abordés avec les mêmes techniques. De nombreux ouvrages notamment celui de Andrei Alexandrescu "modern c++ design" traite de sujets qui seraient intraitable de la sorte dans le monde managé.

Bref, la reproduction en c++ de mécanisme c# me semble contre-productif et tout du moins ne tire pas partis des concepts (bien plus nombreux) de c++.

M'enfin pour les librairies disponibles, je pense que C++ est plutôt gâté : Qt, boost, la merveilleuse ACE ... et puis C++11 moi, j'aime bien