Questions Avancées de C/C++

Bonjour après avoir épluché la FAQ C++ quelques questions subsistent encore dans mon esprit. Si quelqu'un possède la capacité d'y répondre, je lui en serais reconnaissant.

1) Concernant les exceptions en C++, j'ai lu et j'admets qu'il est plus facile pour un développeur de gérer les erreurs dans son programme. Cependant, j'ai aussi lu qu'un bloc "try-catch" était "lourd" à gérer et ralentissais le programme.
- Dans ce cas, peut-on considérer qu'une gestion des erreurs comme on le ferait en C (avec tout un tas de "return") serait plus optimal qu'un "trow" ?
- Ne gâche-t-on pas la puissance de C++ en n'utilisant pas les exceptions ?
- Dans quels cas serait-il favorable d'utiliser "return" ou "throw" ?

2) J'ai lu qu'on utilisait les classes abstraites pour factoriser les opérations sur une classe et les interfaces pour les définir. Cependant, a-t-on réellement besoins d'utiliser des interfaces ?
J'admets qu'il est peut-être utile d'en utiliser dans le cas où un projet devrait être repris par plusieurs développeurs et qu'il avait une grande envergure, mais je ne comprends pas ce que cela apporte de plus que de lire le ".h" d'une classe par exemple hormis le fait qu'on ne puisse en hériter sans implémenter chacune des méthodes définies.
N'est-ce pas plus lourds en terme de performance d'utiliser une classe qui hérite d'une classe abstraite héritant elle-même d'une interface plutôt qu'une classe héritant uniquement d'une classe abstraite ?

3) Après avoir développé en C++, je me suis rendu compte qu'il serait possible d'utiliser un "faux concept d'objet" en C. Par exemple créer des structures contenant des pointeurs sur fonctions en guise de méthodes et ainsi regrouper des fonctionnalités.
Cela affecte-t-il les performances ?
Cela ne va-t-il pas à l'encontre du développement en C qui se voudrait uniquement procédurale ?

4) En C++, lorsque l'on utilise du polymorphisme et que l'on désire stocker ses classes dans une seule "List".
Exemple :
- une classe "Humain".
- une classe "Soldat" héritant "d'Humain".
- une classe "Marchand" héritant "d'Humain".
On désire simplement utiliser une "List<Humain*>".
Vient alors le besoin d'extraire ces classes et de déterminer de quels types elles sont. En PHP on utiliserait "instanceof" pour cela.
En C++, j'ai trouvé plusieurs solutions :
- Utiliser "typeid"
- Utiliser un "dynamic_cast" (problèmes de performance ?)
- Stocker un id dans la classe Humain sous forme "d'enum" de manière à connaitre le type et faire appel à un "static_cast" (limite d'utilisation avec héritage multiple ?)
- Quelle est parmi ces 3 solutions, celle qui est la plus performante ?
- Existe-t-il une solution plus adaptées ?

5) Et enfin dernière question, de manière générale, un code en C++ sera-t-il forcément plus lent à exécuter qu'un code en C ?
Je serai du genre à penser qu'un bon code en C++ surpassera un mauvais code en C et vice et versa, cependant je me pose la question, lorsque l'objectif est la "performance absolue" pour le développement d'un serveur que vaut-il mieux choisir entre C++ et C (ne me répondez pas l'ASM :D) ?

Merci d'avance à ceux qui prendront le temps de lire et de répondre à ce message.

1) Il y a récemment eu sur le forum toute une discussion sur ce sujet. À chercher...

2) L'intérêt de découper les interfaces permet une plus grande granularité sur les fonctionnalités que tu choisis d'offrir.

3) À voir dans le forum C ?

4) type: pas vraiment portable
dynamic_cast : pas performant
enum : le plus perfomant
Mais il est souvent conseillé de créer, en plus de ta liste générique, une liste pour chaque type.

5) Forcément plus lent, non. Mais les fonctionnalités haut-niveau qu'apportent le C++ ont un coût (polymorphisme, par exemple).

Merci pour votre réponse. Quelques questions subsistent encore :

Citation:

---

Envoyé par oodini

