Template et constante

fabien.chene@gmail.com (Fabien Chêne) writes:


[...]

| > Je ne retourne pas le type de retour « T const » pour à peu près la
| > même raison que je ne déclare pas le type paramètre « T const »
| >
| > void f(T const);
| >
| > quand « T » est un type d'objet. Sauf que dans le cas de type de
| > retour, le « const » n'est pas systématiquement ignoré. Il n'est
| > ignoré que si le type T n'est pas une class. Je ne vois pas
| > l'intérêt de cette « tromperie », même si je comprends les raisons
| > avancées -- je ne les trouve pas convaincantes.
|
| Le cas de l'operator+ n'est pas le meilleur exemple.

Ah.

| Si on considère
| le cas de la surcharge de ces chers operator++(int) et operator++(),
| il est bien difficile d'admettre que ++++it; fera ce à quoi on
| s'attend, et it++++; non - it étant un itérateur de la bibliothèque
| standard par exemple.

Je n'ai pas eu affaire à des « ++++it », ni des « it++++ » dans du
code réel. Je ne dis pas que cela ne pourrait pas exister. Juste que
ce n'est pas le genre de problèmes que je rencontre dans la pratique
dans du code sur lequel j'ai travaillé de près ou de loin, ni dans
ceux de mes collègues.
J'ai cependant remarqué que cela fait partie des sujets favoris de
nombre de gens qui écrivent à propos des gens qui écrivent des
logiciels.
YMMV.

[...]

| Je trouve cet exemple ci plus convainquant, mais j'avoue que je serai
| géné de retourner «T const» pour une surcharge d'operateur, et pas
| pour un banal accesseur -- la problématique m'a l'air d'être la même.
| Finalement, je me demande aussi comment sera comprise la déclaration
| suivante par un développeur C++ moyen: T const Foo::getT() const;
| Croiras t'il qu'on ne peut définitivement pas modifier le retour de la
| fonction ?

Même les étudiants fraîchement arrivés ne pensent pas qu'ils peuvent
modifier la valeur de retour de

int Cursor::get_position() const;

ni celle de

Token Parser::current_token() const;


Peut-être que les étudiants (fraîchement arrivés) que j'ai rencontrés
ne sont pas encore arrivés au niveau moyen. (Mais on y travaille :-)

-- Gaby

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

fabien.chene@gmail.com (Fabien Chêne) writes:


[...]

| > Je ne retourne pas le type de retour « T const » pour à peu près la
| > même raison que je ne déclare pas le type paramètre « T const »
| >
| > void f(T const);
| >
| > quand « T » est un type d'objet. Sauf que dans le cas de type de
| > retour, le « const » n'est pas systématiquement ignoré. Il n'est
| > ignoré que si le type T n'est pas une class. Je ne vois pas
| > l'intérêt de cette « tromperie », même si je comprends les raisons
| > avancées -- je ne les trouve pas convaincantes.
|
| Le cas de l'operator+ n'est pas le meilleur exemple.

Ah.

Dans le sens où écrire « a + b = c » est sans doute plus révélateur qu'un
éthylotest positif :-)

| Si on considère
| le cas de la surcharge de ces chers operator++(int) et operator++(),
| il est bien difficile d'admettre que ++++it; fera ce à quoi on
| s'attend, et it++++; non - it étant un itérateur de la bibliothèque
| standard par exemple.

Je n'ai pas eu affaire à des « ++++it », ni des « it++++ » dans du
code réel. Je ne dis pas que cela ne pourrait pas exister. Juste que
ce n'est pas le genre de problèmes que je rencontre dans la pratique
dans du code sur lequel j'ai travaillé de près ou de loin, ni dans
ceux de mes collègues.
J'ai cependant remarqué que cela fait partie des sujets favoris de
nombre de gens qui écrivent à propos des gens qui écrivent des
logiciels.
YMMV.

Bah, j'ai l'impression que ces sujets sont écrits pour attirer
l'attention sur les différences -- possiblement silencieuses -- entre
opérateurs « built-in » et surcharges d'opérateur. Je ne garde en
mémoire aucun exemple en particulier qui ne collent pas vraiment avec
la réalité, j'éprouve juste une certaine méfiance pour les expressions
douteuses.


--
Fab

fabien.chene@gmail.com (Fabien Chêne) writes:

[...]

| Dans le sens où écrire « a + b = c » est sans doute plus révélateur qu'un
| éthylotest positif :-)

:-) :-)

[...]

| Bah, j'ai l'impression que ces sujets sont écrits pour attirer
| l'attention sur les différences -- possiblement silencieuses -- entre
| opérateurs « built-in » et surcharges d'opérateur.

Nous aimerions bien que les gens ne voient pas de différence :-)

Un principe (idéal) qui guide la conception de C++, c'est que les
built-in sont supportés aussi bien que ceux définis par
l'utilisateur. C'est par exemple l'une des raisons pour laquelle nous
généralisons les expressions constantes aux litéraux définis par
l'utilisateur, ou les listes d'initialisation.

-- Gaby

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

| Bah, j'ai l'impression que ces sujets sont écrits pour attirer
| l'attention sur les différences -- possiblement silencieuses -- entre
| opérateurs « built-in » et surcharges d'opérateur.

Nous aimerions bien que les gens ne voient pas de différence :-)

Un principe (idéal) qui guide la conception de C++, c'est que les
built-in sont supportés aussi bien que ceux définis par
l'utilisateur. C'est par exemple l'une des raisons pour laquelle nous
généralisons les expressions constantes aux litéraux définis par
l'utilisateur, ou les listes d'initialisation.

Ah là, j'ai un train de retard -- au sens propre ! Je lirai sans doute
ces papiers lors de mon prochain trajet en train de plus de 6 heures.

--
Fab