Discussion :

[yan]

Bonjour, y as t'il un moyen de faire choisir l'appel d'une fonction const à celle non const?

Par exemple dans Qt, il as souvent les fonctions complémentaire :

Code :

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

1
2
uchar * scanLine ( int i )
const uchar * scanLine ( int i ) const

seulement, dû au COW utilisé par Qt, la version const est plus rapide (pas de deferencement car const).

Y as t'il une possibilité de privilégier la version const (quand c'est possible) à celle non const?

ou faut t'il travailer avec une reference const sur l'objet?

[r0d]

Salut fillot

De ce que j'ai compris, la fonction const sera appelée dans le cas où l'instance qui appelle cette fonction est constante:

Code :

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

1
2
3
4
5
6
void f( const Dum & d1)
{
   Dum d2;
   d1.UneFonction(); // va appeler la version const de UneFonction()
   d2.Unefonction(); //  va appeler la version NON const de UneFonction()
}

Je ne sais pas si ça répond à ta question (te connaissant, ça me parait trop facile pour être ça ).

[screetch]

Code :

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

1
2
3
4
5
void f( Dum & d1)
{
   ((const D&)d1).UneFonction(); // va appeler la version const de UneFonction()
   d1.Unefonction(); //  va appeler la version NON const de UneFonction()
}

[yan]

Code :

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

1
2
3
4
5
void f( Dum & d1)
{
   ((const D&)d1).UneFonction(); // va appeler la version const de UneFonction()
   d1.Unefonction(); //  va appeler la version NON const de UneFonction()
}

il n'y as d'autre façon pour obliger l'appel, quand c'est possible, de la fonction const quand on fait d1.Unefonction();? de manière caché?

[Jean-Marc.Bourguet]

il n'y as d'autre façon pour obliger l'appel, quand c'est possible, de la fonction const quand on fait d1.Unefonction();? de manière caché?

C'est quoi "quand c'est possible?"

Il n'y a pas de surcharge sur le type du resultat sauf a jouer avec des choses comme introduction d'un proxy.

[yan]

C'est quoi "quand c'est possible?"

en prenant l'exemple de scanline de QImage.


et que je fait cela

Code :

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

int dif = myImage.ScanLine ( i )[0] - myImage2.ScanLine ( i )[0];

avec myImage et myImage2 non const.
L'appel a la fonction const serait plus logique car ce code ne les modifie pas.

[Jean-Marc.Bourguet]

Tu veux donc une surcharge resolue sur le type de retour, ce qui n'est pas possible en C++ sauf a jouer avec des proxys et autres conversions implicites.

[yan]

Tu veux donc une surcharge resolue sur le type de retour, ce qui n'est pas possible en C++ sauf a jouer avec des proxys et autres conversions implicites.

ok, merci.

[JolyLoic]

seulement, dû au COW utilisé par Qt, la version const est plus rapide (pas de deferencement car const).

[Mode sarcastique]
Je croyais pourtant que le COW de Qt n'avait que des effets positifs sur les perfs
[/mode]

Plus sérieusement, si le COW a comme objectif principal de gérer les gens qui oublient de passer les paramètres par références constantes, mais qu'en contrepartie, il demande de devoir remplacer du code comme :

Code :

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

int dif = myImage.ScanLine ( i )[0] - myImage2.ScanLine ( i )[0];

Par :

Code :

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

1
2
3
QImage const &constImage = myImage;
QImage const &constImage2 = myImage2;
int dif = constImage.ScanLine ( i )[0] - constImage2.ScanLine ( i )[0];

Je ne suis pas certain qu'on y ait vraiment gagné en lisibilité.

[yan]

[Mode sarcastique]
Je croyais pourtant que le COW de Qt n'avait que des effets positifs sur les perfs
[/mode]