1) Il y a récemment eu sur le forum toute une discussion sur ce sujet. À chercher...

---

Je suis tombé sur ce topic : http://www.developpez.net/forums/d12...e-for-warning/
Cependant, je ne vois nuls part de comparatif de performances à l'exécution.Peut-être me suis-je trompé de topic, dans ce cas j'ai du mal à le retrouver.

Citation:

---

Envoyé par oodini

2) L'intérêt de découper les interfaces permet une plus grande granularité sur les fonctionnalités que tu choisis d'offrir.

---

En d'autres terme, si je suis l'unique développeur d'un projet, que ce projet n'a aucun but d'être repris plus tard, l'utilisation d'interfaces n'est pas indispensable ? Le fait de les utiliser sera-t-il plus lent à exécuter pour le processeur que s'il n'y en avait pas ?

Citation:

---

Envoyé par oodini

4) type: pas vraiment portable
dynamic_cast : pas performant
enum : le plus perfomant
Mais il est souvent conseillé de créer, en plus de ta liste générique, une liste pour chaque type.

---

Créer une liste pour chaque type en plus de la liste générique, cela n'est-il pas redondant ? Pourriez-vous me donner un exemple ?

Bonjour Pawda et bienvenue sur le forum

1.
Pour la comparaison exception vs retour de fonction, voir cet article : Retour de fonctions ou exceptions ?. Pour les performances : Performances des exceptions C++.

2. en C++, une interface, c'est une classe abstraite particulière. Sinon, son utilisation n'est pas obligatoire et c'est une question de choix du dev

3. on peut aussi créer des vtable
Pour le pourquoi, il faut demander aux dev C

4. faire comme ça est souvent un problème de conception. Il ne s'agit pas forcement d'utiliser plusieurs listes, mais de vérifier les responsabilités des classes

5. Forcement moins performant, non. Toutes les fonctions haut niveau n'apporte pas un surcoût. Les templates permettent également d'évaluer ce qui peut l'être à la compilation, ce qui réduit le coût à l'utilisation (on peut aussi dans les autres langages, mais il faut faire le travail manuellement, on perd en productivité)


Plus généralement : poser autant de question sur une seule discussion fait que les réponses seront moins développées que de détailler chaque question
(et ce ne sont pas des questions avancées, il y a des choses beaucoup plus compliquées en C++ :aie:)

Citation:

---

Envoyé par Pawda

