Discussion :

[Miko95]

Bonsoir,
J'aimerais savoir si quelqu'un pourrait m'eclairer au niveau de la surcharge de fonctions, à savoir est ce qu'il existe un tutoriel à ce sujet pour savoir quelle fonction sera appelée parmis plusieurs sosies.
Peut etre quelqu'un aurait des methodes sur ce domaine à faire partager.
Merci

[flyweight]

regardez
http://cpp.developpez.com/cours/cpp/...age_3#LIII-F-4

[Pacorabanix]

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
17
18
19
20
21
22
23
24
25
26
27
28
29
30
#include <iostream>
using namespace std;
 
void maFonc(int a) {cout << "Fonction int appelée" << endl;}
void maFonc(long a) {cout << "Fonction long appelée" << endl;}
void maFonc(float a) {cout << "Fonction double appelée" << endl;}
 
int main() {
    int x = 0;
    long y = 0;
    float z = 0;
    double probleme = 0;
 
    maFonc(x);  // pas d'ambiguité, le type du param joue parfaitement
    maFonc(y);  // pas d'ambiguité
    maFonc(z);  // pas d'ambiguité
 
    maFonc(5);  // compile parfaitement car 5 est un constante entiere, int par defaut. Ce'st bien maFonc(int) appelée. 
    // S'il n'y a PAS de maFonc(int), erreur car 5 peut etre converti en float ou en long de manière équivalente pour le compilo. 
    //(il y aurait conversion implicite, mais il ne sais pas en quoi le faire car il connait plusieurs manière de le faire)
 
    maFonc(0.25); // 0.25 est une constante double. 
    //Elle peut facilement etre convertie en float, mais aussi int ou long du point de vue du compilo,
    // encore une fois ce sont des conversions implicites qui devraient avoir lieu, mais le compilo ne sait pas laquelle ... 
    //Donc erreur de compilation (resolution ambigüe).
 
    maFonc( static_cast<float>( 0.25 )); // compile. pas d'ambiguité, on donne explicitement la conversion à faire.
 
    maFonc(probleme); //ne compile pas pour les memes raisons que 0.25 
}

je ne sais pas s'il existe des compilos mais ce bout de code devrait t'éclairer un peu.

En fait tout est un histoire de conversion implicite :

Si le type de la variable (ou constante) joue parfaitement avec une des fonctions surchargées, c'est celle là qui sera prise.

Si non le compilo regarde s'il sais faire des conversions de type. Par exemple un compilo sais faire une conversion d'une classe fille vers une classe mère lors d'héritage (en cas d'héritages multiples). de plus les divers constructeurs d'objets fournissent en fait des opérations de conversions.

Et donc : si le compilo remarque qu'il peut convertir de plusieurs manières l'argument de sorte qu'il joue avec *plusieurs* fonctions surchargées -> Erreur de compilation (résolution de conversion ambigue). Sinon c'est bon, il convertit l'argument de la seule manière utilisable par une seule fonction surchargée.

[NiamorH]

http://cpp.developpez.com/cours/cpp/...age_3#LIII-F-4

Ouais mais justement :

D'une manière générale, le compilateur dispose d'un ensemble de règles (dont la présentation dépasse le cadre de ce livre)

Je viens de faire tout un speech à ce sujet ici : http://www.developpez.net/forums/sho...d.php?t=474036

C'est pas non plus exaustif.
Par example il faut savoir que pour résoudre une ambiguité, si le compilateur à le choix entre une fonction template et non template, il choisira la non template.
De même entre deux fonctions template, le compilateur choisira la plus spécialisée (pas toujours possible à déterminer) donc la question devient : qu'est ce qui fait qu'une fonction template est plus spécialisée qu'une autre?

Mais déjà ça peut te donner une idée.

[JolyLoic]

Il y a très peu de gens au monde qui connaissent et maîtrisent toutes les subtilités de la résolution de surcharge de fonctions en C++. Peut-être quelques écrivains de compilateurs, s'ils ont fait ça il y a peu de temps...

La règle principale à retenir, c'est que dans la grande majorité des cas, ça marche de manière "naturelle" pour l'utilisateur...

[NiamorH]

maFonc(5);
// S'il n'y a PAS de maFonc(int), erreur car 5 peut etre converti en float ou en long de manière équivalente pour le compilo.
//(il y aurait conversion implicite, mais il ne sais pas en quoi le faire car il connait plusieurs manière de le faire)

