Discussion :

[Aspic]

Bonsoir,

Je suis actuellement sur la création de mon projet personnel : un remake de zelda, voici le lien vers le topic pour ceux que ca intéresse : (la dernière version du jeu se trouve page 5)http://www.developpez.net/forums/d98...ake-zelda-gbc/

J'aimerais avoir l'avis d'expert sur certains points d'optimisation :

1) Faut-il utiliser des short int plutot que des int quand on a besoin d'une variable allant de 0 à 5 ?

2) Faut-il plutôt utiliser des pointeurs sur classe ou alors la classe directement ? Je m'explique :

Code :

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

1
2
3
4
5
6
7
8
9
 
class tata;
 
class toto
{
private:
  tata* objet; // pointeur
  tata objet; // ou alors pas pointeur
};

Bien sur il y a l'avantage de ne pas oublier le delete quand on utilise pas de pointeur mais niveau mémoire et rapidité d'exécution, lequel est le mieux ?

3) Variables globales ? Pour ou contre ?

4) L'utilisation des opérateurs typeid, static_cast et dynamic_cast sont-ils déconseillés ? (j'utilise typeid dans le cadre du polymorphisme car je dois connaitre le type de mon objet)

5) Doit-on mettre tous les attributs d'une classe en private, en effet il est assez embêtant de constamment avoir à faire des accesseurs en lecture voire écriture pour chaque attributs...

Voilà, si vous avez des conseils à rajouter n'hésitez pas !

Meri à tous

[Mat.M]

Hello,

1) Faut-il utiliser des short int plutot que des int quand on a besoin d'une variable allant de 0 à 5 ?

aucune différence ; je n'ai jamais utilisé des short de ma vie ( sauf l'été quand il fait chaud )
Le type short était valable du temps de Ms Dos lorsque les CPU étaient moins évolués.

Ceci dit si tu utilises un short tu seras amené à faire des "casts" ( cf question à ce sujet ) et utiliser un static_cast ,dynamic_cast ou autre.
Parce que d'un short vers un int ça va , dans l'autre sens la valeur va être tronquée..
pour faire un jeu tu vas être obligé d'utiliser des API graphiques ( Open GL, Direct X ..) et bien souvent les paramètres des fonctions sont des entiers int

2) Faut-il plutôt utiliser des pointeurs sur classe ou alors la classe directement ? Je m'explique :

tout dépend de la conception des classes , de la conception du jeu...
mais en général on utilise des pointeurs sur des classes...
ou bien un simple namespace

Bien sur il y a l'avantage de ne pas oublier le delete quand on utilise pas de pointeur mais niveau mémoire et rapidité d'exécution, lequel est le mieux ?

aucune différence..
dans un jeu ce qui nuit au performace c'est l'utilisation de grosses boucles ...

3) Variables globales ? Pour ou contre ?

dans les langages qui permettent la Programmation Orientée Objet il faut éviter les variables globales et rassembler celles-ci dans des classes..
ou alors utiliser des "namespaces" ou bien des singletons..
mais par exemple si on fait un jeu avec Direct X et win32 on est parfois obligé d'avoir recours à des variables globales..
si tu utilises des threads ( et pour un jeu en réseau tu seras obligé ne serait-ce que pour lancer un "worker thread" pour créer un socket qui écoute sur un port ) on est parfois obligé d'utiliser des variables globales..

4) L'utilisation des opérateurs typeid, static_cast et dynamic_cast sont-ils déconseillés ? (j'utilise typeid dans le cadre du polymorphisme car je dois connaitre le type de mon objet)

c'est à voir...je n'ai jamais utilisé ce genre de "casts" ( transtypage)...
dans le code je fais très rarement des transtypages sauf pour programmer en win32 et appeler des API Windows

5) Doit-on mettre tous les attributs d'une classe en private, en effet il est assez embêtant de constamment avoir à faire des accesseurs en lecture voire écriture pour chaque attributs...

