Le topic de la programmation, string, chaînes, cuir et compagnie

[rOut]

Ouais, les générateurs de code rentrent peut être dans la catégorie metaprogrammation. Mais on utilise quand même plus souvent le terme quand au sein du langage lui-même, on manipule l'AST du programme courant.

[TiNitro]

Tu peux aussi, comme Tramb, qui n'aime pas tout ces trucs de Hippies, écrire directement 12146304367025329675766243241881295855454217088483 38231532891816182923589236216766883115696061264020 21707358352212940477825910915704116514721860295199 06261646730733907419814952960000000000000000000000 000000 dans ton code. Ce qui, avouons le, est tout de même plus lisible que factorielle<123>::value.

Ouais. Tu peux aussi écrire factorielle(123), comme un mec qu'à autre chose à foutre que de jouer avec son compilateur, et profiter des fonctions constexpr en C++

[Lazyjoe]

Ouais. Tu peux aussi écrire factorielle(123), comme un mec qu'à autre chose à foutre que de jouer avec son compilateur, et profiter des fonctions constexpr en C++

Pffff c'est quoi l'intérêt de faire du C++ si c'est pour choisir les solutions de facilité modernes ?

[TiNitro]

Awé. Pas con.

[Nattefrost]

La définition de Tramb me semble quand même mieux : métaprogrammer, c'est écrire des programmes qui manipulent des programmes.

Genre par exemple dans mon boulot j'écrit des scripts python qui réécrivent des morceaux de fortran, c'est aussi une forme de métaprog !

Ca me fait gravement penser à https://racket-lang.org/ qui est un programming programming language (un des devs avait dit ça dans une conf)

[vectra]

En lisp, y'a pas de différence de syntaxe entre le préprocesseur et le compilateur: ça permet de générer son code vraiment très facilement, une fois gérés les problèmes d'évaluation multiple et d'aliasing.

Merci pour Boost.simd, je vais regarder ça!

Sinon, du taf en traitement d'image dans l'industrie, c'est pas ce qui manque (médical par exemple). Avec des CUDA et autres derrière, ça devient plus rare mais bon.

[Møgluglu]

Ouais. Tu peux aussi écrire factorielle(123), comme un mec qu'à autre chose à foutre que de jouer avec son compilateur, et profiter des fonctions constexpr en C++

Ouep, constexpr aussi c'est de la métaprogrammation.

En lisp, y'a pas de différence de syntaxe entre le préprocesseur et le compilateur: ça permet de générer son code vraiment très facilement, une fois gérés les problèmes d'évaluation multiple et d'aliasing

Ouais mais en LISP, tu as la fonction eval, c'est cheatay.

[Tramb]

Tu peux aussi, comme Tramb, qui n'aime pas tout ces trucs de Hippies, écrire directement 12146304367025329675766243241881295855454217088483 38231532891816182923589236216766883115696061264020 21707358352212940477825910915704116514721860295199 06261646730733907419814952960000000000000000000000 000000 dans ton code. Ce qui, avouons le, est tout de même plus lisible que factorielle<123>::value.

Ce qui est génial avec le C++, c'est qu'il contient en standard le type qui peut contenir 123! donc on tient là un example tout à fait intéressant :D
J'imagine que y a des gros malins qui font du BigInt en template, avec des typelists ignoblissimes, mais la performance de ce genre de détournement doit être lamentable par rapport à du vrai code qui le fait.
constexpr est une meilleure syntaxe pour ce genre de trucs, mais, oh, miracle, on ne peut faire que des trucs triviaux dedans (pas d'allocations dynamiques).

Edit: Ah il semblerait qu'on peut faire des constexpr std::array avec des trucs compliqués (j'avais essayé y a 2/3 ans et ça chokait sur clang et gcc), ça devrait permettre de faire des trucs marrants (et inutiles, hein, je ne change pas de point de vue).
constexpr std::array<int,2> a {{ 13, 18 }};
Pour les experts en C++-puzzle, y a moyen d'écrire le constexpr de la FFT de a par exemple ?
Ah bah ui : https://github.com/pkeir/ctfft
C'est marrant on a l'impression de lire du Haskell.

[rOut]

Ce qui est génial avec le C++, c'est qu'il contient en standard le type qui peut contenir 123! donc on tient là un example tout à fait intéressant :D
J'imagine que y a des gros malins qui font du BigInt en template, avec des typelists ignoblissimes, mais la performance de ce genre de détournement doit être lamentable par rapport à du vrai code qui le fait.

Ho la la, le mec trop serieux quoi!

