Discussion :

[ternel]

De toute façon, passé le main, il n'y a pas de différence entre bibliothèque et programme.

Les deux sont composés de fonctions et de classes, ainsi que de templates (de fonctions ou de classes).
Dans l'absolu, tout est groupé dans des namespaces, chacun pouvant devenir une bibliothèque à l'occasion d'une réutilisation.

Certes, certaines sont plus spécifiques. Mais pas forcément plus qu'une bibliothèque de physique quantique.

[Jean-Marc.Bourguet]

Disons que me dire que c'est un "réel et excellent" argument ne suffira pas à me convaincre. Il en faudra plus. J'ai porté des programmes en 64 bits sans souci, et sans auto...

Un port en 64 bits est quand meme particulier. Ca fait 20 ans qu'on sait ce qu'il faut faire pour ecrire du code qui compile en 32 et en 64 bits sans problemes et sans changement. Donc tous les changements a faire sont soit du a du code vieux, soit du a du code ecrit par des personnes pas au courant des bonnes pratiques de ce point de vue (ce qui tient a de l'incompetance les dix dernieres annees). Etre capable de faire la meme chose pour un changement de structure de donnees plus arbitraire, c'est appreciable (je ne compte plus les scripts que j'ai ecrit pour faire des changements qui n'auraient pas ete necessaires avec auto, et c'est sans compter les cas ou je l'ai fait a la main parce que ca ne vallait pas la peine d'ecrire un script)

[white_tentacle]

Une bibliothèque (comme la STL) a pour vocation d'offrir de multiples services, en espérant répondre à l'ensemble des demandes. Une application classique doit répondre à une demande précise. La philosophie de développement de ces deux types d'application n'est pas du tout le même. Et les outils du langage ne seront aussi, pas les mêmes.

C’est exactement ce genre de raisonnement contre lequel je me bats tous les jours. Une application, c’est globalement un main et des appels à une bibliothèque. L’interface / GUI fait en général partie de l’application, parce qu’il y a peu de chances qu’elle soit réutilisée en dehors de l’application elle-même (mais même ça, ça se discute, à fortiori lorsque l’application grossit), mais c’est tout.

Tout le code métier, lui, doit être dans une bibliothèque, surtout pas dans l’application elle-même. Et ce parce que tu ne sais pas à l’avance comment ton projet va évoluer.

Alors bien sûr, si tu es en SSII, que c’est le client qui paie les évolutions, tu t’en tapes qu’elles coûtent plus cher (je n’irais pas jusqu’à dire qu’ils le font exprès). Mais quand tu es dans l’édition, c’est différent.

[moldavi]

Bonjour.

Donc pour vous, développez une application "classique" comme je le mentionne, est la même chose que développer une bibliothèque.

Bon ben là, désolé, je ne sais plus quoi dire...

[gl]

Donc pour vous, développez une application "classique" comme je le mentionne, est la même chose que développer une bibliothèque.

C'est surtout que la barrière me semble très artificielle ou tout au moins ne correspond pas du tout à mon vécu.

Il y a effectivement une différence dans le livrable, je te l'accorde.
Mais en terme de code, je te suis moins.

Dans tous les projets applicatifs sur lesquels je suis intervenu (de près ou de loin), j'ai toujours eu besoin de développer du code générique, réutilisable, rendant de multiple. bref faisant intervenir ce que tu sembles classé comme du code de bibliothèque (template notamment) que ce soit sur du code utilisé exclusivement dans cette application ou partagé entre plusieurs applications (codes qui sont généralement modularisés sous forme de bibliothèque d'ailleurs).
Et à contrario, sur les projets bibliothèques, il y a d'immenses pans qui n'utilisent pas ces techniques (ne serait-ce que les tests et exemples) et de nombreuses bibliothèques adressent un besoin extrêmement précis et n'ont pas vocation à être généralistes.
Et souvent ce sont les mêmes personnes qui interviennent sur les deux types projets

Il est fort possible que dans ton domaine d'activité la séparation soit franche et la distinction très claire. Mais ce n'est pas généralisable à tous les domaines. Et dans ces domaines, développer une application ou développer une bibliothèque ne sont pas, en terme de développement, fondamentalement différents.

[white_tentacle]

Bonjour.

Donc pour vous, développez une application "classique" comme je le mentionne, est la même chose que développer une bibliothèque.

Bon ben là, désolé, je ne sais plus quoi dire...

En fait, je crois que je ne sais pas ce qu’est une application « classique », au-delà des applications jouet.

Je ne crois pas un seul instant qu’une application un tantinet conséquente soit si spécifique qu’aucun de ses composants ne soit réutilisable dans un autre projet. La seule chose qui se rapprocherait de ça, c’est pour moi la couche d’interface. Bien sûr, il y a une certaine lourdeur à tout sortir du code de l’application, et bien sûr, ça ne se justifie pas toujours pour tout. Mais généralement, tu y gagnes à terme.

[moldavi]

Bonjour gl.

C'est surtout que la barrière me semble très artificielle ou tout au moins ne correspond pas du tout à mon vécu.
Il y a effectivement une différence dans le livrable, je te l'accorde.
Mais en terme de code, je te suis moins.

Je vais essayer d'éclaircir mon raisonnement.

Dans tous les projets applicatifs sur lesquels je suis intervenu (de près ou de loin), j'ai toujours eu besoin de développer du code générique, réutilisable, rendant de multiple. bref faisant intervenir ce que tu sembles classé comme du code de bibliothèque (template notamment) que ce soit sur du code utilisé exclusivement dans cette application ou partagé entre plusieurs applications (codes qui sont généralement modularisés sous forme de bibliothèque d'ailleurs).