c'est une question que je me pose souvent ; en fait cela ne change pas grand chose de mettre les attributs en public ou private..
mais il est préférable d'avoir des "getters" et "setters"

Dans un jeu on fait un grand usage de conteneurs comme std::map , std::vector ou std::list de la STL

[LittleWhite]

Bonjour,

Dans toutes les questions, je n'ai rien vu qui joué "énormément" sur la performance (je veux dire, de manière sensible).
Par contre ... je crains ceci:

4) L'utilisation des opérateurs typeid, static_cast et dynamic_cast sont-ils déconseillés ? (j'utilise typeid dans le cadre du polymorphisme car je dois connaitre le type de mon objet)

Peut on voir le code lié à ce cas?
En théorie, dan un polymorphisme ... on ne devrait pas avoir trop de cast de ce genre (qui est dynamic_cast d'après moi). De plus, j'ai appris (enfin un truc qui me semble logique) que:
Si on fait un switch sur le type d'une classe (sur un typeid ou technique similaire avec un enum) on peut se jeter d'un pont.
Cela prouve que le design du programme est vraiment mauvais (et puis peut être un problème de performance)

[Aspic]

Alors oui moi aussi je suis contre les cast...
Je ne l'utilise qu'une seule fois dans le code, c'est en fait pour les objets de type "bloc_poussable". Parfois dans le cadre d'un énigme, il faut placer le bloc à un endroit précis.
Pour cela j'ai ajotué un bool bienPlacer dans ma classe mère "Objet". Et dans mon code, je fais :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
// objs est un vector de "Objet"
for (unsigned i=0; i<objs.size(); i++)
{
// si cet objet est de type "bloc_possable"
if (typeid(*objs[i]) == typeid(bloc_poussable)
{
   if (objs[i]->bienPlacer)
   {
      // indiquer ici que l'énigme est résolue...
   }
}
}

Sinon j'ai deux autres questions :

1) Faut-il mieux utiliser la liste d'initialisation dans les constructeurs plutot que de faire attribut = valeur dans les accolades ?

2) Y'a t-il un intérêt d'utiliser les foncteurs et template, plutot que des for classiques ? Exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
struct Afficher
{
    Afficher(BITMAP*& zoneJeu) : zoneJeu(zoneJeu) {}
   template <class T> void operator ()(T const& p) const
   {
      p.afficher(zoneJeu);
   }
 
   private:
    BITMAP* zoneJeu;
};
 
// et son appel :
for_each(tab1.begin(), tab1.end(), Afficher(zoneJeu));
for_each(tab2.begin(), tab2.end(), Afficher(zoneJeu));

Au lieu de :

Code :

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

1
2
3
4
5
6
7
8
9
 
for (unsigned int i=0; i<tab1.size(); i++)
    {
        tab1[i]->afficher(zoneJeu);
    }
for (unsigned int i=0; i<tab2.size(); i++)
    {
        tab2[i]->afficher(zoneJeu);
    }

Merci

[bafman]

1) Faut-il mieux utiliser la liste d'initialisation dans les constructeurs plutot que de faire attribut = valeur dans les accolades ?

oui, c'est au moins egal en terme de performance, au mieux bien plus efficace.
le problème viens du fait que dans tous les cas, à la construction de l'objet, on doit créer le membre. Du coup, si on prend l'exemple d'une string, à la construction de l'objet, il va :
- appeler le constructeur vide de string (qui va initialiser la taille de la string à 0, peut être faire une alloc, appeler une fonction reseau et faire le café)
- appeler l'operateur = qui va faire une alloc, initialiser la taille de la string, appeler notre super fonction reseau et faire un deuxième café.

