Discussion :

[Kaluza]

Bonjour.

J'étais en train de faire de la surcharge d'opérateurs quand j'ai constaté une chose sur la page "Operators in C and C++" de Wikipédia :
http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B

Je vois que pour chaque opérateur, deux formes sont proposées :
- "As member of T" : exemple : "T& T::operator -=(const T& b);"
et
- "Outside class definitions" : exemple : "T& operator -=(T& a, const T& b);"

Je n'ai jamais tenté l'option n°2 et j'aimerai connaître ses avantages/inconvénients par rapport à la méthode n°1 : en particulier si la mémoire/cpu est critique et que je vais avoir des dizaines de milliers d'exemplaires des classes concernées.

De plus, y-a-t-il possibilité d'inliner l'option 2 comme on inlinerai l'option 1 ? Est-ce que à l'usage c'est totalement transparent pour l'utilisateur ?

Merci beaucoup.

[Flob90]

Bonsoir,

D'un point de vue performance c'est pareil que la différence entre fonction membre et fonction libre (qui feraient la même chose) : probablement aucune différence (sauf si virtual). D'un point de vue technique certains opérateurs doivent être libres pour des raisons de conversions et symétries. D'un point de vue conceptuel, certains opérateurs ont bien plus de sens en étant membres ou libres selon la situation.

Oui, tu peux inliner de la même manière (note qu'inline n'est qu'une indication, pas une obligation pour le compilateur). Oui, c'est transparent pour l'utilisateur (sauf si l'opérateur est membre alors que l'opérateur a besoin de la symétrie et de la conversion).

[3DArchi]

Salut,
Pas grand chose à rajouter à la réponse de Flob90 si ce n'est l'entrée de la F.A.Q : J'ai pour surcharger mon opérateur la possibilité d'utiliser une fonction membre ou une fonction libre, que choisir ?

[Kaluza]

Merci ça m'éclaire pas mal.

En voyant vos réponses une question que je me suis toujours posé à refait surface. Est-ce que des fonctions membres d'une classe prennent de l'espace mémoire à chaque nouvel objet créé ? Autrement dit, si l'on imagine 3 classes :
- classe A avec comme data members un tableau de 256 int + 20 fonctions membres non statiques
- classe B avec comme data members un tableau de 256 int + 20 fonctions membres statiques
- classe C avec comme data members un tableau de 256 int + 20 fonctions "libres" externes qui opèrent sur cette classe

En admettant que chacune de ces fonctions prenne le même espace mémoire. Si je déclare ensuite 1000 objets A, 1000 objets B et 1000 objets C, occuperont-ils la même place en mémoire ?

Bref est-ce que des fonctions membres "alourdissent" le poids d'une classe au runtime comme c'est le cas avec les données membres ?

Merci beaucoup

[Flob90]

Non, le seul surcout c'est celui d'un pointeur dans le cas d'utilisation de fonctions virtuelles.

Je n'en suis pas certain, mais il me semble que les fonctions ne prennent pas de place en mémoire au même sens que les données membres. Elles prennent de la place "dans le binaire", mais pas dans la mémoire vive.

[3DArchi]

Elles prennent de la place "dans le binaire", mais pas dans la mémoire vive.

A ma connaissance, sur un PC, les fonctions sont chargées en RAM pour être exécutées. Elles ne sont pas sur les mêmes sections et la mémoire n'a pas les mêmes propriétés (droit d'accès, déplacement, chargement/déchargement...) que pour les données 'dynamiques' (piles, tas, variables globales non const). En embarqué, le code est souvent exécuté depuis une flash et n'est pas chargé en RAM (sauf demande express du codeur d'exécuter la fonction en RAM pour par ex mettre à jour la flash...)

[3DArchi]

Est-ce que des fonctions membres d'une classe prennent de l'espace mémoire à chaque nouvel objet créé ?

Pour les fonctions non virtuelles, non. Le code est partagé, il n'y a pas de pointeur caché ou quoique ce soit d'autre. 1 objet ou 1 0000000000000000000000000 d'objets n'aura pas de surcout en fonction des fonctions de la classe.

Cependant pour les fonctions virtuelles il y a une subtilité :
=> chaque classe possédant des fonctions virtuelles a une table de pointeur de fonction dont le nombre d'entrées est en proportion du nombre de fonction virtuelles (détail d'implémentation, non normalisé)
=> chaque instance va avoir un pointeur vers cette vtable comme un membre caché. Mais ce sera toujours un nombre de pointeur en rapport avec le nombre de classes de base (terminale) et non de nombre de fonctions virtuelles