Au moins, avec toi j'ai l'impression que tu comprends le sujet et le fond de ma pensée sur les templates. Cela fait plaisir, car j'étais prêt à lâcher l'affaire au vu des derniers messages.

En lisant cette phrase, ma première impression a été, mais est-ce que tu réinventes la roue ?

Et à contrario, sur les projets bibliothèques, il y a d'immenses pans qui n'utilisent pas ces techniques (ne serait-ce que les tests et exemples) et de nombreuses bibliothèques adressent un besoin extrêmement précis et n'ont pas vocation à être généralistes.
Et souvent ce sont les mêmes personnes qui interviennent sur les deux types projets

Je parle évidemment des bibliothèque type STL, des template et de leur technicité. Je pense que mes précédents messages sont clairs là-dessus. Vous pensez vraiment que je ne sais pas qu'une bibliothèque peut faire quelque chose de très précis, sans templates ?

Il est fort possible que dans ton domaine d'activité la séparation soit franche et la distinction très claire.

Je ne vais donner que deux exemples, le développement de jeux vidéo et le décodage/encodage vidéo. Je ne pense pas que ce soit deux domaines informatiques triviaux.

Par exemple, tu développes une application qui décode du mp4. Tu penses vraiment que si tu "templatises" ton programme, cela va décoder tous les formats vidéos... Je peux t'assurer que cela sera une perte de temps.

Mais ce n'est pas généralisable à tous les domaines.

Je suis d'accord, ce n'est pas généralisable. Donc pourquoi j'utiliserais les templates, si je n'en ai pas besoin ? J'utilise le C++ pour mes besoins. Qu'il fasse plus c'est formidable, mais ce n'est pas parce qu'il y des templates que je suis obligé de les utiliser. Et c'est la force du C++. Il couvre plusieurs besoins. Ce que je ne comprends pas trop, c'est : il y a des templates en C++, alors il faut les utiliser, sinon tu es mauvais. Il y a auto, alors il faut les utiliser, sinon tu es mauvais. Pour moi clairement non, on peut utiliser un seul pan du C++, sans être mauvais.

Et dans ces domaines, développer une application ou développer une bibliothèque ne sont pas, en terme de développement, fondamentalement différents.