on est bien d'accord qu'on a fait des truc en double ici (initialiser la taille de la string, le café etc...

alors que si tu passe par la liste d'initialisation, il ne va faire que ce qu'il fait à l'assignation dans le premier cas. C'est donc plus rapide.

Pour le cas des types natifs, ça ne fait pas de différence en compile optimisé. Par contre, en débug, il fait quand même une initialisation par défaut des membres, ce qui rend la version débug encore plus lente

2) Y'a t-il un intérêt d'utiliser les foncteurs et template, plutot que des for classiques ? Exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
struct Afficher
{
    Afficher(BITMAP*& zoneJeu) : zoneJeu(zoneJeu) {}
   template <class T> void operator ()(T const& p) const
   {
      p.afficher(zoneJeu);
   }
 
   private:
    BITMAP* zoneJeu;
};
 
// et son appel :
for_each(tab1.begin(), tab1.end(), Afficher(zoneJeu));
for_each(tab2.begin(), tab2.end(), Afficher(zoneJeu));

Au lieu de :

Code :

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

1
2
3
4
5
6
7
8
9
 
for (unsigned int i=0; i<tab1.size(); i++)
    {
        tab1[i]->afficher(zoneJeu);
    }
for (unsigned int i=0; i<tab2.size(); i++)
    {
        tab2[i]->afficher(zoneJeu);
    }

Pour les perf, j'ai tendance à dire que non sauf que ça permet d'eviter des erreurs simple. Ici par exemple, tu appel size fois la fonction size(), sans avoir de garanti que le compilo va réellement l'optimiser du fait de sa constness. Et encore une fois, c'est plus lent en debug...

Perso, je préfère faire mes boucle à la main, je trouve ça infiniment plus lisible. Et ça compile plus vite aussi.

[LittleWhite]

La question que j'ai envie de poser, cest:
Y a t'il vraiment besoin d'optimiser ? Y a t'il des ralentissements dans le jeu ?

J'ai teste toutes (ou presque) les version du jeu qui sont apparues ici, et je n'ai jamais eu de probleme de vitesse.

De plus, j'ai eu l'occasionm de voir le code a un certain point ... et je dois dire que je ne m'interesserai pas au cas d'optimisations tant que le code ne soit pas mieux designer, ou mieux lisible ....
Donc, a ce point, vous allez nous demander tout un tas de trucs mais qui n'auront que de tres petit effet (et que meme, personne ne remarquera).
De plus, a part le truc du typeid que je trouve horible ... bah voila, je n'ai rien a dire. (on peut remplacer, en implementant une fonction virtuelle isPoussable() par exemple)

[Aspic]

Oui c'est lent sur certain pc de mes amis mais c'est très minime.
Désole de ne pas savoir coder en c++ je suis avant tout un codeur php et vbnet. J'essaye d'apprendre le plus possible de nouveaux langages et ça passe forcément par des erreurs.

Sinon oui pour la méthode virtuelle je n'y avais pas pensér !

Merci

[Astraya]

1) Faut-il utiliser des short int plutot que des int quand on a besoin d'une variable allant de 0 à 5 ?

ça serais plus une optimisation mémoire que performance, et encore, avec le padding tu te retrouve avec un int. Donc ça peut valoir le coup si tu as 2 short au lieu de 2 int niveau mémoire.

Faut-il plutôt utiliser des pointeurs sur classe ou alors la classe directement ? Je m'explique :

ça ça va dépendre de ton architecture. L'une n'est pas meilleur que l'autre. Mais le déréférencement (*p) à un coût dans certaines situations, si il y en à trop voir pour mettre des références si on le peut et vérifier la pertinence du changement. De plus, faire un :

Code :

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

1
2
3
4
5
 
class T
{
short s;
}

couteras 2 octet de moins que faire un

Code :

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

1
2
3
4
5
 
class T
{
short &s;
}

Je dis 2 octets de moins lors du sizeof(T). Sinon aucune différence lorsque la taille de l'objet est plus importante que la taille d'un pointeur.

3) Variables globales ? Pour ou contre ?

Contre tout comme les macros.