constexpr est une meilleure syntaxe pour ce genre de trucs, mais, oh, miracle, on ne peut faire que des trucs triviaux dedans (pas d'allocations dynamiques).

En C++14 t'as droit de faire plein de trucs en plus dans une constexpr, notamment tout sauf:

- an asm declaration
- a goto statement
- a try-block
- a definition of a variable of non-literal type
- a definition of a variable of static or thread storage duration
- a definition of a variable for which no initialization is performed.

Et bien entendu appeler une fonction non-constexpr, donc pas d'alloc dynamique. Mais les boucles c'est OK.

[Tramb]

C'est bien cool, tout ça. Bon on est pas prêts d'en faire en prod

[war-p]

Pour info on retrouve la méta programmation aussi dans d'autre langages plus mainstream, genre le java avec les annotations (je pense principalement à lombok par exemple qui est vraiment un hack pour le coup mais bon)

[rOut]

Ouais, c'est vrai que c'était bien fun le Java ou 95% du code final est en fait du code injecté par diverses librairies, histoire de palier aux limitations du langage. Genre écrire des getters / setter ça fait trop chier donc y'a qu'a faire:

@InjectGettersAndSettersPrettyPlease
class Object {
  private int blou;
  private int bop;
}

[Lazyjoe]

Tiens je viens de tester une beta du compilateur intel fortran 16.

Il m'a sorti une "catastrophic error"

[Møgluglu]

Pour les experts en C++-puzzle, y a moyen d'écrire le constexpr de la FFT de a par exemple ?
Ah bah ui : https://github.com/pkeir/ctfft
C'est marrant on a l'impression de lire du Haskell.

Je prend ça pour un compliment. Je m'attendais à bien pire que ça :

template <typename T, size_t N, size_t N_2>
constexpr
typename std::enable_if<N==N_2*2,recarr<T,N>>::type
fft_helper(recarr<T,N> v, recarr<T,N_2> rofu) {
  return cat(zipWith(sum<T>,fft_helper(condense(v), condense(rofu)),
                            zipWith(product<T>,fft_helper(condense(cshift1(v)),
                                                          condense(rofu)),
                                               rofu)),
             zipWith(sub<T>,fft_helper(condense(v), condense(rofu)),
                            zipWith(product<T>,fft_helper(condense(cshift1(v)),
                                                          condense(rofu)),
                                               rofu)));
}

Ouais, un langage fonctionnel pur n'est pas l'idéal pour programmer une FFT, mais c'est plutôt propre et pas si lourd.

En C++14 t'as droit de faire plein de trucs en plus dans une constexpr, notamment tout sauf:

Faut dire que l'absence de control-flow dans les constexpr en C++11 c'était vraiment du foutage de gueule, comment proposer une super feature et la rendre inutilisable pour autre chose que des hello world. Ah si, à initialiser des constantes virgule flottantes aussi. C'est vrai qu'il a fallu attendre 2011 pour pouvoir écrire constexpr double a = 32.0 * 52.0;

[ducon]

Faut dire que l'absence de control-flow dans les constexpr en C++11

Pas de control-flow dans les constip… heu ?

[Benav]

Ouais, c'est vrai que c'était bien fun le Java ou 95% du code final est en fait du code injecté par diverses librairies, histoire de palier aux limitations du langage. Genre écrire des getters / setter ça fait trop chier donc y'a qu'a faire:

@InjectGettersAndSettersPrettyPlease
class Object {
  private int blou;
  private int bop;
}

C'est un développeur Java qui t'a piqué ta femme ou bien ?

[rOut]

C'est un développeur Java qui t'a piqué ta femme ou bien ?

Ben je ne dis pas du mal, au contraire, je trouvais ça assez plaisant d'avoir à écrire moins de code, et finalement d'être moins emmerdé. Parce que de base faut bien avouer que Java c'est pas un langage très sucré syntaxiquement.

[vectra]

Une macro d'une ligne en C++ et c'est plié.

[Spart]

Ok merci pour vos réponses les canards . Du coup ça m'intéresse pas mal (en plus si ça embauche pas mal c'est plutôt cool), je vais regarder ça de plus prêt.

[Møgluglu]

Une macro d'une ligne en C++ et c'est plié.

#define private public

[Sp1d3r]

Ben je ne dis pas du mal, au contraire, je trouvais ça assez plaisant d'avoir à écrire moins de code, et finalement d'être moins emmerdé. Parce que de base faut bien avouer que Java c'est pas un langage très sucré syntaxiquement.

J'ai un problème conceptuel avec le fait que tout code soit du code objet, même un helloworld.

[Teocali]

Ben je ne dis pas du mal, au contraire, je trouvais ça assez plaisant d'avoir à écrire moins de code, et finalement d'être moins emmerdé. Parce que de base faut bien avouer que Java c'est pas un langage très sucré syntaxiquement.

Alors tes idées comme ça si tu pouvais te les garder et éviter de trop les rependre ça m'arrangerait j'ai déjà suffisamment de bytecode généré impossible à debugger dans mes projets pour éviter d'en rajouter, merci...

[rOut]

J'ai un problème conceptuel avec le fait que tout code soit du code objet, même un helloworld.

Ben disons qu'en java je n'avais pas beaucoup le choix. Et je suis plutôt partisan du fonctionnel finalement, y compris en C++.

Alors tes idées comme ça si tu pouvais te les garder et éviter de trop les rependre ça m'arrangerait j'ai déjà suffisamment de bytecode généré impossible à debugger dans mes projets pour éviter d'en rajouter, merci...

