Discussion :

[dragonjoker59]

@r0d : Je me trompe peut-être, mais j'aurais dit exactement l'inverse par rapport à ton exemple : une modification du main() n'implique que lui-même. Par contre une modification de to_string, pour peu que d'autres classes (on ne sait pas où, ni quand, et c'est là l'important) utilisent son résultat dans des comparaisons ou que sais-je, l'impact peut être bien plus important (voire énorme).

[r0d]

une modification du main() n'implique que lui-même.

C'est le cas si on a conçu le main de façon suffisamment générique pour que la modification ne se répercute pas dans les autres couches.

Prenons un autre exemple, plus représentatif:

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
int main()
{
   communication_layer com;
   cout << com.read<network_com_type>() << endl;
}
 
class communication_layer
{
   public: template <typename communication_type> string read() { return communication_type::read();}
};
 
class network_com_type
{
public: static string read() { /* code here */ }
};

Ici, on voit bien que l'on a fait un effort pour que la couche communication_layer soit suffisamment générique. Alors que la fonction network_com_type::read() est statique (en terme de type). En effet, il est inutile de complexifier le code de cette fonction, de la rendre template ou autre, tant qu'on en a pas besoin.
Alors que si on a choisi cette architecture, c'est à dire le template sur communication_layer::read(), ça veut dire qu'on sait qu'on va avoir besoin de plusieurs classes de "communication" qui auront des comportements différents.

Ce que je veux dire, c'est que c'est justement parce qu'on a bien fait les choses et qu'on a rendu les classes "proches du noyau" assez générique qu'on pourra les modifier sans qu'il y ait de répercutions. Alors qu'en revanche, il est inutile de complexifier les couches éloignées du noyau avant qu'on en ait besoin.
C'est juste une façon de dire que tout ce qui touche à la généricité (template, polymorphisme, modularité, etc.) a un coût, et que ce n'est pas toujours rentable.

[white_tentacle]

Je pense comme DragonJoker, à savoir que pour moi, le main est plutôt la couche supérieure de l’oignon. Au centre, j’ai mes fonctionnalités. Mais c’est aussi et surtout parce que je considère une application principalement comme une couche d’interaction (gui, mais pas forcément) permettant d’exécuter du code métier. Et que fondamentalement, ce qui est important pour moi, c’est le code métier. Et c’est lui qui va devoir s’adapter à différents contextes (serveur web, gui, application autonome, etc).

Enfin, les templates ne sont qu’une des nombreuses manière d’arriver à ce résultat. Le polymorphisme dynamique fait aussi bien l’affaire dans beaucoup de cas (pas tous, et il a un coût), et je pense que c’était aussi un des points que voulait soulever moldavi.

[r0d]

C'est vrai qu'après réflexion, vous avez raison sur un point: les couches extérieures de l'oignon serait les couches les plus hautes du programme, puisque ce sont les plus "visibles", les plus exposées.
Et oui, la généricité ne concerne pas que les templates. Ni même le polymorphisme. J'inclus par exemple la modularité également.
Enfin, j'essaie d'être dans un cadre le plus large possible, c'est à dire que lorsque je parle d'application ou de programme, ça concerne aussi bien les applis "front-end", que les bibliothèques, les services, etc.