L'utilisation des opérateurs typeid, static_cast et dynamic_cast sont-ils déconseillés ? (j'utilise typeid dans le cadre du polymorphisme car je dois connaitre le type de mon objet)

L'appel au RTTI n'est pas conseiller pour des questions de performance, c'est même exclu de la compilation chez certain.
Pour les cast, il y a différent coup à différent niveau.
En gros, static_cast, const_cast, 0 coût à l'exécution, coût a la compilation. dynamic_cast, reintrepret_cast, coût à exécution, 0 coût à la compilation. Donc à préfèrer le static_cast au dynamic_cast. Les autres tu ne devrais pas les utiliser, surtout le reinterpret_cast

Doit-on mettre tous les attributs d'une classe en private, en effet il est assez embêtant de constamment avoir à faire des accesseurs en lecture voire écriture pour chaque attributs...

C'est fortement recommandé.

Ensuite, il a été prouvé ( je ne sais plus ou ) que for_each est 100,04% plus rapide, quelque chose comme ça. Donc négligeable mais recommandé tout de même pour la lecture du code.
Le polymorphisme à un coût, parfait même très très sérieux! Une aggrégation à la place peut modifier radicalement le comportement du jeu dans certains cas. lit ce PDF de la GDC Canada, qui explique très bien et montre une autre alternative (très utilisée) dans le développement de jeu AAA. C'est du data-driven, et la composition est préférer. Observons aussi certaine API qui ont genre 4 5 niveau de hiérarchie maximum ( Havok physics)

[LittleWhite]

Je sais tres bien que vous apprennez le C++, il n'y a pas de probleme la dessus ... mais cette histoire de performances va etre plus difficile a voir si le code est en lui meme un peu bancal.
Un prof m'a dit que des fois, tout peut mieux marcher avec du refactoring :p
(a prendre avec des pincettes )

Sinon un conseil (mais je n'ai pas verifie le code ) c'est d'eviter les copies des gros elements (soit tout ce qui est plus gros qu'un des types de bases du langage)
Ceci peut se faire en utilisant les pointeurs ou (et c'est mieux) les references (constantes so possible)

[Aspic]

Oui je comprends, je sais que la conception des classes du jeu n'est déjà pas optimale car je n'ai pas les compétences ni le temps pour faire une vraie architecture en UML...

Concernant les références, j'ai commencé à les implémenter dans mes classes (enfin je me décide !). J'essaye de les mettre en const mais bon généralement, elle doivent être modifiées...
Et concernant la copie d'objet, j'utilise que des pointeurs donc je n'ai pas ce problème.

[LittleWhite]

Je pense aussi que le probleme de performance peut venir d'Allegro (moi j'en avais avec la SDL, car je l'utilisais un peu mal) ... donc ... je vous conseille de vous renseigner aussi la dessus.

[Ange_blond]

Alors ce qui est sur, c'est que d'utiliser des pointeur et des references est toujours mieux que de copier toute l'instance d'une classe.

[Aspic]

En parlant de ca, quel est l'intérêt de faire une référence sur un pointeur ?

Code :

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

1
2
3
4
5
6
7
8
9
10
 
// extrait de la FAQ de dvp
struct Delete
{
   template <class T> void operator ()(T*& p) const
   {
      delete p;
      p = NULL;
   }
};

[Astraya]

En parlant de ca, quel est l'intérêt de faire une référence sur un pointeur ?

A peut-prêt aucun . A part faire comme si tu voulais une référence nulle et faire bien planter le programme en m'étant le pointeur à 0 . Et rendre le code difficilement compréhensible.

[bafman]

Bien sur que si c'est utile. Ici, l'objectif est de modifier le pointeur pour le mettre à NULL après l'avoir désalloué, comme ça, le code utilisateur récupère un pointeur à NULL. Essaye le même code sans la référence, tu verra qu'il ne fait pas du tout la même chose du point de vu utilisateur.

[maske]

1) Faut-il utiliser des short int plutot que des int quand on a besoin d'une variable allant de 0 à 5 ?