Et bien normalement non car int -> long est une simple promotion et int -> float requiert une convertion standard.

maFonc(0.25); // 0.25 est une constante double.
//Elle peut facilement etre convertie en float, mais aussi int ou long du point de vue du compilo,
// encore une fois ce sont des conversions implicites qui devraient avoir lieu, mais le compilo ne sait pas laquelle ...
//Donc erreur de compilation (resolution ambigüe).

Ici oui car il s'agit de double -> float. Ce serait l'inverse, il pourrait de la même manière faire une promotion.

En fait tout est un histoire de conversion implicite :

Pas uniquement. Dans l'idée je suis d'accord mais il y a des subtilités (voir mon autre post).

Si le type de la variable (ou constante) joue parfaitement avec une des fonctions surchargées, c'est celle là qui sera prise.

Exact.

de plus les divers constructeurs d'objets fournissent en fait des opérations de conversions.

C'est aussi à prendre en compte oui.

[NiamorH]

La règle principale à retenir, c'est que dans la grande majorité des cas, ça marche de manière "naturelle" pour l'utilisateur...

C'est très vrai. Le seul moment où ça peut vraiment déconner, c'est lorsque le programmeur a lui même implémenté des opérateurs de convertions implicites à foison dans ses classes. Là on peut se trouver face à des bizareries.

On peut noter aussi que le compilateur tente d'enchaîner plusieurs convertions implicites à la suite (cast d'un pointeur vers un objet -> void* puis -> bool) mais il n'utilisera au maximum qu'un seul opérateur de convertion implicite définit par l'utilisateur dans sa séquence.

[Pacorabanix]

Citation:
Envoyé par Pacorabanix Voir le message
maFonc(5);
// S'il n'y a PAS de maFonc(int), erreur car 5 peut etre converti en float ou en long de manière équivalente pour le compilo.
//(il y aurait conversion implicite, mais il ne sais pas en quoi le faire car il connait plusieurs manière de le faire)

Et bien normalement non car int -> long est une simple promotion et int -> float requiert une convertion standard.

J'ai testé (je ocmpile sous XCode), une erreur se passe bel et bien. Apparemment la promotion int -> float et int -> long est au meme niveau pour le compilo.



Pour compléter ce qui a été dit ici, l'exemple de la FAQ permet aussi de cerner une subtilité (tout a fait naturelle je trouve) lorsqu'il y a plusieurs arguments.

Ce code :

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
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
#include <iostream>
using namespace std;
 
void test(int i, int j)
{
    cout << "test(int, int)" << endl;
}
 
void test(float i, float j)
{
    cout << "test(float, float)" << endl;
}
 
int main() {
    int x = 0;
    float z = 0;
 
    test(x, x); // utilise int, int
	test(z, z); // utilise float, float
 
    test(2, 2.5); // utilise int, int (warning car convertit 2.5 (double) en int)
	test(2.5, 2); // utilise int, int (warning car convertit 2.5 (double) en int)
	// car un des arguments joue DEJA PARFAITEMENT ( le int),
	// reste a convertir le double en ... int! (seule possibilite)
 
	test( z, x); // error un float un int, il ne sait aps dans quel sens la convertion doit se faire	
	test(x, z); // error idem
 
	test(2.5, 2.5); // error
 
}

genère chez moi ces erreurs :