Lorsque tu développes une bibliothèque comme string (d'ailleurs je me demande pourquoi en 2014 je suis obligé de spécifier wstring lorsque je suis en Unicode). Une telle bibliothèque essaie de répondre à des besoins connus, mais aussi anticipés. L'état d'esprit au niveau du développement, c'est que la bibliothèque réponde à des demandes connues et même inconnues.

Lorsque tu développes une application classique, qui normalement réponds à un besoin précis, il n'y a pas ce principe d'anticipation. Une application classique, tu sais ce que tu fais, et tu sais où tu vas. Une bibliothèque générique ne sais pas où elle va. Elle espère répondre à tous les besoins. La philosophie de développement est différente et les outils du langage seront aussi différents.

[mintho carmo]

Lorsque tu développes une application classique, qui normalement réponds à un besoin précis, il n'y a pas ce principe d'anticipation. Une application classique, tu sais ce que tu fais, et tu sais où tu vas. Une bibliothèque générique ne sais pas où elle va. Elle espère répondre à tous les besoins. La philosophie de développement est différente et les outils du langage seront aussi différents.

En fait, la confusion vient de là : tu as des clients qui savent parfaitement définir leurs besoins et ces besoins n'évoluent pas dans le temps. Sans m'avancer pour les autres, je pense que ta situation est exceptionnelle, je crois qu'une grande majorité des développeurs envie ta situation et échangeraient volontiers leurs clients contre les tiens

Du coup, j'imagine que tu n'as pas besoin de faire ce conception et que tu te moques des évolutions des langages et des pratiques, puisque tu n'as pas de problèmes d'évolutivité de ton code, de maintenabilité, de fiabilité, etc. J'envie presque ta situation.

Je dois avouer que je n'ai pas la chance d'avoir de tels clients. Et en plus, je n'ai pas la chance de travailler sur du code totalement générique. Lorsque je dois modifier une classe, je suis parfois obligé de modifier en cascade plusieurs classe, réécrire les tests unitaires et d'intégration, mettre à jour la doc. Du code générique me permet de gagner beaucoup de temps. Vraiment, je t'envie.

Par exemple, tu développes une application qui décode du mp4. Tu penses vraiment que si tu "templatises" ton programme, cela va décoder tous les formats vidéos... Je peux t'assurer que cela sera une perte de temps.

J'ai quelqu'un qui travaille comme toi dans mon équipe. L'avantage, c'est que je peux jouer aux paris avec mes autres collègues : quand je tombe sur certains codes, avant même de regarder qui est l'auteur, je peux parier que je trouverais son identité. Je gagne systématiquement.

Tiens, cela me fait penser que je travaille aussi sur des codecs vidéos et audio (côté client - c'est à dire le décodage - c'est une autre équipe qui pose sur la partie serveur). Faudra que je prévienne l'équipe que finalement c'est pas une bonne idée de faire du code générique pour cela. Moi qui pensais naïvement que corriger le code pour gagner en généricité nous faisais gagner en qualité logiciel, je suis déçu. Je vais aller remettre les bugs que l'on a corrigé en faisant cela.

Au moins, avec toi j'ai l'impression que tu comprends le sujet et le fond de ma pensée sur les templates. Cela fait plaisir, car j'étais prêt à lâcher l'affaire au vu des derniers messages.

En fait, ce qui me gène dans tes propos, c'est que tu sembles inverser ton raisonnement : tu penses que les templates et plus généralement le code générique ne sert à rien dans tes cas d'application, donc tu ne les étudies pas et tes (faibles) connaissances sur le sujet te prouvent que tu as raison quand tu penses que cela est inutile.
Ou alors, j'ai mal compris tes propos et en fait tu maîtrises la programmation générique, les templates, les tenants et aboutissants des évolutions du langage, la conception "moderne" en général, et donc que tu as un avis éclairé là dessus. Et les anciens du forum, que je sais avoir une connaissance avancée du C++, se trompent complètement (je ne m'inclue pas dans les "vieux de la veille" du C++, je sais d'expérience que j'ai fait trop souvent des erreurs pour imaginer que je n'en ferais plus).

J'ai acheté "Effective Modern C++", j'espère qu'il ne parle pas trop de auto dedans, je vais être perdu sinon, je n'arriverais pas à comprendre les codes. Ou il faudra espérer qu'il y a des commentaires détaillés pour dire à quels types correspondantes les auto.
(HS : vu que Dvp aime bien CodeGears en ce moment, on va avoir une news sur ce livre, maintenant que CodeGears a publié une review dessus ?)

Bref, j'envie ta situation. Presque.

[gl]

En lisant cette phrase, ma première impression a été, mais est-ce que tu réinventes la roue ?

Quand la roue existe et qu'elle et qu'elle correspond à ce que j'ai besoin, bien sur que non.

Je parle évidemment des bibliothèque type STL, des template et de leur technicité. Je pense que mes précédents messages sont clairs là-dessus. Vous pensez vraiment que je ne sais pas qu'une bibliothèque peut faire quelque chose de très précis, sans templates ?

J'essaie surtout de comprendre pourquoi et comment tu différencies bibliothèque et application "classique" en terme de dev. Et pourquoi tu veux réserver les template aux bibliothèques type STL (et occasionnellement ce que tu appelles style STL).

Par exemple, tu développes une application qui décode du mp4. Tu penses vraiment que si tu "templatises" ton programme, cela va décoder tous les formats vidéos...

Non bien sur que templatiser ton programme ne fait pas magiquement faire en sorte qu'il va décoder tous les formats vidéos possible. Mais qu'une partie des algo soit paramétrés par des templates ne me choquerais pas.

Je suis d'accord, ce n'est pas généralisable. Donc pourquoi j'utiliserais les templates, si je n'en ai pas besoin ? J'utilise le C++ pour mes besoins. Qu'il fasse plus c'est formidable, mais ce n'est pas parce qu'il y des templates que je suis obligé de les utiliser. Et c'est la force du C++. Il couvre plusieurs besoins. Ce que je ne comprends pas trop, c'est : il y a des templates en C++, alors il faut les utiliser, sinon tu es mauvais. Il y a auto, alors il faut les utiliser, sinon tu es mauvais. Pour moi clairement non, on peut utiliser un seul pan du C++, sans être mauvais.

Mais je n'ai pas dit que tu devais absolument utiliser auto ou les templates si tu n'en as pas besoin, et je n'ai vu personne ici le dire.
Encore une fois, si j'ai réagi c'est car tu as dit que auto ne devrait pas exister (ou être limité ou boucle), que template ne devrait pas être utiliser hors de bibliothèque type STL, etc. Et avec ça je ne suis pas d'accord, ce sont des outils qui ont leur rôle et qu'il n'y a pas de raison de ne pas les utiliser lorsqu'ils correspondent à nos besoins (ni, et je suis d'accord avec toi, d'absolument les utiliser lorsque ce n'est pas ce dont tu as besoin, mais je n'ai jamais prétendu le contraire ni vu personne le préconiser)

Bref, mon intervention consiste simplement à dire que je ne partage pas ton avis de rejeter à priori tel ou tel outil à priori ni de limiter arbitrairement tel autre à un cadre particulier. Si tu n'en as pas besoin, tu as raison de ne pas les utiliser, mais ce n'est pas une raison de prétendre que d'autres ont tort de les utiliser.

Lorsque tu développes une bibliothèque comme string (d'ailleurs je me demande pourquoi en 2014 je suis obligé de spécifier wstring lorsque je suis en Unicode). Une telle bibliothèque essaie de répondre à des besoins connus, mais aussi anticipés. L'état d'esprit au niveau du développement, c'est que la bibliothèque réponde à des demandes connues et même inconnues.

Lorsque tu développes une application classique, qui normalement réponds à un besoin précis, il n'y a pas ce principe d'anticipation. Une application classique, tu sais ce que tu fais, et tu sais où tu vas. Une bibliothèque générique ne sais pas où elle va. Elle espère répondre à tous les besoins. La philosophie de développement est différente et les outils du langage seront aussi différents.

Déjà je ne suis pas d'accord avec l'hypothèse qu'une bibliothèque ne sait pas où elle va. Que tu ne connaisses pas à priori tous les cas d'utilisation, je suis d'accord, mais tu sais où tu vas (outu vas dans le mur).
Mais surtout je ne vois pas en quoi ça change fondamentalement les outils que tu utilises. Dans mes applications, bien que je connaisse la finalité de celles-ci, il m'arrive d'utiliser des templates car j'ai besoin d'un algo ou d'un conteneur particulier (et non présent dans la STL, boost ou une autre bibliothèque du même type) fonctionnant sur différents types, de paramétrer un comportement via une classe de politique tout comme il m'arrive d'utiliser auto car je n'ai pas besoin de connaitre le type précis (et me facilite dans ce cas la maintenance) et bien d'autres pratiques.
Et surtout il m'arrive de développer des modules de l'application sous forme de bibliothèques génériques afin de les réutiliser et de les partager dans d'autres produits

Ce n'est pas le fait de développer une application ou une bibliothèque qui guide le choix des outils que j'utilise, c'est le problème que j'ai à résoudre et le point de compromis que je cherche à atteindre lors de cette résolution.

[JolyLoic]

Ce que je ne comprends pas trop, c'est : il y a des templates en C++, alors il faut les utiliser, sinon tu es mauvais. Il y a auto, alors il faut les utiliser, sinon tu es mauvais. Pour moi clairement non, on peut utiliser un seul pan du C++, sans être mauvais.

Je vais répondre à ce point uniquement :
Je ne pense pas qu'auto et les templates soient au même niveau :
Les templates sont un outil de conception, ils sont très adaptés pour certaines situations, et beaucoup moins pour d'autres. Il faut donc sans cesse se poser la question est-ce que dans ce bout de code, les templates amélioreraient ou pas ma conception (et je suis convaincu qu'un simple critère bibliothèque/application est bien trop simpliste, et que template ne signifie pas généricité à 200% partout, qu'un même code peut avoir différents niveaux de généricité, et que certains niveaux ont de l'intérêt jusque dans le main).

Auto est un outil d'écriture de code, qui ne joue pas sur la conception. Il est donc de portée plus large, dans l'ensemble du code.

Alors certes, on peut écrire du bon code sans auto, et du mauvais avec. Mais je pense qu'en général, du bon code sera encore amélioré si on utilise auto dedans.

[Jean-Marc.Bourguet]

Je vais essayer d'éclaircir mon raisonnement.

Je ne suis pas encore intervenu sur ce point, en autre parce que tu veux n'est pas très clair.

Je parle évidemment des bibliothèque type STL, des template et de leur technicité.

Les templates, c'est un outil. Un partie de la bibliothèque standard consiste à offrir des outils pour faire d'autres outils. Oui c'est technique, oui effectivement il y a pas mal de cas où on n'a pas besoin de la même technicité.

Je pense que mes précédents messages sont clairs là-dessus. Vous pensez vraiment que je ne sais pas qu'une bibliothèque peut faire quelque chose de très précis, sans templates ?

Pour moi, la dichotomie bibliothèque/programme principal n'est pas pertinente pour savoir quel genre de code je veux écrire et quelle techniques je vais mettre en oeuvre. J'ai l'impression que pour toi elle est pertinente et je me demande quelles sont les caractéristiques que tu leur associes qui les rendent pertinentes.

Je ne vais donner que deux exemples, le développement de jeux vidéo et le décodage/encodage vidéo. Je ne pense pas que ce soit deux domaines informatiques triviaux.

Par exemple, tu développes une application qui décode du mp4. Tu penses vraiment que si tu "templatises" ton programme, cela va décoder tous les formats vidéos... Je peux t'assurer que cela sera une perte de temps.

Templatiser quelles fonctions, quelles classes, sur quels paramètres?

Je suis certain que je veux rendre le plus possible de mon code indépendant des codecs. Après, le C++ offre deux techniques pour avoir du polymorphisme: les templates, les classes avec des fonctions virtuelles. Le choix de l'une ou l'autre (y compris le choix possible et courant de l'une et l'autre) va se faire sur une série de critères (de la faisabilité technique -- les versions du polymorphisme paramétrique et du polymorphisme d'inclusion du C++ ont leurs particularités et n'interagissent pas de la même manière avec tous les aspects du langages -- à des aspects beaucoup plus terre à terre -- avec quoi l'équipe qui doit faire le développement est le plus à l'aise?).

Donc pourquoi j'utiliserais les templates, si je n'en ai pas besoin ?

Parce que le fait que tu puisses faire sans ne veut pas dire que ce n'est pas la meilleure approche.

Ce que je ne comprends pas trop, c'est : il y a des templates en C++, alors il faut les utiliser, sinon tu es mauvais. Il y a auto, alors il faut les utiliser, sinon tu es mauvais.

Ce qui rendrait mauvais, c'est le refus de considérer l'utilisation d'auto, des templates, ... Tes arguments sont très proches de "J'ai jamais fait autrement, j'ai l'habitude de mes techniques, je ne vois pas pourquoi j'en considérerais qu'autres."

Lorsque tu développes une bibliothèque comme string. Une telle bibliothèque essaie de répondre à des besoins connus, mais aussi anticipés. L'état d'esprit au niveau du développement, c'est que la bibliothèque réponde à des demandes connues et même inconnues.

Et suivant l'inventaire des besoins, on choisit parmi les techniques disponibles celles qui permettent d'y répondre au mieux. Note: la templatisation de string a déjà été citée comme un cas de templatisation prématurée compliquant les choses pour pas grand chose.

Lorsque tu développes une application classique, qui normalement réponds à un besoin précis, il n'y a pas ce principe d'anticipation. Une application classique, tu sais ce que tu fais, et tu sais où tu vas. Une bibliothèque générique ne sais pas où elle va. Elle espère répondre à tous les besoins. La philosophie de développement est différente et les outils du langage seront aussi différents.

Et suivant l'inventaire des besoins, on choisit parmi les techniques disponibles celles qui permettent d'y répondre au mieux. Et on peut avoir dans une application le besoin de traiter de la même manière différent types. J'ai déjà utilisé dans du code purement applicatif des templates parce que je considérais que les alternatives répondaient moins bien aux besoins.


Oui, les besoins de certaines bibliothèques sont tels que les templates font souvent plus souvent partie de la solution que dans du code plus applicatif, mais refuser de considérer les alternatives dans les bibliothèques, comme refuser de considérer les templates dans le code applicatifs, ça tient à un dogmatisme qui n'est pas sain.

---

Ceci mériterait sa propre discussion.

d'ailleurs je me demande pourquoi en 2014 je suis obligé de spécifier wstring lorsque je suis en Unicode

1/ Je ne comprends pas pourquoi wstring plutôt que string te gène, je vois mal comment changer fondamentalement les choses sans utiliser de nouveaux noms.

2/ Les choix de bases du système de locale ont été fait avant le milieu des années 90. C'est presque un cas d'école de normalisation trop hâtive, ces choix ont été faits en fonction de critères qui pour une bonne partie ne sont plus d'actualités ce qui rend le résultat mal adapté à la situation actuelle.

3/ Personne ne considère ça comme suffisamment important pour proposer sérieusement une alternative. Beaucoup de "il faudrait" pas de volontaires pour faire le travail (et la normalisation, c'est une affaire de volontaires).

[Flob90]

Quelqu'un sait pourquoi le prochain standard n'autorisera pas l'utilisation des concepts pour la déclaration des variables ?

Pour situer un peu, lorsqu'on aura les concepts, disons un concept C, on devrait pouvoir faire :

Code :

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

1
2
3
 
void foo(C&& c)
{ /*stuff on c*/ }

qui sera "équivalent" (si je me trompe pas) à :

Code :

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

1
2
3
4
 
template<class T>
void foo(T&& c) requires C<T>
{ /*stuff on c*/ }

(c'est à dire que le type T respecte le concept C)

Pourquoi ne pas avoir autorisé :

Code :

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

1
2
 
C v = make_//...

Qui aurait le même sens qu'un :

Code :

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

1
2
 
auto v = make_//...

Avec la contrainte "le type déduit doit respecter le concept C".

L'application typique que je vois est un truc du genre :

Code :

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

1
2
 
Iterator it = //stuff

Qui est sémantiquement plus parlant qu'un :

Code :

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

1
2
 
auto it = //stuff

Où c'est la documentation/les commentaires qui viennent indiquer la sémantique qu'on attend du type de it. A l'heure actuelle, si j'utilise mon it comme un itérateur alors qu'au final ce n'en est pas un, le compilateur me l'indiquera comme il le peut, si on avait la contrainte d'un concept l'erreur serait clair : "deduced type for it failed on requirements of Iterator concept" (ou un truc dans cette idée).

[JolyLoic]

Quelqu'un sait pourquoi le prochain standard n'autorisera pas l'utilisation des concepts pour la déclaration des variables ?

Je n'étais pas là à toutes les discussions autour du sujet, donc ce que je dis est à prendre avec des pincettes.

Il y a deux façons de dire que le standard ne l'autorise pas :
- Ça a été proposé, défendu, analysé, voire implémenté, et finalement rejeté. Il est donc possible d'expliquer pourquoi ce n'est pas autorisé.
- Ça n'a pas encore été proposé sérieusement

Je pense qu'ici, on est plus dans le second cas. Cette notation a été évoquée sous forme d'extension possible dans les premières versions des papiers sur les concepts-lite (en particulier autour de la terse notation). Mais elle ne fait pas partie des papiers définissant formellement les concepts lite. Et je n'ai encore jamais vu quelqu'un vraiment proposer cette extension (bien qu'elle fasse régulièrement surface dans les mails).

[Flob90]

Dans le document de la proposition actuelle (n4333) cette fonctionnalité est sous l'appellation "Constrained type specifiers" (je vais pouvoir chercher avec le terme terse notation que tu viens de me donner pour trouver plus d'information) et la formulation se retrouve obligé d'exclure certains cas :

A constrained-type-specifier can appear in many of the same places as the auto type-specifier,
is subject to the same rules, and has equivalent meaning in those contexts.

Note: Unlike auto, a constrained-type-specifier cannot be used in the type of a variable declaration
or the return type of a function.

En tant qu'exception à une règle, elle ne doit pas exister pour rien (je vois mal un auteur prendre le temps d'écrire un note sans se demander pourquoi elle est là).

L'utilisation des concepts dans les declarators est aussi réservés aux fonctions, mais dans ce cas l'exception me semble plus naturelle à cause de la présence éventuelle d'un initializer dans le cas des variables, qui pose peut-être un problème pour la syntaxe :

Code :

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

1
2
 
auto v requires C<decltype(v)> = //...

Me semble logique, mais c'est loin d'être évident qu'il n'y a pas d’ambiguïté syntaxique.

Du coup je me demande si ce n'est pas pour éviter d'avoir une possibilité pour une syntaxe (autorisation de la terse notation pour les variables) et pas pour l'autre (interdiction du requires pour les variables).

[JolyLoic]

Dans le document de la proposition actuelle (n4333) cette fonctionnalité est sous l'appellation "Constrained type specifiers" (je vais pouvoir chercher avec le terme terse notation que tu viens de me donner pour trouver plus d'information) et la formulation se retrouve obligé d'exclure certains cas :

En tant qu'exception à une règle, elle ne doit pas exister pour rien (je vois mal un auteur prendre le temps d'écrire un note sans se demander pourquoi elle est là).