Il y a l'uint8 codé sur 8 bits, équivalent à un char donc. Le short est sur 16 bits - équivalent à l'uint16.

C'est recommandé si on veut optimiser fortement la gestion mémoire, par exemple pour encoder des données qui doivent circuler sur un réseau, sur un matériel embarqué ou je sais pas quoi d'autre. Si on est sur PC, c'est pas vraiment la peine, d'autant plus que ça nécessite des casts dans tous les sens pour être sur que la conversion int vers uint8 passe.

2) Faut-il plutôt utiliser des pointeurs sur classe ou alors la classe directement ? Je m'explique :

Code :

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

1
2
3
4
5
6
7
8
9
 
class tata;
 
class toto
{
private:
  tata* objet; // pointeur
  tata objet; // ou alors pas pointeur
};

Probablement à gérer selon les cas...

3) Variables globales ? Pour ou contre ?

Faut vraiment que ça soit justifié et pas une verrue pour pallier à un défaut de conception ou à un manque de compétences (ou alors faut que ça soit présent au niveau conception, genre un choix "volontaire").

4) L'utilisation des opérateurs typeid, static_cast et dynamic_cast sont-ils déconseillés ? (j'utilise typeid dans le cadre du polymorphisme car je dois connaitre le type de mon objet)

S'il y a besoin de sécurité, le dynamic_cast est probablement mieux. Je ne vois pas de raison particulière d'être contre un cast, c'est parfois justifié...

Il faut privilégier le dynamic_cast sur les types non triviaux par contre, et pas le static. Pour le static_cast, il faut être bien sur de son coup - ce qui n'arrive pas souvent en informatique. Tant pis pour le coût, mais à moins que ça soit une application pour plateforme embarquée à très forte contraintes mémoire et perf, je crois qu'on s'en fout.

Par contre dans l'exemple donné, ça serait pas plus simple d'avoir une variable d'instance à true qui est renvoyée sur une méthode isPoussable() comme suggéré plutôt qu'un test sur un type (ce qui est pas propre du tout non, ni explicite)?

5) Doit-on mettre tous les attributs d'une classe en private, en effet il est assez embêtant de constamment avoir à faire des accesseurs en lecture voire écriture pour chaque attributs...

Oui on doit, on peut en mettre en protected si on fait intervenir de l'héritage et que c'est nécessaire. On ne met rien en public, sinon c'est de la bidouille et c'est pas propre.

Mettre les variables d'instance en public, c'est briser l'encapsulation.

Voilà, si vous avez des conseils à rajouter n'hésitez pas !

Oublies tous les points précédents si tu veux optimiser un programme, regardes dans tes boucles et tes structures de données (notamment les parcours).

C'est là qu'un programme passe (ou perd) la majeure partie de son temps. Vouloir optimiser les points ci-dessus, c'est absolument négligeable à moins d'avoir des contraintes vraiment fortes - et des contraintes plutôt mémoire que performance.

Il est donc je pense plus indiqué de d'abord se soucier du lourd avant de s'attaquer aux détails mineurs insignifiants.

[Note] Perso j'ai déjà été obligé d'utiliser le reinterpret_cast lors de soucis avec de l'héritage multiple (belle merde ce truc au passage). C'est pas à déconseiller, mais faut vraiment savoir ce qu'on fait à ce moment.

[Emmanuel Deloget]

1) Faut-il utiliser des short int plutot que des int quand on a besoin d'une variable allant de 0 à 5 ?

Micro-optimisation. Aucune chance que ça ait un impact visible sur ton jeu.

2) Faut-il plutôt utiliser des pointeurs sur classe ou alors la classe directement ? Je m'explique :

Code :

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

1
2
3
4
5
6
7
8
9
 
class tata;
 
class toto
{
private:
  tata* objet; // pointeur
  tata objet; // ou alors pas pointeur
};