Bah après tout est une question de gain en terme de facilité d'utilisation vs perte en terme de compréhension au niveau du debugging. Les mecs qui codent en assembleur diront la même chose quand il s'agit de débugguer du code généré par GCC. Et pourtant les langages compilés apportent un gain et une abstraction significatifs par rapport à l'assembleur pur. De mon point de vue, pour les langages intereprétés, le gain n'est pas très clair par rapport à un laguage compilé. Mais par contre, à mon avis, la métaprogrammmation peut apporter un gain d'abstraction et de réduction du nombre de lignes de code à maintenir qui vaut le coup par rapport à des difficultés de debugging potentielles.

Tout est aussi question de contexte d'utilisation. Un générateur de getter / setter apporte un gain significatif en terme de lignes de code inutiles à écrire et chiantes à lire / maintenir par rapport au faible risque qu'il apporte en terme d'obfuscation du code. Par contre, un générateur de code de merde va clairement avoir un impact sur la chiantitude à débugguer un programme qui ne vaudra pas l'avantage de ne pas avoir à écrire le code de merde soi même. Et ça, quel que soit le langage sous-jacent.

[Tramb]

Mais pourquoi générer un getter ou un setter ?
Souvent on veut rajouter des asserts ou de la logique dedans. Ou choisir leur visibilité.
Ou juste faire chier le monde.

[TiNitro]

Pour forcer les appelants à passer par des getters / setters, comme ça le jour ou tu veux ajouter du code dedans tu peux. Si tout le monde a tapé dans le champs directement t'es mort.

[Tramb]

Pour forcer les appelants à passer par des getters / setters, comme ça le jour ou tu veux ajouter du code dedans tu peux. Si tout le monde a tapé dans le champs directement t'es mort.

Ca je suis 100% d'accord. Mais on peut les faire à la main. C'est même le moindre des problèmes d'un programme.
C'est rare d'écrire un setter dans validations d'ailleurs.
Non, pardon. Ca devrait être rare

[rOut]

Mais pourquoi générer un getter ou un setter ?
Souvent on veut rajouter des asserts ou de la logique dedans. Ou choisir leur visibilité.
Ou juste faire chier le monde.

Parce qu'en Java c'est "obligé". Je ne me souviens plus exactement, mais genre ça faisait partie des "bonnes pratiques" et sinon t'étais bon pour un warning ou un truc du genre.

Et puis je ne suis pas d'accord, la plupart du temps un getter c'est juste "getBla() { return bla; }", j'ai rarement vu d'assert dedans, et s'il y a de la logique c'est plus un getter.

[Benav]

Parce qu'en Java c'est "obligé". Je ne me souviens plus exactement, mais genre ça faisait partie des "bonnes pratiques" et sinon t'étais bon pour un warning ou un truc du genre.

Et puis je ne suis pas d'accord, la plupart du temps un getter c'est juste "getBla() { return bla; }", j'ai rarement vu d'assert dedans, et s'il y a de la logique c'est plus un getter.

La plupart du temps, le getter ne fait rien. Mais il a quand même plusieurs avantages; c'est une méthode et donc ça peut se redéfinir, tu peux mettre du lazy load dedans, des logs dedans...

[vectra]

Mais pourquoi générer un getter ou un setter ?
Souvent on veut rajouter des asserts ou de la logique dedans. Ou choisir leur visibilité.
Ou juste faire chier le monde.

Juste parce que ça évite de rajouter des lignes de code pour un contenu tellement trivial que ça en devient du bruit.
Alors oui, en effet, quand il y a du code custom dedans, ça ne marche plus. Mais quitte à faire une macro sale, on peut aussi rajouter une condition comme argument de la macro.

En pratique, c'est plutôt agréable à lire sur mes programmes. Le côté "chiant", c'est que ça élude les index de fonctions dans emacs et doxygen (je suppose), mais ça reste gérable.


Sinon oui, la classe Hello world en Java, c'est genre pénible. Mais pas autant que les programmeurs Java qui te ramènent ces "bonnes pratiques" en C. A la base, je pense qu'il doit y avoir une sémantique derrière la définition d'une classe, mais je sais que je suis vieux jeu

[Tramb]

Mon point c'est qu'un setter "par défaut" est très très très souvent insuffisant.

- - - Mise à jour - - -

Parce qu'en Java c'est "obligé". Je ne me souviens plus exactement, mais genre ça faisait partie des "bonnes pratiques" et sinon t'étais bon pour un warning ou un truc du genre.

Oui tout à fait parce que via l'introspection getXX et setXX sont des noms privilégiés pour beaucoup de framework.

Et puis je ne suis pas d'accord, la plupart du temps un getter c'est juste "getBla() { return bla; }", j'ai rarement vu d'assert dedans, et s'il y a de la logique c'est plus un getter.

Si tu fais du multithread, tu mets souvent des asserts de contrôle de thread, des locks, des asserts que tu lis tel truc si et seulement si tel autre est initialisé... Et tu veux régler des visibilités plus finement, également.