Discussion :

[Davidbrcz]

Salut.

Je viens de tomber par le plus grand des hasards sur cette page : named operators.

Il y a tous les détails sur la page, et je préfère juste poster les exemples qui sont parlant :

Code :

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

1
2
 
auto result = "Hello" <repeat> 3 <join> ", "; std::cout << result << '\n';

Code :

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

int x = 42; int y = 23; auto z = x <divmod> y; // calculates { x / y, x % y }

Code :

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

vector<int> vec{ 1, 2, 3 }; vec <append>= 4; // same as: vec = vec <append> 4;

Que pensez vous de cette approche ?
Peut elle améliorer l’expressivité du code selon vous ?

[Luc Hermitte]

C'est rigolo, mais je crains que cela trop alien pour pouvoir le proposer sur un projet maintenu par plusieurs personnes.
À la limite, une bibliothèque pourrait volontairement proposer ce genre d'interface à ses utilisateurs.

[Davidbrcz]

C'est rigolo, mais je crains que cela trop alien pour pouvoir le proposer sur un projet maintenu par plusieurs personnes.
À la limite, une bibliothèque pourrait volontairement proposer ce genre d'interface à ses utilisateurs.

C'est vrai que cest deroutant, surtout que ya pas de macro ou d'autres trucs wtf.

Mais dans le cadre de la création de bibliothèques, tu peux gagner beaucoup en expressivité en complément des opérations plus classiques .

[jblecanard]

L'idée est intéressante.

C'est dommage d'avoir un symbole instancié dans le scope pour servir d'"objet intermédiaire" comme expliqué alors que fonctionnellement, ça ne sert qu'à la compilation. On peut peut-être ruser avec des const_expr mais je suis pas sûr que ça soit aussi bon qu'un appel de fonction au niveau du code généré.

[iNaKoll]

@jblecanard : le compilateur sait inliner des foncteurs de sorte qu'il n'y ait pas de trace de l'objet dans le code généré. Les foncteurs sans état sont depuis le début (depuis la STL ? avant ?) un hack du C++ permettant de transmettre un type plutôt qu'un pointeur de fonction justement pour permettre au compilateur d'inliner le code correspondant. Donc je ne pense pas que ce soit réellement un problème si l'on compile avec optimisation au max.

Après on devrait pouvoir faire la même chose avec des expressions templates et des string template (possible avec un hack assez furieux) mais la pour le coup bonjour les logs de compilation en cas d'erreur

Edit:
J'oublie de donner mon avis sur le sujet.
Pour répondre à la question, je pense que le C++ manque cruellement de simplicité d'utilisation. Dés que l'on cherche à améliorer la lisibilité du code en créant/utilisant des bibliothèques DSEL on se retrouve avec du boost et template à gogo (proto ? phoenix ? spirit ? ublas ?).
J'aime boost et j'aime les templates d'une façon générale mais sans vouloir remettre en cause la qualité des bibliothèques de boost, je trouve que le C++ manque d'API simple et efficace et évitant au maximum les logs de compilation interminables en cas d'erreur. Le vrai problème avec ce genre de hack simple, c'est qu'il est trop simple pour se démocratiser en C++.

Il serait temps que le C++ évolue encore vers plus de simplicité :
- A quand les modules ?
- A quand des bibliothèques "python-like" en C++ ?
- A quand les concepts ?

[Davidbrcz]

Après on devrait pouvoir faire la même chose avec des expressions templates et des string template (possible avec un hack assez furieux) mais la pour le coup bonjour les logs de compilation en cas d'erreur

Tu es libre d’améliorer la chose.

Pour répondre à la question, je pense que le C++ manque cruellement de simplicité d'utilisation. Dés que l'on cherche à améliorer la lisibilité du code en créant/utilisant des bibliothèques DSEL on se retrouve avec du boost et template à gogo (proto ? phoenix ? spirit ? ublas ?).
J'aime boost et j'aime les templates d'une façon générale mais sans vouloir remettre en cause la qualité des bibliothèques de boost, je trouve que le C++ manque d'API simple et efficace et évitant au maximum les logs de compilation interminables en cas d'erreur. Le vrai problème avec ce genre de hack simple, c'est qu'il est trop simple pour se démocratiser en C++.

Je suis bien d'accord. Plus le temps passe, plus le langage s’enrichit (et se complexifie !). Et mon ressenti global est qu'on peut faire des choses vraiment géniales, mais que les fondations sont des méandres de complexité.

- A quand les modules ?

Je suis pas sur de ce que les modules veulent recouvrir. PCH généralisés? Auto génération des headers ?

Ca simplifiait le dev, et encore, je suis pas convaincu par les fichiers uniques de Java. Avoir le header permet de connaitre directement ce que fait la classe.

- A quand des bibliothèques "python-like" en C++ ?

Je connais pas, tu peux détailler ?

- A quand les concepts ?

La réponse ici : http://www.cs.ox.ac.uk/ralf.hinze/WG...des/bjarne.pdf

[therwald]

Ca simplifiait le dev, et encore, je suis pas convaincu par les fichiers uniques de Java.

Java PERMET de définir une classe en un seul fichier, C++ aussi.
Mais une bonne conception java inclus des interfaces (ou à la rigueur des classes abstraites) pour définir l'interface des classes.
Et bien travailler en C++ implique de définir des headers...

[Arzar]

- A quand les concepts ?

La réponse ici : http://www.cs.ox.ac.uk/ralf.hinze/WG...des/bjarne.pdf

Encore plus récent, ici : http://www.open-std.org/jtc1/sc22/wg...2013/n3819.pdf
C'est sorti la semaine dernière, c'est la première spécification disponible pour les concept-lite.

Sinon, pour les named operators, je trouve le hack très amusant mais jamais je n'irais utiliser ce genre de bidouille dans du code de production.

[Klaim]

De meme si je devais utiliser ce hack ca serait pour une bibliotheque specifique, la ou j'envisagerai un EDSL.