cependant je me pose la question, lorsque l'objectif est la "performance absolue" pour le développement d'un serveur que vaut-il mieux choisir entre C++ et C (ne me répondez pas l'ASM :D) ?

---

La performance absolue n'existe pas. Avec des ressources infinies, un programme ne C ou un autre en C++ tourneront aussi vite l'un que l'autre. La vraie question me semble plus être : Avec des ressources raisonnables, lequel des deux tournera plus vite ? Et je pense que l'avantage va au C++, à la condition qu'on dévelope sur une plateforme avec un bon compilateur.

L'exemple canonique est le tri d'un tableau (les chiffres sont bidons, c'est juste pour illustrer) :
Schématiquement, ressources infinies, on redéveloppe l'algorithme de tri, on l'optimise pour les données que l'on a, et on hard-code la comparaison des éléments deux à deux. On obtient une référence qui s'exécute en 1s, pour 1 mois de développement.
En C++, on utilise std::sort, les templates font qu'une grande partie du code est inlinée, on obtient du code qui tourne en 1,0002s, pour 1h de développement.
En C, on utilise qsort, pas d'inlining possible de la fonction de comparaison, on obtient du code qui tourne en 1,2s, pour 2h de développement (la fonction de comparaison est plus complexe à écrire et à tester avec tous ces casts).

Citation:

---

Envoyé par gbdivers

1.
Pour la comparaison exception vs retour de fonction, voir cet article : Retour de fonctions ou exceptions ?. Pour les performances : Performances des exceptions C++.

---

Merci, c'est exactement ce que je cherchais, je ne comprends pas comment ces liens ont pu m'échapper. :oops:

Citation:

---

Envoyé par gbdivers

Plus généralement : poser autant de question sur une seule discussion fait que les réponses seront moins développées que de détailler chaque question
(et ce ne sont pas des questions avancées, il y a des choses beaucoup plus compliquées en C++ :aie:)

---

Je dois avouer qu'à l'origine, ce sujet s'appeler "question générales de c++" mais faisant une attention particulière aux performances, je me suis dit que seul les utilisateurs avancés s'attardait à ces différences. Au temps pour moi, je me rends bien compte que poser autant de questions dans un topic n'est pas l'idéal, d'un autre côté, je me voyais mal inscrire mes premiers messages sur ce forum par 5 topics différents. A l'avenir je poserais mes questions au cas par cas !

Quoi qu'il en soit, merci à vous tous d'avoir répondu à mes questions !

Je voulais juste préciser, pour le 4.

De mémoire, il me semble que, en interne, dynamic_cast utilise une enum. Donc une enum n'est pas plus performant qu'un dynamic_cast, et a en plus le désavantage de limiter le nombre d'héritants.
Après, la simple utilisation de dynamic_cast me fait penser qu'il y a un problème : on a tendance à ne plus respecter l'Open-Closed Principle (OCP), puisque pour ajouter un descendant il faut modifier la classe de base pour ajouter un élément à l'enum.

Voilà mon petit grain de sel !

Citation:

---

Envoyé par gbdivers

5. Forcement moins performant, non. Toutes les fonctions haut niveau n'apporte pas un surcoût. Les templates permettent également d'évaluer ce qui peut l'être à la compilation, ce qui réduit le coût à l'utilisation (on peut aussi dans les autres langages, mais il faut faire le travail manuellement, on perd en productivité)

---

Mais cela augmente le coût à la compilation. Et quand on bosse avec de multiples branches su Git, que chaque changement de branches induit souvent de conséquentes recompilations, ça peut finir par être lourd.

Si on a plusieurs branches git, pourquoi ne pas avoir plusieurs répertoires pour stocker les .o ? Un par branche et tout roule. :)

Citation:

---

Envoyé par JolyLoic

L'exemple canonique est le tri d'un tableau (les chiffres sont bidons, c'est juste pour illustrer) :
Schématiquement, ressources infinies, on redéveloppe l'algorithme de tri, on l'optimise pour les données que l'on a, et on hard-code la comparaison des éléments deux à deux. On obtient une référence qui s'exécute en 1s, pour 1 mois de développement.
En C++, on utilise std::sort, les templates font qu'une grande partie du code est inlinée, on obtient du code qui tourne en 1,0002s, pour 1h de développement.
En C, on utilise qsort, pas d'inlining possible de la fonction de comparaison, on obtient du code qui tourne en 1,2s, pour 2h de développement (la fonction de comparaison est plus complexe à écrire et à tester avec tous ces casts).

---

Mouais... On parle de langages, ou de bibliothèques ? Et si on parle de temps de développement, on peut aussi aller vers Java, ou même Python.
Si tu fais un moteur de rendu, les algorithmes de la STL, tu ne vas pas t'en servir souvent. Et étrangement, tu vas souvent privilégier le C.

Citation:

---

Envoyé par Ekleog

Si on a plusieurs branches git, pourquoi ne pas avoir plusieurs répertoires pour stocker les .o ? Un par branche et tout roule. :)

---

C'est contre la philosophie de Git; cela double les manipulations, et si tu ne fais pas gaffe, tu peux très bien te retrouver à t'arracher les cheveux sur un log, alors que tu modifies un code correspondant à une autre branche !
Déjà qu'il faut faire gaffe de ne pas popper un stash dans la mauvaise branche...

Sauf si on configure le dossier de build dans la branche. Changer de branche entrainera automatiquement le changement de dossier de build.
Ou bien configurer le makefile (ou équivalent) pour faire l'output dans build_`git branch | sed 's/\* //'`/. (Il doit y avoir une façon plus élégante que sed)

Et puis, je ne suis pas sûr que la philosophie de git soit de tout rebuild à chaque changement de branche, hein.

Citation:

---

Envoyé par oodini

Mouais... On parle de langages, ou de bibliothèques ? Et si on parle de temps de développement, on peut aussi aller vers Java, ou même Python.
Si tu fais un moteur de rendu, les algorithmes de la STL, tu ne vas pas t'en servir souvent. Et étrangement, tu vas souvent privilégier le C.

---

En effet, je parlais bien de langage et non de bibliothèques. L'exemple cité par JolyLoic n'est pas des plus adaptés. Dans mon cas, je suppose que le temps de développement ainsi que le temps de compilation n'entre pas dans la balance, il s'agit uniquement du temps d'exécution. Au final je sais qu'il est possible de faire du C en C++ mais cela ne vaut-il pas mieux la peine de tout faire en C si on s'occupe de la moindre nanoseconde d'exécution, telle est la question. Par exemple, il y a quelques années de ça, j'avais fait un raytracer en C et je me demande si le refaire en C++ avec une conception objet serait équivalent en termes de performances ou plus lent. Si vous me dites que plus on cherche la performance (ex avec le moteur de rendu), plus le code ressemble à du C, je pense que cela répond à ma question et qu'il vaut mieux développer (les parties sensibles du moins) en C. Après, je ne sais pas si l'asm généré par g++ est équivalent à celui généré par gcc pour le même code, à tester.

Citation:

---

Envoyé par oodini

Mouais... On parle de langages, ou de bibliothèques ? Et si on parle de temps de développement, on peut aussi aller vers Java, ou même Python.

---

Je parlais de langage avant tout. Et du fait qu'avec certains langages, on peut faire des bibliothèques qui accélèrent le développement sans pour autant faire chuter les performances, alors qu'avec d'autre, ce genre de bibliothèques n'est pas réalisable, et qu'on se trouve confronté au choix de multiplier par 50 les coûts de dev ou d'accepter une baisse de performances du résultat.

Citation:

---

Envoyé par oodini

Si tu fais un moteur de rendu, les algorithmes de la STL, tu ne vas pas t'en servir souvent. Et étrangement, tu vas souvent privilégier le C.

---

Je ne vois vraiment pas pourquoi pour un tel moteur, je privilégierais le C. Et même si je ne suis pas dans le domaine des jeux, je connais un paquet de jeux faits en C++, y compris le moteur de rendu. Voir par exemple le cryengine de crytech.
Si je prends un autre exemple où les performances comptent beaucoup, et le coût de dev moins, étant données les sommes en jeu dans tous les autres aspect du sujet, les calculs qui ont permis la découverte du boson de higgs ont été faits en C++.
Là où le C++ marque un peu le pas de nos jours, c'est pour l'utilisation de hardware type cartes graphiques pour effectuer du calcul générique, où le C++ est quand même utilisé comme intermédiaire, mais pas jusqu'au bout.

Citation:

---

Envoyé par Pawda

Dans mon cas, je suppose que le temps de développement ainsi que le temps de compilation n'entre pas dans la balance, il s'agit uniquement du temps d'exécution.

---

Je pense que c'est une obligatoirement une exagération de dire ça. Si vraiment le temps de développement n'entrait pas dans la balance du tout, tu n'essaieras pas de programmer ça sur une plate-forme générique, mais tu ferais graver ton propre circuit électronique spécialisé :)
Surtout que rien n'est linéaire... S'il faut 1j pour développer l'algo et qu'il tourne en 1s, il faudra 10j pour qu'il tourne en 0.9, 100j pour qu'il tourne en 0.89, 1000j pour qu'il tourne en 0.889...
Même si tu bosses sur un projet non commercial, où tu pense que ton temps ne compte pas, il te faudra tout de même arbitrer sans cesse entre peaufiner un bout de code déjà écrit et ajouter des fonctionnalités pour aller jusqu'à le finir. Si nous étions une espèce immortelle, peut-être que le temps ne compterait pas. Mais ce n'est pas le cas...

Citation:

---

Envoyé par Pawda

[...] Par exemple, il y a quelques années de ça, j'avais fait un raytracer en C et je me demande si le refaire en C++ avec une conception objet serait équivalent en termes de performances ou plus lent. [...]

---

En utilisant bien le c++, en réfléchissant bien à ce qu'on fait, on peut très facilement atteindre les mêmes performances que le C sans y mettre autant de lignes de code. Voire plus, étant donné que les exceptions sont plus rapides que le check d'un retour d'erreur. (Non, je n'essaie pas de relancer le débat, je ressors juste le résumé de ce qui avait été dit.)