Je me suis peut-être mal exprimé : Oui, cette possibilité est explicitement exclue. Mais ça n'est pas signe qu'on ne veut pas l'avoir, juste signe que :
- Elle ne coule pas forcément de source de manière 100% évidente
- Personne ne l'a pour l'instant assez défendue
Ça ne signifie pas qu'il y a des problèmes insurmontables à l'ajouter.

C'est une différence entre les papiers initiaux proposant une idée et les papiers avec un formulation en standardese : quand une voie est juste suggérée, mais pas explorée en détails dans un papier initial, il faut qu'elle soit explicitement exclue dans la spécification formelle, afin de ne pas laisser de trous dans le standard. Un "peut-être que..." devient alors un "NON ! (pour l'instant)".

[Jean-Marc.Bourguet]

Si j'ai bien compris (comme Loic, je suis d'assez loin cet aspect), les constraints-type-specifier sont dans cette version réservées à la contraintes de template. Ils ne sont possibles en remplacement d'auto qu'aux endroits où auto signale aussi des paramètres templates (syntaxe simplifiée des templates, generic lambda). Il me semble avoir bien vu passer l'idée qu'il était envisageable d'étendre les cas où cette substitution était possible, mais que c'était considéré comme en dehors du cadre de la proposition (qui concerne les templates, pas le reste du langage).