Mais je persiste à penser que plus on est bas dans les couches métiers, plus on va se spécialiser, donc moins on va être générique. Voyez par exemple la S(T)L: les classes exposées (les conteneurs est l'exemple typique) sont les plus génériques. Les traits, politiques et allocateurs sont déjà plus spécifiques. Ainsi de suite, jusqu'à arriver à une couche où il n'y a (presque) plus de généricité. Par exemple l'implémentation concrète de l'operateur ++ d'un iterateur c'est un simple 'jump'. Parce que pour l'instant, on en a pas besoin de plus. Mais si un jour le matériel évolue et (je dis n'importe quoi), on ne lit plus la mémoire uniquement par adresse, mais aussi par longueur d'onde (je dis vraiment n'importe quoi hein), alors il faudra ajouter une couche à l'oignon et rendre ces classes génériques.

Après, je ne suis pas sûr que l'image de l'oignon soit très pertinente finalement. Peut-être vaudrait-il mieux considérer ça comme une sorte de graphe, du genre réseau de voie ferrée, quelque chose comme ça.

[Jean-Marc.Bourguet]

Peut-être vaudrait-il mieux considérer ça comme une sorte de graphe

C'est un peu ma vision. Mais j'aime pas

• quand il y a des boucles dans le graphe
• les arcs transitifs (c'est un peu trop fort, il faudrait préciser)

[moldavi]

Bonjour white_tentacle.

Enfin, les templates ne sont qu’une des nombreuses manière d’arriver à ce résultat. Le polymorphisme dynamique fait aussi bien l’affaire dans beaucoup de cas (pas tous, et il a un coût), et je pense que c’était aussi un des points que voulait soulever moldavi.

Ce n'est pas au polymorphisme dynamique que je pensais. Plutôt à des interfaces virtuelles pures, qui peuvent remplacer le fameux T, très abstrait à la lecture. Sauf évidemment pour les types primitifs.

PS : désolé, je n'ai pas répondu à tous les messages, et il y en a beaucoup. En période de fête, c'est délicat...

[nikko34]

Enfin l'idée des templates c'est que tout soit validé à la compilation (polymorphisme statique).

Ce n'est pas trop la philosophie du C++ de forcer les objets à hériter d'interfaces abstraites. Par contre dans ton code à toi tu fais comme tu veux. Mais ça ne sert à rien de perdre du temps à refaire une librarie standard C++ à sa sauce. (enfin, même le Java s'est mis aux generics!)

[Jean-Marc.Bourguet]

Enfin l'idée des templates c'est que tout soit validé à la compilation (polymorphisme statique).

L'idée des templates, c'est d'avoir des types en paramètres. Dans un langage avec un typage plus dynamique, les templates pourraient aussi être résolu dynamiquement. (J'imagine mal comment étendre le C++ de ce côté-là).

[oodini]

Bonjour,

Cela fait quelques mois que je ne fréquente plus ce forum, car je suis contraint de travailler sur un projet en Python.
Toutefois, je devrais revenir au C++ d'ici peu, et je suis donc revenu sur ce forum, où j'ai tardivement découvert cette conversation.
En particulier le débat sur auto, sur lequel j'aurai l'outrecuidance de donner mon avis.

Quand auto est apparu dans C++11, je l'utilisais à toutes les sauces. L'attrait de la nouveauté, sans doute.
Et j'ai peu à peu restreint son usage aux boucles ; j'ai même fini par renoncer à son utilisation avec les valeurs de retour des templates (alors que je suis fan des templates, et que je dois souvent me réfréner).

Pourquoi ? Comme moldavi, je trouve ça gênant de ne pas savoir sur quoi on bosse.

J'entends bien votre discours sur : "Ce qui est important, ce sont les services proposés, pas le type réel."
Sauf que pour connaître les services proposés, il faut connaître le type...

Mon évocation de Python au début du message n'était pas anodine : j'ai été mis sur un projet Python existant.
Et ma conclusion est qu'entrer dans un code Python est beaucoup plus difficile que d'entrer dans un code C++. Par manque d'informations. Notamment du type (et aussi de la constance, mais ce n'est pas ici le débat).

Je ne suis pas contre la notion de "service proposé". Quant on utilise le polymorphisme, on dispose d'un pointeur vers une classe de base, cette classe définissant une interface. On connaît donc les services associés.
Mais promouvoir auto, c'est promouvoir le void*.

Quand je cherche à comprendre un code Python, afin d'y faire une modification, je me retrouve donc souvent à devoir lire le code des fonctions appelées pour savoir ce que je récupère, et savoir ainsi s'il y aurait éventuellement sur l'objet retourné, des membres qui pourraient m'être utiles pour effectuer des modifications sur le site appelant.

Je ne doute pas que mon esprit ait été formaté au cours des années par le typage statique de C++, mais je pense que la moitié de mon temps en Python est dépensé en effectuant le processus décrit ci-dessus.
Personnellement, je préfère qu'on me laisse une carte de visite plutôt que de qu'on me fasse sortir ma lampe UV pour trouver des traces de sperme.

Le Python est un langage génial pour le codeur solitaire, qui connaît ses fonctions. C'est un enfer pour les autres, car il est beaucoup plus difficile de connaître les intentions du codeur.
Et ce qui facilite la maintenance, c'est la connaissance des intentions des codeurs qui sont passés avant nous. Le type y participe. Le mot-clé const également.

Alors on me répond : documentation, nommage des variables, voire tests unitaires...
Toutes ces choses que les codeurs font toujours avec rigueur et bonne volonté, c'est bien connu.

Et, ce qui est assez ironique, c'est qu'est apparu dans Python un nouveau style de documentation pour pouvoir mettre le type dans la liste des arguments d'une fonction plutôt que dans sa docstring.
Cela me rappelle Java qui vilipendait l'héritage multiple et qui l'a finalement introduit dans la version 8, s'apercevant que ça manquait...

Pour en revenir au C++, je réserverai le mot-clé auto à 2 cas d'utilisation :

• boucles / itérateurs
• partout où c'est indispensable

Pour tous les autres cas où c'est simplement utile/pratique, je m'abstiens.
Car c'est une flemme qui aura un coût à la maintenance.

Le type, c'est de la doc. Jamais obsolète.

PS : votre foie gras était-il typé canard ?

[gl]

La comparaison avec python et void* me gêne. Python c'est du typage dynamique et void* relève de la faiblesse du typage. Alors que auto c'est simplement de l'inférence de type, le typage reste statique et il n'affaibli pas le typage.

[oodini]

Tu noteras que dans ma longue prose, je n'ai pris que le point de vue du codeur/relecteur de code, pas celui du compilateur.

[gl]

Tu noteras que dans ma longue prose, je n'ai pris que le point de vue du codeur/relecteur de code, pas celui du compilateur.

Oui, moi aussi. Ma remarque reste valable, le typage c'est en grande partie pour le codeur/relecteur (soit directement dans le code source, soit au travers des messages du compilateur en cas d'erreur/incohérence). Le type de la variable reste celui de sa création, il est certes infere et non déclaré mais il ne varie pas, et c'est une différence fondamentale pour le codeur/relecteur, et c'est ce qui rend la comparaison avec du typage dynamique (ou avec l'usage de void*) assez limite.

Concernant le fait de retrouver le type précis de la variable si on en a besoin (ce qui n'est systématique) : il faut regarder la déclaration de la variable, comme avec les types déclarés mais en se préoccupant de l'initialisation et non du type déclaré (qui, bien souvent, ne fait que répéter le type fournit par l'initialisation voire introduit des erreurs)

[oodini]

Le type de la variable reste celui de sa création, il est certes inféré et non déclaré mais il ne varie pas, et c'est une différence fondamentale pour le codeur/relecteur

L'inférence est aisée pour le compilateur, beaucoup moins pour relecteur. Et s'il n'y a pas d'erreur, le compilateur ne donnera pas d'info (quand on fait de la relecture de code, on peut vouloir connaître le type, même si ça compile).

Concernant le fait de retrouver le type précis de la variable si on en a besoin (ce qui n'est systématique) : il faut regarder la déclaration de la variable, comme avec les types déclarés mais en se préoccupant de l'initialisation et non du type déclaré (qui, bien souvent, ne fait que répéter le type fournit par l'initialisation voire introduit des erreurs)

Quand l'initialisation se fait dans des fonctions, on n'est guère avancé : faut aller voir le code des fonctions.

[gl]

Quand l'initialisation se fait dans des fonctions, on n'est guère avancé : faut aller voir le code des fonctions.

L'initialisation d'une variable auto peut se faire avec le retour d'une fonction mais pas dans une fonction.

Dans le cas où tu as absolument besoin de connaître le type précis d'une variable et que ce type n'est facilement déductible par le lecteur, c'est un cas où l'usage d'auto n'est pas recommandée. Mais ce n'est pas une raison pour rejeter auto ou le restreindre à 2 ou 3 cas très particuliers.
Encore une fois, je ne dis pas qu'il faut utiliser systématiquement auto, loin de là, mais je persiste à dire que le rejeter à priori, ou de le restreindre à qq cas hyper particulier s, est absurde.
Et l'argument "le type n'est pas écrit donc je n'arrive pas à lire le code" pour proscrire l'usage d'auto ne me convainc vraiment pas, surtout vu les erreurs de typage qu'auto évite (voir les messages de Loic à ce sujet)

[Médinoc]

Un des arguments purement "confort du codeur/relecteur" que j'avais vus en faveur de var(C#)/auto(C++), c'était d'éviter les répétitions lors de casts ou d'instanciations sur le tas. Le problème, c'est qu'il était surtout question de pointeurs nus à l'époque, et ce n'est pas forcément aussi pratique en C++ moderne.

[r0d]

Je pense qu'on se rendra compte de tout ça dans quelques années, lorsque certains d'entre nous auront récupéré des projets dont le code est "full auto". Parce qu'il faut voir aussi que les IDEs aident beaucoup également.
Personnellement, ça fait plusieurs années que je travaille sur le même projet, donc je ne sais pas trop, mais il m'arrive de regarder du code source juste par curiosité, et les auto ne m'ont pas encore dérangé. Mais "regarder du code par curiosité" et "maintenir du code", ce n'est pas du tout la même chose, j'en conviens.

[bacelar]

Je pense qu'on a fait le tour de l'auto.
Je me permets donc un HS sur un argument de la chapelle adverse: que JAVA est passé à l'héritage multiple.
http://www.oracle.com/technetwork/ja...w-2157071.html
Je suis un fervent réfractaire à l'héritage multiple alors qu'une évolution d'un langage le mette dans la boucle, ça m'a "froissé".
Donc, ça sort d'où cet héritage multiple en JAVA ?

[white_tentacle]

java a toujours eu l’héritage multiple, sous la forme d’héritage multiple d’interfaces. Si j’ai bien compris, java 8 rajoute la possibilité d’avoir des implémentations dans les interfaces (en somme, des implémentations par défaut). Ce n’est pas une révolution, et ce n’est pas de l’héritage multiple à la c++ (puisqu’on n’a pas le problème d’accès aux membres, les interfaces ont toujours une taille de*0).

Par contre, je ne comprends pas bien pourquoi comment on peut être réfractaire à l’héritage multiple. Ça ne sert pas souvent, mais quand tu en as besoin, tu es bien content de l’avoir. Ça crée des problèmes pour celui qui écrit le langage, et je comprends que ceux qui écrivent un langage préfèrent s’éviter ces problèmes, mais côté utilisateur, fondamentalement, ça ne change pas grand chose. C’est que du bonus.

[JolyLoic]

Donc, ça sort d'où cet héritage multiple en JAVA ?

Parce qu'ils se sont enfin rendus compte que le copier/coller de code était un fléau bien pire que l'héritage multiple, et terme de temps de développement, de temps de mise au point, de stabilité, d'évolutivité ?
Pour voir mon point de vue là dessus : http://loic-joly.developpez.com/arti...tage-multiple/ (je sais que tu connais, mais c'est pour si d'autres lisent ce message).

[Médinoc]

D'instinct, j'aurais dit que le manque d'héritage multiple n'aurait pas été un problème si on pouvait rediriger les interfaces vers un autre objet (ce que permet COM). Mais tant qu'on ne peux pas faire ça, c'est handicapant.