Bien sûr, si tu utilises la virtualité alors qu'avant tu n'en utilisait pas l'équivalent, ou bien si tu utilises dynamic_cast alors qu'avant tu avais un bête C-style cast (équivalent du reinterpret_cast, IIRC), alors oui, tu vas perdre en performances. Mais ce sera un "sacrifice" consenti.

Par contre, en utilisant les fonctionnalités c++ là où avant tu utilisais quelque chose de home-made, tu vas probablement gagner en performances : il est probable que les développeurs de ton compilateur ont plus réfléchi que toi à l'optimisation, et même en ont plus les moyens (e.g. réorganisation du code pour les exceptions, infaisable en C, même avec du linux-like unlikely).

Salut,

Citation:

---

Envoyé par Pawda

4) En C++, lorsque l'on utilise du polymorphisme et que l'on désire stocker ses classes dans une seule "List".
Exemple :
- une classe "Humain".
- une classe "Soldat" héritant "d'Humain".
- une classe "Marchand" héritant "d'Humain".
On désire simplement utiliser une "List<Humain*>".
Vient alors le besoin d'extraire ces classes et de déterminer de quels types elles sont. En PHP on utiliserait "instanceof" pour cela.
En C++, j'ai trouvé plusieurs solutions :
- Utiliser "typeid"
- Utiliser un "dynamic_cast" (problèmes de performance ?)
- Stocker un id dans la classe Humain sous forme "d'enum" de manière à connaitre le type et faire appel à un "static_cast" (limite d'utilisation avec héritage multiple ?)
- Quelle est parmi ces 3 solutions, celle qui est la plus performante ?
- Existe-t-il une solution plus adaptées ?

---

A vrai dire, il existe une autre solution que je trouve, pour ma part, plus adaptée:

1. Tu commences par déléguer correctement les responsabilités des différentes clases qui doivent manipuler tes "humains"
2. Tu manipule tes objets comme étant des "humains" tant que tu peux le faire.
3. Quand tu dois impérativement faire la distinction entre les "marchands" et les "soldats" mais que tu dois gérer les deux types en "même temps", recourir au "double dispatch" (renseigne toi sur le patron de conception "visiteur" ;))
4. Quand tu dois manipuler exclusivement des "soldats" ou exclusivement des "marchands", essaye de les regrouper dans des collections de pointeurs sur leur type réel (soldat ou marchand).