ben non ce serait trop facile (c'est même le contre exemple que j'avais ecrit
http://www.developpez.net/forums/d59...e/#post3555660 )
C'est d'ailleurs le gros point faible.

Plus sérieusement, si le COW a comme objectif principal de gérer les gens qui oublient de passer les paramètres par références constantes, mais qu'en contrepartie, il demande de devoir remplacer du code comme :
...
Je ne suis pas certain qu'on y ait vraiment gagné en lisibilité.

En faite j'ai pris Qt et le cow en exemple, (je préfère éviter de refaire un débat dessus). Mais la question est générale. Comme l'on peut écrire les deux, je trouvais plus jolie que la fonction const soit privilégié.

un autre exemple

Code :

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

1
2
3
4
5
6
7
8
9
 
class A
{
    std::vector<int> m_tab;
public :
    A(const std::vector<int> &ii =std::vector<int>()) :m_tab(ii){}
    std::vector<int> getI() {return m_tab;};
    const std::vector<int> & getI() const {return m_tab;};
};

getI() const à beaucoup d'intérêt à être privilégier par rapport à l'autre, tant que rien n'est modifié.

Mais c'est peut être un problème de conception...

[r0d]

Code :

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

1
2
3
4
5
6
7
8
9
 
class A
{
    std::vector<int> m_tab;
public :
    A(const std::vector<int> &ii =std::vector<int>()) :m_tab(ii){}
    std::vector<int> getI() {return m_tab;};
    const std::vector<int> & getI() const {return m_tab;};
};

getI() const à beaucoup d'intérêt à être privilégier par rapport à l'autre, tant que rien n'est modifié.

Mais c'est peut être un problème de conception...

Dans ce cas c'est différent. Et effectivement, le fait d'éviter la copie peut faire une énorme différence niveau perfs. Mais la, je ne dirais pas un "problème de conception", je dirais un problème de sémantique. Effectivement, le 1er getI, je ne l'aurais pas appelé comme ça. Puisqu'il renvoie une copie du vecteur, je l'aurais appelé un truc dans le style: GetICopy() ou GetCopyOfI(). Tu vois ce que je veux dire?

[yan]

Salut parrain.

Mais la, je ne dirais pas un "problème de conception", je dirais un problème de sémantique.

j'ai pas trouvé d'exemple autre qu'avec le COW de Qt...

Effectivement, le 1er getI, je ne l'aurais pas appelé comme ça. Puisqu'il renvoie une copie du vecteur, je l'aurais appelé un truc dans le style: GetICopy() ou GetCopyOfI(). Tu vois ce que je veux dire?

Un get n'est pas censé permet la modification interne d'une variable, non?

Ce que je veut dire, c'est que j'ai l'impression qu'une fonction const est potentiellement plus rapide, car moins besoin de test et de contrôle, qu'une fonction non const. D'où la privilégier dés que possible..

C'est ce qui se passe pour Qt. Les version const sont plus rapide car il n'y as pas de deferencement.

[r0d]

Un get n'est pas censé permet la modification interne d'une variable, non?

Non effectivement. Mais là on retombe sur un débat qui revient fréquemment: comment nommer un accesseur? Et sur ce point, de ce que j'ai vu, les avis divergent. Personnellement, je n'utilise quasiment plus de Get, précisément pour la raison que je viens de montrer: un Get()* n'est pas assez explicite à mon goût.

Du coup, je ne sais pas s'il y a vraiment de réponse à ta question. Comme le dit Loic, sans passer par un proxy, tu ne peux pas forcer une surcharge sur le type de retour. Donc pour moi, la meilleure solution consiste à ne pas surcharger, c'est à dire à changer le nom de l'accesseur. Mais bon, c'est mon avis, et je sais que tout le monde n'est pas d'accord. Il serait d'ailleurs intéressant d'avoir d'autres avis.


* aujourd'hui, le seul cas où j'utilise un Get, c'est dans le cas d'un variable de type simple (int, char, float...) et si une ou les deux conditions suivantes sont vérifiées:
. Je dois effectuer une opération supplémentaire (en plus de retourner la variable), comme par exemple une vérification.
. Cette variable ne doit à aucun prix être modifiée de l'extérieur (autrement dit, pas de set() )