[moldavi]

Bonjour mintho carmo.

En fait, la confusion vient de là : tu as des clients qui savent parfaitement définir leurs besoins et ces besoins n'évoluent pas dans le temps. Sans m'avancer pour les autres, je pense que ta situation est exceptionnelle, je crois qu'une grande majorité des développeurs envie ta situation et échangeraient volontiers leurs clients contre les tiens

Le pire dans tout cela, c'est que moi aussi j'envie ta situation (en la supposant...). J'aimerai ne développer que dans un seul langage, pour un seul logiciel, et pousser à bout les possibilités du langage pour en tirer le meilleur parti. Et faire un logiciel écrit dans les règles de l'art, sans bug, testé dans tous les sens, extensible à souhait, enfin bref le logiciel parfait. Chose qui n'existe plus depuis qu'une certaine fusée s'est coupée en deux en plein vol, malheureusementl...

Je fais du logiciel jetable et du logiciel pérenne. Mais je fais les deux en même temps. Ce n'est pas le cas de figure ci-dessus. Je ne pense être pas dans une situation exceptionnelle. Je connais deux dévelopeurs indépendants qui font du C++, du C#, du php, du Unity3D, des shaders, etc... Ils n'ont pas le temps d'ajouter les dernières améliorations du C++ à leur arc. Ils doivent capitaliser leurs connaissances. Alors je ne sais pas combien il y a de développeurs indépendants dans cette situation, mais je n'irai pas jusqu'à dire que nos situations sont exceptionnelles. j'ai lu beaucoup de témoignages ici, de développeurs travaillant en SSII qui changent de mission comme de chemise. Et donc de langages et de technologies. Tu trouveras ici des messages où je prône la spécialisation. Un seul langage, quelques technos et la qualité logicielle s'en portera mieux.

