Discussion :

[buzzkaido]

Bonjour,

Question un peu bête, mais je n'arrive pas à trouver d'infos dessus :

Si je multiplie un "int" par un "int", j'obtiens... un "int", n'est-ce pas ?

(sans se préoccuper de leur valeur, débordement, tout ça)

Quel est le type de retour de ces multiplications ?

(char) * (int) ?
(int) * (char) ?
(unisgned long) * (int) ?

etc...

Plus généralement, quel est le type de retour de

(type 1) * (type 2) ?

Avec "type 1" et "type 2" des types natifs c++ ?

[screetch]

les entiers sont sujets a des "promotions"; char + char renvoie un int
tout est promu en int si possible, unsigned si necessaire, long si necessaire.

si je ne me trompe pas,
int + unsigned long renvoie un unsigned long
char + short renvoie un int
unsigned char + unsigned char renvoie un unsigned int

et pour être encore plus précis, ce n'est pas le type de retour mais bien les paramètres qui sont promus;
char+short effectue en fait int+int

[buzzkaido]

Ok, merci pour l'info !

Tu aurais un lien sous la main ?

Et pour les types float / double et le mélange entier / float ou entier / double ? Tu saurais comment ça se passe ?

[screetch]

le standard C++:

4.5 Integral promotions
1 An rvalue of type char, signed char, unsigned char, short int, or unsigned short int can be converted to
an rvalue of type int if int rvalue can be converted to an rvalue of type int if int can represent all the values of the
source type; otherwise, the source rvalue can be converted to an rvalue of type unsigned int.
2 An rvalue of type wchar_t (3.9.1) can be converted to an rvalue of the first of the following types that can represent
all the values of its underlying type: int, unsigned int, long, orint, unsigned long int, long long int, or
unsigned long long int. An rvalue of an enumeration type (7.2) can be converted to an rvalue of the first of the
following types that can represent all the values of the enumeration (i.e. the values in the range bmin to bmax as described
in 7.2: int, unsigned int, long, orint, unsigned long int, long long int, or unsigned long long int.
3 An rvalue for an integral bit-field (9.6) can be converted to an rvalue of type int if int can represent all the values of the
bit-field; otherwise, it can be converted to unsigned int if unsigned int can represent all the values of the bit-field.
If the bit-field is larger yet, no integral promotion applies to it. If the bit-field has an enumerated type, it is treated as any
other value of that type for promotion purposes.
4 An rvalue of type bool can be converted to an rvalue of type int, with false becoming zero and true becoming one.
5 These conversions are called integral promotions.
4.6 Floating point promotion [conv.fpprom]
1 An rvalue of type float can be converted to an rvalue of type double. The value is unchanged.
2 This conversion is called floating point promotion.

9 Many binary operators that expect operands of arithmetic or enumeration type cause conversions and yield result types
in a similar way. The purpose is to yield a common type, which is also the type of the result. This pattern is called the
usual arithmetic conversions, which are defined as follows:
— If either operand is of type long double, the other shall be converted to long double.
— Otherwise, if either operand is double, the other shall be converted to double.
— Otherwise, if either operand is float, the other shall be converted to float.
— Otherwise, the integral promotions (4.5) shall be performed on both operands.59)
— Then if either operand is unsigned long long int, the other shall be converted to unsigned long long int.
— Otherwise, if one operand is long long int and the other unsigned long int or unsigned int, then if a
long long int can represent all the values of the unsigned operand type, the unsigned operand shall be converted
to long long int; otherwise both operands shall be converted to unsigned long long int.
— Otherwise, if either operand is long long int, the other shall be converted to long long int.
— Otherwise, if either operand is unsigned long the other shall be converted to unsigned long.
— Otherwise, if one operand is a long int and the other unsigned int, then if a long int can represent all the
values of an unsigned int, the unsigned int shall be converted to a long int otherwise both operands shall
be converted to unsigned long int.
— Otherwise, if either operand is long, the other shall be converted to long.
— Otherwise, if either operand is unsigned, the other shall be converted to unsigned.
[ Note: otherwise, the only remaining case is that both operands are int —end note ]

[buzzkaido]

Ah ! Génial !

Merci !

[kessoufi]

J'ai un cas que je n'ai toujours pas compris

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
struct Name
{
	explicit Name(const char*);
	operator const char*();
	bool operator==(const Name&) const; // utilise un strcmp
};
...
Name  a("toto"),b("toto");
...
	if(a==b)

là au lieu d'utiliser l'opérateur == de ma classe, le compilateur (VS 2008) a choisi de caster en const char* et compare deux pointeurs ..
résultat : le test échoue

pour éviter cette confusion j'ai opté pour c_str au lieu de l'operator const char*, mais je suis curieux de savoir ce que dit la norme dans ce cas

Merci

[buzzkaido]

Dans ton cas, le type natif est "const char *"

C'est donc normal qu'il compare les valeurs des pointeurs.

Nativement, le compilateur n'a aucune connaissance de ce que c'est qu'une "chaîne de caractères".

D'où les classes String et compagnie...

[kessoufi]

Dans ton cas, le type natif est "const char *"

C'est donc normal qu'il compare les valeurs des pointeurs.

si tu parle de natif au sens clr & cie, mon code est du bon vieux c++ : tout est natif,

donc j'imagine qu'étant devant un operator== le compilateur a le choix entre les operateurs == initalement déclarés, qu'il peut faire un cast au besoin

le souci est que == de ma classe Name est bien appelé dans un test simple et pour la plus part des utilisations de ma classe, mais dans certains cas plus loin, il se met à comparer des const char*

je me rapelle vaguement que la déclaration de l'operator en friend peut résoudre le problème mais je ne sais pas vraiment ce que fera le compilateur pour résoudre l'appel

Code :

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

 if(a==b)

1- avec génération d'un cast par argument :

Code :

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

 bool operator==((const char*)a, (const char*)b)

ou
2- en appelant l'opérateur membre==
a est à la fois argument implicit (this) et explicit de la fonction

Code :

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

 if(a.operator==(a,b))

ou
3- en appelant la fonction friend operator(const Name&, const Name&)

Code :

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

 if(::operator==(a,b))

[screetch]

ca ressemble soit a un bug du compilateur soit tu n'avais pas la declaration complete de la classe (l'operateur == etait invisible au moment de l'utilisation)
il pourrait y avoir des problèmes avec les namespace aussi, des trucs de ce genre.
si tu as plus d'infos ca peut aider a trouver.
Dans le ca sque tu montres, normalement ca marche!

[jblecanard]

Intéressant, c'est peut être la raison pour laquelle la solution c_str() a été retenue dans la STL...

[3DArchi]

Bonjour,
Certains cas peuvent amener à préférer l'utilisation de la conversion plutôt que l'opérateur. Je n'ai plus en tête les exemples précis (un vague souvenir concernant plutôt des conversions avec les bool). C'est entre autre pour cela que C++0x propose d'étendre l'utilisation de explicit aux opérateurs. Cela provoque une erreur au lieu d'utiliser l'opérateur de conversion (cf wiki et faq de Stroustrup)