Micro-optimisation. L'intérêt de l'utilisation de l'un ou de l'autre intervient dès lorsque que tu commence à jouer avec le cache data. Un bon contrôle du cache peut permettre de voir un gain en performance dans les programmes qui utilisent beaucoup de données de manière intense.

Bien sur il y a l'avantage de ne pas oublier le delete quand on utilise pas de pointeur mais niveau mémoire et rapidité d'exécution, lequel est le mieux ?

3) Variables globales ? Pour ou contre ?

Cour. Ou Pontre. Je sais que je peux donner l'impression de me moquer, mais ce n'est pas du tout le cas : dans certains cas très particuliers, une variable globale est justifié (cf. std::cin, std::cout, ...). Dans 99,9% des cas, il faut absolument s'en garder.

Ceci dit, ce n'est qu'un problème d'architecture, et pas nécessairement un problème d'optimisation. Au niveau optimisation, une variable globale permet d'eviter un push/pop ici ou là, mais en échange d'un accès mémoire situé très certainement en dehors du cache (et donc, cache miss). Ca reste de la micro-optimisation.

4) L'utilisation des opérateurs typeid, static_cast et dynamic_cast sont-ils déconseillés ? (j'utilise typeid dans le cadre du polymorphisme car je dois connaitre le type de mon objet)

Interdiction absolue d'utiliser typeid et dynamic_cast, sauf dans des cas très particuliers. De plus, c'est à moi qu'il faut demander : il faut m'envoyer un mail en triple exemplaire, me fournir une explication cohérente de la raison pour laquelle il te faut l'utiliser, et peut être, peut être serais-je d'accord avec toi, et tu obtiendras dans ce cas une dispense temporaire. D'ailleurs, dans le cas noté dans ce fil, c'est un refus net et catégorique, assorti d'une amende.

Au niveau performance, ces opérateurs ne sont pas à proprement parler très lents, mais ils sont quand même relativement lent. typeid est équivalent à utiliser une méthode virtuelle. dynamic_cast est bien pire : dans certains cas, il faut marcher le long de la hiérarchie de classes. C'est un algorithme en O(n) donc chaque opération est peu efficace. Il vaut mieux l'éviter.

Cependant, encore une fois, il s'agit de micro-optimisation.

5) Doit-on mettre tous les attributs d'une classe en private, en effet il est assez embêtant de constamment avoir à faire des accesseurs en lecture voire écriture pour chaque attributs...

J'ai une solution pour toi : tu ne fais pas d'accesseurs. Le pire, c'est que je ne plaisante même pas.

Un accesseur simple (par exemple un getter()) dont le code se situe dans le .h a 99,9% de chances de se faire inliner. Le code est donc équivalent à un accès direct à la variable membre. Au niveau des performances, c'est strictement équivalent. Pour le coup, on ne parle même plus de micro-optimisation, puisqu'il n'y en a pas

Toutes les questions que tu te poses sont peu légitimes, sauf si tu est en train d'essayer de trouver 0,05ms par ici, 0,1ms par là, dans le but d'espérer caser une frame de plus par seconde afin de t'adapter à la fréquence de rafraîchissement de l'écran. Je doute que ça soit le cas. Il est possible que tu ait des problèmes de performance, mais je doute que ces problèmes soient liés à un manque de micro-optimisation (qui n'aura de toute façon qu'un impact plus que négligeable sur l'ensemble). Si tu dois cherches des optimisations, pose toi des questions sur les algorithmes employés, compte les copies de larges zones mémoires, etc. Une fois que tu auras fait le tour de tout, alors tu pourras peut-être te poser des questions plus pointues...

[oxyde356]

Salut à toi ^^

1) Faut-il utiliser des short int plutot que des int quand on a besoin d'une variable allant de 0 à 5 ?

Bah autant utiliser des char à ce prix là m'enfin c'est pas vraiment une optimisation importante ...

2) Faut-il plutôt utiliser des pointeurs sur classe ou alors la classe directement ?