Du coup, j'imagine que tu n'as pas besoin de faire ce conception et que tu te moques des évolutions des langages et des pratiques, puisque tu n'as pas de problèmes d'évolutivité de ton code, de maintenabilité, de fiabilité, etc. J'envie presque ta situation.

C'est très condensé, et presque chaque mot mériterait une réponse. Je vais juste résumer.

La dernière fois que j'ai réécrit un programme à zéro remonte à 10 ans. Je l'ai réécrit 3 fois. C'est lorsque j'ai compris l'importance d'architecturer un programme. Maintenant, je suis plutôt sur des méthodes type "agile". Je refactorise à mort mon code, en général. Par contre le C++ m'aide beaucoup à faire des programmes viables rapidement. Et en général, pas joli à lire avant refactoring. Mais c'est une autre discussion.

Je dois avouer que je n'ai pas la chance d'avoir de tels clients. Et en plus, je n'ai pas la chance de travailler sur du code totalement générique. Lorsque je dois modifier une classe, je suis parfois obligé de modifier en cascade plusieurs classe, réécrire les tests unitaires et d'intégration, mettre à jour la doc. Du code générique me permet de gagner beaucoup de temps. Vraiment, je t'envie.

Je sens une pointe d'ironie et du sarcasme...

quand je tombe sur certains codes, avant même de regarder qui est l'auteur, je peux parier que je trouverais son identité. Je gagne systématiquement.

La personne qui m'a appris le développement, me disait que le code source d'un développeur peut révéler sa personnalité.

Tiens, cela me fait penser que je travaille aussi sur des codecs vidéos et audio (côté client - c'est à dire le décodage - c'est une autre équipe qui pose sur la partie serveur). Faudra que je prévienne l'équipe que finalement c'est pas une bonne idée de faire du code générique pour cela. Moi qui pensais naïvement que corriger le code pour gagner en généricité nous faisais gagner en qualité logiciel, je suis déçu. Je vais aller remettre les bugs que l'on a corrigé en faisant cela.

Encore de l'ironie, et pas un début de preuve/argumentation. Dommage, je reste sur ma faim. Cela m'intéresse vraiment, j'ai quelques connaissances en décodage vidéo et je suis prêt à discuter sur ce sujet.

En fait, ce qui me gène dans tes propos, c'est que tu sembles inverser ton raisonnement : tu penses que les templates et plus généralement le code générique ne sert à rien dans tes cas d'application, donc tu ne les étudies pas et tes (faibles) connaissances sur le sujet te prouvent que tu as raison quand tu penses que cela est inutile.