Le (1) doit s'appliquer aussi bien aux types qui manipulent tes "humains" qu'aux fonctions membres qui les manipulent : de manière générale, si une fonction a plus d'une responsabilité, c'est, très clairement, qu'elle en a trop.

Plus tu arrivera à déléguer les responsabilités de manière à avoir des fonctions simples, plus tu pourras "jouer" à invoquer les différentes fonctions dans différents ordres ;)

Pour le (2) : Il y aura fatalement des moments où tu pourras manipuler tes différents "humains" comme étant, tout simplement, des humains alors que des "soldats" et que des "marchands" sont mélangés...

Dans ces conditions, il "suffit" de veiller à ce que les services rendus par "humains" soient suffisants (quitte à être adaptés grâce aux fonctions virtuelles ;)) pour que tu n'aies pas à t'inquiéter du type réellement manipulé ;)

Pour le (3) la règle est, une fois de plus, de déléguer correctement les responsabilités...

Plus tu arriveras à garder des responsabilités simples dans les fonctions membres propres aux "marchands" et aux "soldats", et plus tu pourra faire en sorte que les visiteurs de ces deux classes ont eux aussi des responsabilités simples, plus il te sera facile d'arriver à faire jouer le polymorphisme si besoin ou d'arriver à effectuer un traitement particulier sur un type particulier ;)

Enfin, le double dispatch devrait pouvoir t'aider à mettre le (4) en place avec une classe proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