En faite ça dépend vraiment de tes patterns de conception, moi par défaut j'utilise directement la classe et si je n'ai pas le choix des pointeurs (ça dépend qui à le rôle de la création/destruction de l'objet), je ne saurais pas vraiment l'expliquer mais c'est ce qui me semble le plus cohérent.

3) Variables globales ? Pour ou contre ?

Il y a plusieurs écoles mais si tu tend à faire de l'orienté objet pure alors pas de variables globales, à toi de trouver où les mettre dans les bonnes classes, à utiliser le pattern singleton etc...

4) L'utilisation des opérateurs typeid, static_cast et dynamic_cast sont-ils déconseillés ? (j'utilise typeid dans le cadre du polymorphisme car je dois connaitre le type de mon objet)

Personnellement j'ai banni typeid et dynamic_cast pour éviter d'utiliser RTTI qui consomme pas mal de performances et qui créé des dépendances. Par contre static_cast il n'y a aucune raison de le déconseiller bien au contraire.

5) Doit-on mettre tous les attributs d'une classe en private, en effet il est assez embêtant de constamment avoir à faire des accesseurs en lecture voire écriture pour chaque attributs...

Cela dépend, pour une classe ... classe oui tous les attributs sont censés être en private, pour une classe ... structure au final non :p par exemple. Une classe Image n'aura pas d'attributs publiques alors qu'une classe Vecteur en aura.

[maske]

Quelqu'un peut expliquer pourquoi vous déconseillez (voir interdisez) le dynamic_cast ?

Moi je vois ça en recommandation dans des normes de codage sur des gros projets industriels, ça a pas l'air de choquer - et en terme de sécurité par rapport à un reinterpret_cast par exemple, je trouve ça mieux personnellement.

Il me semble également que le static_cast est équivalent au cast C brutal ce qui est moyen niveau sécurité quand même.


Pour les attributs en public, c'est un truc qui détruit littéralement l'approche objet - si on fait ça on ne fait pas d'objet. Sinon ça brise d'un seul coup le principe d'encapsulation.

Par exemple c'est impossible de récupérer un attribut en Smalltalk, à moins d'utiliser un accesseur (bon on peut bidouiller quand même mais c'est con), car l'orienté objet est respecté jusqu'au bout.

Après, on est pas obligé de faire de l'objet en C++...

[LittleWhite]

Quelqu'un peut expliquer pourquoi vous déconseillez (voir interdisez) le dynamic_cast ?

Ne va t'il pas parcourir la vtable pour savoir si le cast est faisable ? (ou un truc du genre des fonctions virtuel)

Il me semble également que le static_cast est équivalent au cast C brutal ce qui est moyen niveau sécurité quand même.

C'est toujours moins brutal que celui de C ... car déjà si ce n'est pas un static_cast qui doit être là, le compilateur chouine :p. Le cast C peut convertir des pierres en pigeons à qui on peut demander de voler O_o

Pour les attributs en public, c'est un truc qui détruit littéralement l'approche objet - si on fait ça on ne fait pas d'objet. Sinon ça brise d'un seul coup le principe d'encapsulation.

Par exemple c'est impossible de récupérer un attribut en Smalltalk, à moins d'utiliser un accesseur (bon on peut bidouiller quand même mais c'est con), car l'orienté objet est respecté jusqu'au bout.

Après, on est pas obligé de faire de l'objet en C++...

Et bah là ... moi j'ai un prof de Java (donc plus stricte sur l'objet que le C++) qui me dit, si vous avez une classe dans laquelle vous avez des membres et que vous avez réimplémenté les accesseurs (ecriture et lecteurs) c'est que vous avez une structure (soit en public). Bien sur, je ne dis pas le faire sur les pointeurs / gestion de ressources ... et tout cas ou l'on voudrait avoir des setteurs / getteurs peronnalisé (compté le nombre d'accès ... faire des actions plus compliqué que le simple get / set)