J'ai surtout expliqué qu'il y a plusieurs façons d'utiliser le C++, selon nos besoins. Et c'est la force du C++.

L'implémentation de string sous VS (juste un extrait):

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
 
 
_STD_BEGIN
		// basic_string TEMPLATE OPERATORS
template<class _Elem,
	class _Traits,
	class _Alloc> inline
	basic_string<_Elem, _Traits, _Alloc> operator+(
		const basic_string<_Elem, _Traits, _Alloc>& _Left,
		const basic_string<_Elem, _Traits, _Alloc>& _Right)
	{	// return string + string
	basic_string<_Elem, _Traits, _Alloc> _Ans;
	_Ans.reserve(_Left.size() + _Right.size());
	_Ans += _Left;
	_Ans += _Right;
	return (_Ans);
	}
/*
 * Copyright (c) 1992-2009 by P.J. Plauger.  ALL RIGHTS RESERVED.
 * Consult your license regarding permissions and restrictions.
V5.20:0009 */

Ce code fait bien son travail, mais c'est juste illisible. Ce code est tellement optimisé, qu'il se rapproche du BrainFuck. Histoire de gagner des ko. Une autre philosophie de développement.

Ou alors, j'ai mal compris tes propos et en fait tu maîtrises la programmation générique, les templates, les tenants et aboutissants des évolutions du langage, la conception "moderne" en général, et donc que tu as un avis éclairé là dessus. Et les anciens du forum, que je sais avoir une connaissance avancée du C++, se trompent complètement (je ne m'inclue pas dans les "vieux de la veille" du C++, je sais d'expérience que j'ai fait trop souvent des erreurs pour imaginer que je n'en ferais plus).

Mon avis éclairé rejoindra l'adage KISS. Rester le plus simple possible. Sans dire que toutes les abstractions ne sont pas d'une aide, mais qu'elles complexifient les choses malgré elles.

J'ai acheté "Effective Modern C++", j'espère qu'il ne parle pas trop de auto dedans, je vais être perdu sinon, je n'arriverais pas à comprendre les codes. Ou il faudra espérer qu'il y a des commentaires détaillés pour dire à quels types correspondantes les auto.

Je vois encore de l'ironie ici et aucune argumentation.

Bref, j'envie ta situation. Presque.

J'ai bien compris le "Presque", mais j'ai répondu au message malgré tout...

[JolyLoic]

Le pire dans tout cela, c'est que moi aussi j'envie ta situation (en la supposant...). J'aimerai ne développer que dans un seul langage, pour un seul logiciel, et pousser à bout les possibilités du langage pour en tirer le meilleur parti. Et faire un logiciel écrit dans les règles de l'art, sans bug, testé dans tous les sens, extensible à souhait, enfin bref le logiciel parfait. Chose qui n'existe plus depuis qu'une certaine fusée s'est coupée en deux en plein vol, malheureusementl...

Je fais du logiciel jetable et du logiciel pérenne. Mais je fais les deux en même temps. Ce n'est pas le cas de figure ci-dessus. Je ne pense être pas dans une situation exceptionnelle. Je connais deux dévelopeurs indépendants qui font du C++, du C#, du php, du Unity3D, des shaders, etc... Ils n'ont pas le temps d'ajouter les dernières améliorations du C++ à leur arc. Ils doivent capitaliser leurs connaissances. Alors je ne sais pas combien il y a de développeurs indépendants dans cette situation, mais je n'irai pas jusqu'à dire que nos situations sont exceptionnelles. j'ai lu beaucoup de témoignages ici, de développeurs travaillant en SSII qui changent de mission comme de chemise. Et donc de langages et de technologies. Tu trouveras ici des messages où je prônent la spécialisation. Un seul langage, quelques technos et la qualité logicielle s'en portera mieux.

C'est une des choses qui fait que je ne bosse pas en SSII, mais chez des éditeurs, où le contexte est différent.

Par contre, dans tes différents propos, j’entends 2 choses différentes un peu mélangées :
- Il n'est pas évident d'être bien formé à toutes les bonnes pratiques d'un langage (et là, je peux être relativement d'accord, même si je pense que c'est aussi en grande partie affaire de volonté)
- Certaines techniques ne servent à rien quand on fait du logiciel final, et non pas des bibliothèques ultra génériques (et là, je suis en profond désaccord)

Le problème, c'est que quelqu'un pensant le second point vrai ne va pas faire d'effort pour améliorer le premier point, et donc ne pourra pas se rendre compte que le second point est faux

L'implémentation de string sous VS (il n'y a pas tout):
[...]

Ce code fait bien son travail, mais c'est juste illisible. Ce code est tellement optimisé, qu'il se rapproche du BrainFuck. Histoire de gagner des ko. Une autre philosophie de développement.

Mais écrire du code un minimum générique ne signifie pas écrire du code comme ça !! La généricité peut améliorer la lisibilité. Exemple inspiré de vrai code que j'ai vu il y a peu :

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
class LogArgument
{
public:
  LogArgument(string name, int val);  
  LogArgument(string name, unsigned int val);
  LogArgument(string name, char *val);
  LogArgument(string name, long val);
  // Dans le vrai exemple, il y en avait encore une dizaine
private:
  string name;
  string value;
};
 
 LogArgument::LogArgument(string name, int val) :
    name(name)
{
  char valStr[100];
  sprintf(valStr, "%d", val); // Je me suis probablement planté ici, je n'utilise jamais sprintf moi-même, c'est pour donner une idée du code
  value = valStr;
}