gcc
/Users/lioobayoyo/test/main.cpp: In function `int main()':
/Users/lioobayoyo/test/main.cpp:21: warning: passing 'double' for converting 2 of 'void test(int, int)'
/Users/lioobayoyo/test/main.cpp:22: warning: passing 'double' for converting 1 of 'void test(int, int)'
/Users/lioobayoyo/test/main.cpp:26: error: call of overloaded 'test(float&, int&)' is ambiguous
/Users/lioobayoyo/test/main.cpp:4: note: candidates are: void test(int, int)
/Users/lioobayoyo/test/main.cpp:9: note: void test(float, float)
/Users/lioobayoyo/test/main.cpp:27: error: call of overloaded 'test(int&, float&)' is ambiguous
/Users/lioobayoyo/test/main.cpp:4: note: candidates are: void test(int, int)
/Users/lioobayoyo/test/main.cpp:9: note: void test(float, float)
/Users/lioobayoyo/test/main.cpp:29: error: call of overloaded 'test(double, double)' is ambiguous
/Users/lioobayoyo/test/main.cpp:4: note: candidates are: void test(int, int)
/Users/lioobayoyo/test/main.cpp:9: note: void test(float, float)

et les fonctions qu'il utilise sont indiquées en commentaires.

Pour test(int, double) -> test (int, int) et test(double, int) -> test(int, int)

Cela me semble normal : si des arguments jouent *deja* parfaitement sans conversion, le compilo va d'abord voir s'il peut convertir les arguments qui ne jouent pas. Et seulement après il tentera de convertir des arguments qui jouaient pourtant deja bien avec certaines versions surchargées.

EDIT:Cela clarifie pas mal l'ordre de décision deja . après c'est vrai qu'il y a toujours les cas super tordus. Mais dans ce cas chaque cas nécessiterai un post à lui je pense .

[NiamorH]

J'ai testé (je ocmpile sous XCode), une erreur se passe bel et bien. Apparemment la promotion int -> float et int -> long est au meme niveau pour le compilo.

Effectivement il n'y a pas de promotion de int -> long, j'aurai cru.

Par contre il y en a bien dans chacun des exemples :

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
void func( int );
void func( long );
void func( double );
 
int main()
{
  char  c = 5;
  short s = 5;
  bool  b = true;
  float f = 5;
  func( c );
  func( s );
  func( b );
  func( f );
}

[flyweight]

Bonsoir

http://cpp.developpez.com/cours/cpp/...age_3#LIII-F-4
Ouais mais justement :
D'une manière générale, le compilateur dispose d'un ensemble de règles (dont la présentation dépasse le cadre de ce livre)

comment le compilateur sait quelle version de la fonction func() il faut appeler ?

il collecte toute les fonctions accessible de la symbole-table qui ont le même nom que la fonction func
exclue toute les fonction qui n'ont pas le même nombre de paramètres
si aucune fonction ne correspond alors il renvoie une erreur
le compilateur choisit directement une fonction si les les arguments sont exactement les paramètres.

Si il ya plus d'une correspondance, choisir la meilleure correspondance.
Lors de la décision sur la meilleure correspondance, le compilateur fonctionne sur un système de notation selon l'ordre suivant :
1. Une correspondance exacte
2. Une promotion
3. Une conversion standard
4. un constructeur ou une conversion définie par l'utilisateur

>une promotion c-a-d un des cas suivant :
*{char, unsigned char, short} -> int
*float->double
*bool-> int

>ou une conversion standard de type c-a-d:
* conversions entre types scalaire, à l'exception de ceux qui sont considérés comme des promotions.
* Conversions entre les types flottant: double, float et long double
* Conversions entre les types flottants et scalaire
* conversions de scalaire, pointeur et de type flottant à bool (zéro ou NULL est FALSE, tout le reste est VRAI)
* Conversion d'un entier à zéro le pointeur NULL.

>S'il n'y a pas de gagnant clair des meilleurs correspondance, le compilateur signale une erreur


un lien en anglais http://www.dcs.bbk.ac.uk/~roger/cpp/week20.htm

[Miko95]

Merci pour toutes ces réponses mais desfois je comprends pas trop comment ca se passe, par exemple dans ce cas :
si je declare deux fonctions "func" de la sorte :

Code :

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

1
2
3
4
5
6
7
8
 void func (int n, int p)
{
...........
}
           void func (float n, float p)
{
...........
}

ensuite je fais cet appel :

Code :

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

 func(3.2,5);

J'ai vu que c'était la fonction avec les deux arguments int qui était appelée mais je comprends pas pourquoi celle la( je me suis dis qu'apres la conversion de 3.2 en int il y aurait perte de la partie décimale alors que si on appelait la deuxieme fonction qui prends les deux arguments float on aurait qu'à convertir 5 en float et on perdrait rien)
Merci

[JolyLoic]

3.2 n'est pas un float, mais un double. Donc, pour la première, il faut :
- Convertir de double en int le premier argument
- Le second argument est au bon format

Pour la seconde :
- Convertir de double en float le premier argument (ce qui perd aussi de l'info)
- Convertir de int à float le second.

On voit que la première gagne.

Si tu faisais le test avec 3.2f, qui lui est un float, tu verrais d'autres choses.

Question : Pourquoi utiliser des floats ? C'est déjà assez difficile d'écrire du code correct avec des doubles, alors avec des floats, statistiquement, les problèmes arrivent encore plus vite...

[poukill]

Je suppose que ceux qui utilisent les float voient un gain de place en mémoire...
Mais c'est vrai que maintenant, avec les quantités de mémoires disponibles, ça paraît effectivement inutile de les utiliser...

Question d'ailleurs : au niveau temps de calcul, qu'est-ce qui est la plus rapide entre les deux calculs suivant? Les float sont plus rapides ou c'est complètement équivalent?

Code :

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

1
2
3
float a = 1.25876;
float b = 9.54861;
float c = a * b;

Code :

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

1
2
3
double a = 1.25876;
double b = 9.54861;
double c = a * b

[ac_wingless]

Une chose dont il faut se souvenir aussi: les règles évoquées ci-dessus ne s'appliquent qu'à l'intérieur du scope local. En particulier, les surcharges ne sortent pas du namespace et ne remontent pas la hiérarchie de classe.

Exemple:

Code :

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

1
2
3
4
struct A { void f ( const char * ); };
struct B : public A { void f ( float ); };
 
    B().f("toto"); // erreur: pas de conversion vers float

[nicroman]

Sans vouloir dire trop de bétise, de manière interne (a partir de SSE2 tout du moins) float et double sont traités par le même hardware, donc vitesse identique.

Pour ce qui est du code en question, c'est encore pire, puisque le processeur ne fait rien du tout (c'est le compilateur qui fait la multiplication)

Dans une boucle sur un array de float/double, le compilateur va selectionner les fonctions SSE ad-hoc (qui existent en version float/double de la même manière).

Dans une grosse boucle genre:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
 
void interpolate(ALIGNED FLOAT* dest, FLOAT t, ALIGNED FLOAT* src1, ALIGNED FLOAT* src2, int size)
{
FLOAT omt = MAKE_FLOAT(1.0)-t;
for (int i = 0; (i < size); ++i) 
   c[i] = a[i] * omt + b[i] * t;
}
 
ALIGNED FLOAT a[16384];
ALIGNED FLOAT b[16384];
ALIGNED FLOAT c[16384];
interpolate(c,t,a,b);

Dans laquelle on passe 100 fois par seconde, là, par contre, on voit une différence (presque) flagrante entre float et double. Ca ne vient pas du processeur (SIMD/SSE), mais du cache data. Et traiter 16384 doubles demande 2x plus de bande passante mémoire que de traiter 16384 floats....

[Miko95]

Donc si j'ai bien compris c'est juste du au fait qu'il y a moins de conversion dans l'appel de la premiere fonction par rapport à la deuxieme, que la premiere fonction soit appelée?
On ne tiendrait pas compte du fait qu'on perde moins de donnees en appelant la deuxieme?(on pourrait convertir 3.2 en float ce qui fait perdre moins de donnees je pense que si on convertissait 3.2 en int et on convertit 5 en float ce qui ne fait pas perdre de donnees donc au final on pourrait penser que c'est plus avantageux d'appeler la deuxieme?Non?)
Merci

[NiamorH]

Oui le compilateur n'utilise pas la notion de "plus avantageux" en terme de conservation/pertes de données, il choisit juste la fonction dont le type des paramètres sont au plus proche du type des arguments.

Ca n'empeche pas le fait qu'il devrait te donner un warning "attention conversion de double en int, perte de données possible"

[poukill]

Attention, convertir 5 de int en float fait aussi perdre des données, car le résultat va certainement donner quelquechose comme ça :
5.000000007
Ceci est dû au codage interne des nombres flottants !

-> http://cpp.developpez.com/faq/cpp/in...ions_flottants

[JolyLoic]

Attention, convertir 5 de int en float fait aussi perdre des données, car le résultat va certainement donner quelquechose comme ça :
5.000000007

Sauf erreur de ma part (ce n'es pas mon domaine, donc risque d'erreurs), une telle erreur ne peut pas arrive, un nombre entier petit étant représentable de manière exacte.
Sur un float standard, la mantisse étant codée sur 26 bits, je pense que seuls les entiers supérieurs à 2^26 peuvent commencer à avoir une conversion en float non exacte.

[JolyLoic]

Oui le compilateur n'utilise pas la notion de "plus avantageux" en terme de conservation/pertes de données, il choisit juste la fonction dont le type des paramètres sont au plus proche du type des arguments.

Le compilateur différencie conversion sans perte, nommée type promotion, de celles à perte (type conversion). Maintenant, une fois qu'une conversion est à perte, il ne cherche pas à savoir si elle perd plus ou moins qu'une autre.