class HumanSorter { public: template <class iterator> void sortHuman(iterator begin, iterator end) { while(begin != end) { (*begin)->accept(this); ++begin; } } void visit(const Marchand * m) { marchandsTab.push_back(m); } void visit(const Soldat * s) { soldatsTab.push_back(s); } const std::vector<Soldat*>& allSoldiers()const{return soldatsTab;} const std::vector<Marchand *>& allMerchants()const{return marchandsTab;}   private: std::vector<Soldat*> soldatsTab; std::vector<Marchand *> marchandsTab; }

---

qui pourrait être utilisée sous une forme proche de

Code:

---

1 2 3 4 5 6 7

void Game::doSomthingWithSoldiers() { HumanSorter sorter; sorter.sortHuman(allHumans.begin(), allHumans.end()); std::vector<Soldat*> const & tab = sorter.allSoldiers(); /* utilisation de tab en étant sur de n'avoir que des soldats ;) ) */ }

---

Merci pour ces exemples, ils éclaircissent une fois de plus la direction dans laquelle je dois m'orienter. Je suis en effet tombé sur des articles disant que le double dispatch pouvait répondre à ce problème de conception, mais je n'ai encore eu le temps de tester. :)

Citation:

---

Envoyé par oodini

Si tu fais un moteur de rendu, les algorithmes de la STL, tu ne vas pas t'en servir souvent. Et étrangement, tu vas souvent privilégier le C.

---

Ogre 3D (http://ogre3d.org) a toujours été totalement écris avec des conteneurs de la STL, même au tout départ, parceque l'auteur, comme la plupart des gens, n'avait pas que ça a faire de réimplémenter des conteneurs alors que le but cétait def aire un moteur de rendu. Depuis quelques versions, grace aux allocateurs, une implementation d'allocateur (nedalloc http://www.nedprod.com/programs/portable/nedmalloc/ ) est utilisé par défaut pour tous les conteneurs et objets internes a Ogre.

Etrangement (et malgrés le manque de certaines features et de certaines optimizations présentes dans les moteurs commerciaux les plus chers - ce qui n'a rien a voir avec la STL mais plutot des problemes de design et de force de travail), c'est le moteur de rendu open source le plus populaire au monde. Il est d'ailleurs utilisé par des jeux (TorchLight pour ne citer qu'un) a 50% environ, et l'autre 50% sont des implémentations de simulations, surtout dans les musés.


Au passage, pour en rajouter une couche, j'ai implémenté des jeux commerciaux et sur le marché sur NDS uniquement avec la STL parceque j'avais, moi non plus, pas que ça a faire.


Aussi, lire: http://gamedev.stackexchange.com/que...mes-yea-or-nay

Mais je dis graisse...

Citation:

---

Envoyé par Ekleog

Je voulais juste préciser, pour le 4.

De mémoire, il me semble que, en interne, dynamic_cast utilise une enum. Donc une enum n'est pas plus performant qu'un dynamic_cast, et a en plus le désavantage de limiter le nombre d'héritants.
Après, la simple utilisation de dynamic_cast me fait penser qu'il y a un problème : on a tendance à ne plus respecter l'Open-Closed Principle (OCP), puisque pour ajouter un descendant il faut modifier la classe de base pour ajouter un élément à l'enum.

Voilà mon petit grain de sel !

---

j'ai deja jete un coup d'oeil, sous WIndows avec MSVC, un dynamic_cast faisait parfois des comparaisons de chaines. C'etait dans le cas de code charge dynamiquement (DLL) ou l'unicite de certains objets ne pouvait plus etre assuree. En gros, typeid<T> retourne toujours le meme objet (donc on peut simplement comparer les pointeurs) pour un meme module. Si on a des objets de differents modules, le typeid semblait exister independemment dans chaque module.
La consequence est que si la comparaison de pointeurs reussit, les typeid sont bien les memes. Si ca echoue, ca ne veut pas encore dire que c'est different. Du coup tous les dynamic_cast qui ne sont pas triviaux impliquent des compariasons de chaines en cascade.

C'est specifique a une implementation sur un compilateur evidemment.