On va remplacer tout ce code par :

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
class LogArgument
{
public:
  template<class T>
  LogArgument(string name, T &&val);  
private:
  string name;
  string value;
};
 
template <class T>
LogArgument::LogArgument<T>(string name, T &&val) :
    name(name)
{
  ostringstream oss;
  oss << val;
  value = oss.str();
}

Le code final est bien plus court, plus simple aussi, et en plus gère bien plus de cas que le code initial. Et pourquoi j'ai détaillé le coup du sprintf/ostringstream ? Parce qu'il me semble significatif d'un cercle vertueux: Si ofstream n'avait pas été conçu avec la généricité en tête (sans forcément être lui-même générique), je n'aurais pas pu l'utiliser. La première fois que tu rends un bout de code plus générique, ça ne sera peut-être pas évident, car le reste du code ne s'y prêtera pas forcément. Mais une fois les bonnes habitudes prises, ça devient plus aisé.

Mon avis éclairé rejoindra l'adage KISS. Rester le plus simple possible. Sans dire que toutes les abstractions ne sont pas d'une aide, mais qu'elles complexifient les choses malgré elles.

Mais une solution générique peut être plus simple qu'une solution non générique, généralement parce que :
- Elle évite du copier/coller/foirer
- Elle permet d'avoir un typage plus fort qui permet de trouver des bugs plus aisément

[Jean-Marc.Bourguet]

Mais une solution générique peut être plus simple qu'une solution non générique, généralement parce que :
- Elle évite du copier/coller/foirer
- Elle permet d'avoir un typage plus fort qui permet de trouver des bugs plus aisément

En passant, on ne commence pas par écrire une solution générique pour le plaisir d'écrir qqch de générique en devinant les axes de variabilités. On écrit une solution générique parce que l'on a déjà expérimenté la nécessité des axes de variabilités sur lesquels on sera générique (d'après mon expérience, les deviner, c'est comme deviner les points qu'il faut optimiser, ça se devine tellement mal qu'une approche relativement conservatrice est bénéfique).

(Et ce n'est pas la différence entre application et bibliothèque, même en restreignant bibliothèques aux bibliothèques à destination externe. Si on fait une bibliothèque générique, c'est parce que l'on sait -- par expérience, par retour des utilisateurs, par étude du marché -- qu'il y a des axes de variabilités nécessaires; les axes de variabilités non nécessaires ne font qu'apporter un complexité non justifiée).

[r0d]

En ce qui concerne la généricité, modularité, etc, certains appellent ça la viscosité d'un code: plus un code est visqueux, plus une modification fonctionnelle implique de modifications au niveau du code source. Or, dans cette histoire de viscosité, j'ai l'impression que ce qui est important c'est ce que j'appelle "la distance avec le noyau". C'est une intuition. Je m'explique.

On peut considérer une application comme un arbre hiérarchique: le main est la racine de l'arbre, tout en haut. Les fonctions utilisées dans le main seront les nœuds niveau 1, ainsi de suite jusqu'aux feuilles qui sont tout en bas.
Mais on peut aussi considérer une application comme un oignon: le main est au centre, et à chaque niveau d'indirection, on ajoute une couche à notre oignon.
Ce sont des représentations, aucune n'est meilleure que l'autre, mais la seconde est plus pratique pour moi pour vous expliquer mon histoire.

Dans une application donc, et si on la considère comme un oignon, on aura un noyau (le centre), et des couches périphériques plus ou moins éloignées de ce noyau. Modifier le code du noyau est toujours plus difficile que de modifier le code des couches extérieures.
Prenons par exemple le main suivant, qui est celui d'une application de plusieurs dizaines de milliers de lignes de code:

Code :

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

1
2
3
4
5
6
7
8
int main()
{
   auto & reader = reader_factory::create_reader();
   message current_message;
   while( reader.read(current_message))
      communication_layer::send(message);
   return 0;
}

La moindre modification de ce code va impliquer une avalanche de modifications dans toutes les couches de l'application. Alors que dans une couche très éloignée du noyau, on peut se permettre des modifications sans que cela implique cette avalanche de modifs. Par exemple:

Code :

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

1
2
3
4
5
6
7
8
struct event
{
private:
   int code;
   int id;
public:
   std::string to_string() { /* pseudocode */ std::stream s; s<<code<<id; return s.str(); }
};

Dans l'exemple ci-dessus, si on modifie le code de la fonction to_string(), ça n'aura aucune incidence sur le reste de l'application.

Ces exemples montrent que plus on est proche du noyau, plus il est coûteux de modifier le code. J'ai donc cette intuition que la généricité est importante lorsqu'on est près du noyau de l'application, mais peu rentable lorsqu'on est dans les couches externes. Par peu rentable, je veux dire qu'on risque de passer beaucoup de temps à rendre notre code générique, mais il ne sera finalement jamais utilisé.

En effet, lorsqu'un logiciel évolue, on va lui ajouter des couches. Mais on peut rarement connaître à l'avance en quoi consisteront précisément ces nouvelles couches. Il est donc inutile de perdre trop de temps à rendre fluide (par opposition à visqueux) les couches externes du code. Par contre, à chaque fois qu'on va ajouter une nouvelle couche au niveau N, il faudra vérifier la fluidité des couches que l'on couvre, celles des niveau N-1, N-2, etc...

Je ne sais pas si c'est clair... de toutes façons, si vous ne comprenez pas vous ne perdez pas grand-chose, il n'y a rien de nouveau dans ce que j'explique là, c'est juste que j'essaie de formaliser une intuition qui me taraude en ce moment.