De la rapidité du code

Bonjour,

A propos des performances j ai une question qui me chagrine. Voici un exemple simple:
si dans une methode appelee frequemment j ai par exemple:

• n traitements independants

• chaque traitement sera effectue en fonction de son activation et celle ci est connue au depart

• Chaque traitement prend les meme donnees en entree

Vaut - il mieux un code comme le suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

void method(...) { if(traitement_1_actif) { traitement_1(...); } ....... if(traitement_n_actif) { traitement_n(...); } }

---

mais j ai peur que tous ces test a effectuer ne ralentissent le code

ou alors l autre alternative que je vois est la suivante:
tous les traitements implementent une interface commune etant donne qu ils utilisent les memes entree

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

constructeur(....) { // m_traitements est un vecteur de traitement membre de la classe if(traitement_1_actif) { m_traitements.push_back(traitement_1); } ....... if(traitement_n_actif) { m_traitements.push_back(traitement_n); } }   void method(....) { // ApplyTraitement est un objet fonction permettant de faire passer les donnees aux traitements du vector for_each(m_traitements.begin(),m_traitements.end(),applyTraitement(...)); }

---

J ai tendance a trouver la deuxieme solution plus elegante mais ce que je cherche avant tout c est l efficacite en terme de temps d execution...
selon vous y en a t il une meilleure que l autre ? ou voyez vous un autre moyen plus efficace ?

Personnellement, en matière d'optimisation, en plus des règles traditionnelles, j'utilise une bibliothèque qui me simplifie grandement la vie et est très performante : QT4.
En effet, j'ai moins de code à écrire, donc moins de risque de perte de performances. L'API est très complète. Il y a un designer qui produit du code relativement propre qui me permet de faire des interfaces rapidement avec d'excellentes performances.
A cela s'ajoute le fait que la gestion du multi-threading est particulièrement efficace, ce qui n'est pas négligeable en matière de performances.

En gros : une bonne API, du code léger mais efficace et le tour est joué.

Citation:

---

Envoyé par LeGreg

les operateurs binaires operent sur les representations binaires
des nombres. Point.

---

Attention, il ne faut surtout pas confondre "opérateur binaire" et "opérateur agissant sur la représentation binaire" !
Par exemple, ~ est un "opérateur agissant sur la représentation binaire" mais est unaire car ne prend qu'une opérande.
En revanche, * et / sont binaires car ils prennent deux opérandes.

Salut tout le monde,
J'ai vu dans les premières pages qu'il fallait régulièrement bencher son code, mais vous le faites comment?
Avec un clock() ?
Merci

J'aurais une petite question :

quelle différence entre int x (65) et int x = 65 ?

Est-ce que ça a le même effet que ça :

MaClasse:MaClasse ()
: x (65) <---- Ca ?
{
}

J'autre part, j'ai vu sur les papiers du prochain standard une rvalue référence, qui permettrait de faire ça :

MaClasse && operator + (MaClasse obj1, MaClasse obj2)
{
return MaClasse (obj1.x + obj2.x, obj1.y + obj2.y);
}

Sans l'appel à un constructeur de copie ? Comme ça se fera internement (ça se dit ?). Provoquera t'il une amélioration des perfs que ce qui se passe actuellement (car d'après ce que j'ai compris, dans les cas comme ci-dessus, le compilo utilise l'optimisation RVO qui annule un peu cette surcharge ?

Salut,

Pour les types de base ((unsigned)char, (unsigned) int, (unsigned) float, (unsigned) double etc), il n'y a pas de différence entre le fait d'utiliser la liste d'initialisation et celui de faire l'initialisation dans le corps du constructeur.

Par contre, là où la différence apparait, c'est dans le cadre où le membre à initialiser est une classe ou une structure.

En effet, en mettant que l'on aie une classe du genre de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

class Membre { public: Membre(){} Membre(int i, float j) { /* ici, ca ne change pas grand chose */ _i=i; _j=j; } void SetI(int i){_i=i;} void SetJ(float j){_j=j;} int GetI(){return _i;} float GetJ(){return _j;} private: int _i; float _j; };

---

qui doit servir de membre dans la classe

Code:

---

1 2 3 4 5 6 7 8 9 10

class MaClasse { public: MaClasse(Membre& m); MaClasse(int i, float j); /*...*/ private: Membre mem; };

---

Le fait d'utiliser la liste d'initialisation apportera un gain de temps sous la forme de

Code:

---

1 2 3 4 5 6 7 8

MaClasse::MaClasse(Membre& m):mem(m){}/* utilise   * Membre::Membre(Membre&)   */ /* ou */ MaClasse::MaClasse(int i, float j):mem(i,j){}/* utilise   * Membre::Membre(int i, float j)   */

---

par rapport aux constructeurs sous les formes de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

MaClasse::MaClasse(Membre& m) /* utilise Membre::Membre() */ { mem.SetI(m.GetI());/* il faut encore initialiser les valeurs de mem */ mem.SetJ(m.GetJ()); } /* ou */ MaClasse::MaClass(int i; float j)/* utilise Membre::Membre() */ { mem.SetI(i);/* il faut encore initialiser les valeurs de mem */ mem.SetJ(j); }

---

pour la simple raison que, les versions utilisant les liste d'initialisation se contenteront de l'appel du constructeur qui va bien selon le cas (par copie, ou en fournissant les valeurs nécessaire) alors que les autres versions vont:

• Utiliser des valeurs par défaut pour le constructeur (généralement 0 pour _i et 0.0f pour _j dans l'exemple)
• devoir assigner, pour chacun des membre de la classe membre (ici _i et _j) la valeur que l'on veut leur donner

Citation:

---

Pour les types de base ((unsigned)char, (unsigned) int, (unsigned) float, (unsigned) double etc), il n'y a pas de différence entre le fait d'utiliser la liste d'initialisation et celui de faire l'initialisation dans le corps du constructeur.

---

C'est faux.
Si le type est construit avec new, alors toutes ses variables membres qui sont des types de base seront initialisés à 0.

Citation:

---

Envoyé par loufoque

C'est faux.
Si le type est construit avec new, alors toutes ses variables membres qui sont des types de base seront initialisés à 0.

---

Heuuu, faut il rappeler que le sujet et "de la rapidité du code", et que ton intervention n'a donc pas de sens de ce point de vue.

Mon intervention étant à prendre dans le sens que j'ai expliqué: si le membre est d'un type primitif, il n'y aura pas de différence du point de vue de la rapidité d'exécution entre le fait d'utiliser une liste d'initialisation ou non. Par contre, si l'on veut initialiser un membre qui n'est pas strictement un type primitif, ce sera plus rapide d'exécution d'utiliser la liste d'initialisation, et sur ce coup là, rien n'est faux ;)

Citation:

---

si le membre est d'un type primitif, il n'y aura pas de différence du point de vue de la rapidité d'exécution entre le fait d'utiliser une liste d'initialisation ou non

---

Je viens pourtant de t'expliquer que non.
Avec ton code, par exemple, _i et _j peuvent d'abord être initialisées à 0 avant que les valeurs i et j y soient assignées.
Alors que si tu utilisais les listes d'initialisations, _i et _j seraient directement initialisées à la valeur voulue.

Citation:

---

Par contre, si l'on veut initialiser un membre qui n'est pas strictement un type primitif, ce sera plus rapide d'exécution d'utiliser la liste d'initialisation, et sur ce coup là, rien n'est faux

---

Ce n'est pas qu'une question de rapidité, c'est aussi une question de sémantique. Initialiser une variable ce n'est pas la même chose que d'assigner une valeur à une variable.
De plus, toutes les variables ne peuvent pas nécessairement s'initialiser par défaut.

Citation:

---

Envoyé par loufoque

C'est faux.
Si le type est construit avec new, alors toutes ses variables membres qui sont des types de base seront initialisés à 0.

---

Ca aussi, c'est faux.
Le constructeur par défaut est appelé, et les types de bases ne sont initialisés à 0 qu'en mode debug.

En mode Debug sous quel plate-forme ?
C'est totalement contre-productif d'initialiser à zéro en mode Debug. Des valeurs telles que 0xCCCCCCCC sont plus utiles...

Avec GCC par exemple, même chose pour Visual, ...

Citation:

---

les types de bases ne sont initialisés à 0 qu'en mode debug

---

C'est quand même fou.
Je vais donc répéter pour une troisième fois, et citer le standard pour ceux qui ne veulent pas me croire.

Les types de base sont initialisés à 0 quand on utilise new.
Par exemple

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

#include <iostream>   struct Foo { int value; };   int main() { Foo v1; int t; Foo* v2 = new(&t) Foo(); Foo* v3 = new Foo();   std::cout << v1.value << std::endl; std::cout << v2->value << std::endl; std::cout << v3->value << std::endl;   delete v3; }

---

affichera dans le premier cas une valeur indéfinie, et dans les deux autres 0.

Voir paragraphe 5.3/16 de N2284.

Encore pire dans ce cas.

Citation:

---

Envoyé par loufoque

Citation:

---

Pour les types de base ((unsigned)char, (unsigned) int, (unsigned) float, (unsigned) double etc), il n'y a pas de différence entre le fait d'utiliser la liste d'initialisation et celui de faire l'initialisation dans le corps du constructeur.

---

C'est faux.
Si le type est construit avec new, alors toutes ses variables membres qui sont des types de base seront initialisés à 0.

---

Tu confonds. Si il y a des constructeurs -- et si c'est pas un POD, il en faut, éventuellement généré automatiquement -- new va appeller un de ceux-ci, et dans ce cas les membres d'un type de base non présents dans la liste d'initialisation ne sont pas initialisés. Pour les POD sans constructeur, effectivement new fait une initialisation à 0.

Je crois que dans le cas de VC++ c'est le cas depuis la version 2005 seulement.
Sinon je viens d'apprendre aujourd'hui que les types de bases étaient initialisés à zéro s'ils étaient statiques.

Visual Studio suit (pour une fois) les recommendations et ne fait (par défaut) aucune initialisation lors d'un 'new' d'un objet avec constructeur, à part celle indiquée dans la liste d'initialisation.

Il existe un flag du compilateur, qui peut le forcer à remplir la mémoire par (de mémoire) 0xCD, flag utilisé en mode "debug", et qui permet de trouver bien vite les bugs (bien plus vite qu'une initilalisation à 0 en tout cas).

Il se peut qu'en mode "release" l'initialisation par affectation dans le constructeur soit identique à celle par la liste d'initialisation, j'avoue n'avoir jamais eu à le vérifier (pas encore eu de profiler me montrant du doigt un constructeur à optimiser).

En cherchant des infos la dessus, je découvre que, d'apres la MSDN, le standard fait une distinction entre:

Code:

---

int *i = new int;

---

et

Code:

---

int *i = new int();

---

l'initialisation de *i a 0 ne se ferait que dans le 2eme cas...
http://msdn2.microsoft.com/en-us/lib...y9(VS.80).aspx

8O

VC++ 2003 respectait cela uniquement pour les types scalaires. VC++ 2005 le respecte aussi pour les classes:
http://msdn2.microsoft.com/en-us/lib...8k(VS.80).aspx

Aurélien > De manière analogue, si on écrit int test (), test semble aussi avoir une valeur par défaut (chez moi c'est 1).

Si tu écris int test(), tu déclareras une fonction renvoyant un int, pas une variable ;)