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

[rOut]

Je parlais d'écrire des générateurs pour un nouveau CMake-like.
Bah quand tu gères 12000 variantes de MSVC pour différentes plateformes avec des petites variations + Eclipse + CodeBlocks + quelques autres backends, ça te fait forcément du code très moche et très spécifique. Que je suis ravi de ne pas avoir à écrire, c'est la force de CMake : des mecs se sont retroussés les manches pour les plonger dans la merde.

Le code est pas moche dans ce sens là, il est moche à cause de plein de trucs hardcodés qui n'ont pas lieu d'être. Ou encore de features implémentées à moitié ou d'uniformisation fait à moitié. Ils ont un gros bagage, qui permet de couvrir un panel très large de plateformes, certes, mais il n'est pas maintenu très assidument ce qui fragilise le tout.

Ecrire un nouveau CMake-like ça serait cool. J'avais commencé à faire un truc ou les makefiles seraient eux-même des fichiers C++, mais c'est peut être trop meta pour aboutir à quelque chose (j'ai quand même un proto-générateur pour ninja et le machin se bootstrap, sous Linux du moins).

[Tomaka17]

Le plus simple est d'attendre les modules prévus pour le C++32, pour voir comment le compilo pourrait interagir avec ça.

[Sp1d3r]

Les modules de C++ ? Au sens Fortran 90 du terme ? (des interfaces auto-générés à la compilation)

[rOut]

Non, c'est plutôt des precompiled headers standardisés. Par contre ça ne résoud en rien le problème de mécanisme de compilation.

[Sp1d3r]

Je voulais dire headers, mais interface c'est pas le terme français pour header ?

[Tomaka17]

Non, c'est plutôt des precompiled headers standardisés. Par contre ça ne résoud en rien le problème de mécanisme de compilation.

On pourrait par exemple imaginer un programme qui va lire toutes les déclarations "import" des fichiers du projet et qui télécharge les libs correspondantes, ça pourrait être pas mal.
C'est pas les modules qui résolvent le problème, c'est juste que je pense qu'il faut attendre les modules pour voir quel serait le système de compilation et de gestion des dépendances idéal.

---------- Post added at 22h59 ---------- Previous post was at 22h54 ----------

Les modules c'est ça : http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf (c'est une sorte de powerpoint, c'est pour ça qu'il y a parfois plusieurs slides similaires l'un après l'autre)
Et en un peu plus formel : http://www.open-std.org/jtc1/sc22/wg...2012/n3347.pdf

[rOut]

Concernant les dépendances, comment vas-tu sélectionner la bonne version ? D'ou télécharger la lib ? Quid des modules ayant le même nom (genre import core) ? Tel que Clang les implémente pour l'instant, les modules dépendent du même lookup que les entêtes via les include-path, simplement le compilo cherche un fichier module.map en plus.

Concernant la compilation, c'est pas ça qui va t'indiquer quelle ligne de commande exécuter pour compiler tel ou tel fichier, ni les dépendances entre les différents produits du processus. Je ne pense pas que les modules apportent quoi que ce soit qui ne soit pas déjà envisageable avec des entêtes du point de vue de la compilation.

Connaissant les #include, tu peux déjà déterminer assez bien quelle librairie est utilisée (un bon nombre d'entêtes classiques sont facilement identifiables).

[Sp1d3r]

Oui, c'était juste pour troll et dire que ça existe depuis le Fortran 90 en Fortran.

https://software.intel.com/sites/pro...8E91F2C73C.htm

Les modules c'est ça : http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf (c'est une sorte de powerpoint, c'est pour ça qu'il y a parfois plusieurs slides similaires l'un après l'autre)
Et en un peu plus formel : http://www.open-std.org/jtc1/sc22/wg...2012/n3347.pdf

[Tomaka17]

Disons qu'en C++ les modules sont particulièrement importants.

Dans un code C++ idéal, presque tous les paramètres de fonctions sont sous forme de templates. Sauf que ça t'oblige à tout mettre dans tes .hpp et ça fait des temps de compilation affreux (par exemple quand tu utilises boost tu passes d'une demi-seconde de compilation par fichier à 30 ou 40 secondes). Du coup personne ne fait ça.
Les modules devraient normalement éliminer ce problème, si les compilateurs ne sont pas trop bêtes.

[rOut]

Disons qu'en C++ les modules sont particulièrement importants.

Dans un code C++ idéal, presque tous les paramètres de fonctions sont sous forme de templates. Sauf que ça t'oblige à tout mettre dans tes .hpp et ça fait des temps de compilation affreux (par exemple quand tu utilises boost tu passes d'une demi-seconde de compilation à 30 ou 40 secondes). Du coup personne ne fait ça.
Les modules devraient normalement éliminer ce problème.

Faut pas déconner non plus.

[Tomaka17]

Pour les temps de compilation, j'ai pris des chiffres venant d'un vrai projet.
Ca mettait vraiment 30 à 40 secondes pour compiler. Un jour pour essayer j'ai mis en commentaire toutes les lignes qui utilisaient boost, et pouf presque instantané. Mais je ne me souviens plus de la machine que j'avais.

[rOut]

Comme d'habitude tout dépend de ce que tu utilises et de ce que tu fais.

J'ai des projets qui n'utilisent pas Boost et qui mettaient 2min par fichier à compiler. D'autres qui utilisent Boost et qui compilent en 2s.

[Sp1d3r]

Puisqu'au départ, ça parlait de CMAKE, il y en a qui ont testé Scons sur un vrai projet (et pas un toy case)?

[Tramb]

Dans un code C++ idéal, presque tous les paramètres de fonctions sont sous forme de templates.

Pour que tout soit typé par inférence de type?
J'ai pas vraiment envie que C++ devienne un sous SML/Caml, perso.
Et les lib, c'est quand même utile dans la vraie vie.

---------- Post added at 23h44 ---------- Previous post was at 23h37 ----------

Le plus simple est d'attendre les modules prévus pour le C++32, pour voir comment le compilo pourrait interagir avec ça.

Bof il faudra toujours faire des trucs meta dans un vrai projet, copier des fichiers, invoquer l'assembleur, linker, générer des link maps, stripper des trucs...
Donc il faudra un système de build.

---------- Post added 17/04/2014 at 00h00 ---------- Previous post was 16/04/2014 at 23h44 ----------

Oui, c'était juste pour troll et dire que ça existe depuis le Fortran 90 en Fortran.

Une de mes implémentations préférées, c'est les packages de Ada.
Quasiment tout bon, et ce en 83.

[Orhin]

Concernant les dépendances, comment vas-tu sélectionner la bonne version ? D'ou télécharger la lib ? Quid des modules ayant le même nom (genre import core) ?

Si l'on prend l'exemple de Maven pour Java, y'a quand même moyen d'automatiser un paquet de trucs pour les dépendances externes.

[rOut]

Tu spécifies quand même quelle version du veux de quel paquet. C'est pas déduit magiquement depuis les sources.

[Orhin]

Tu spécifies quand même quelle version du veux de quel paquet. C'est pas déduit magiquement depuis les sources.

Ah bien sur, je n'ai pas dit le contraire, mais je vois difficilement comment passer outre (enfin pas de façon simple et utilisable de façon généralisée).

[Tomaka17]

Pour que tout soit typé par inférence de type?
J'ai pas vraiment envie que C++ devienne un sous SML/Caml, perso.
Et les lib, c'est quand même utile dans la vraie vie.

C'est un peu longuet à expliquer, mais si tu veux faire du parallélisme de façon performante et propre, c'est complètement ça qu'il faut faire.

C'est pas si différent des interfaces/implémentation. La différence c'est que les interface ça s'appellera des concepts, et que les implémentations n'ont pas besoin de dire quel concept elles implémentent.

[war-p]

Bon, c'est bon j'ai trouvé pour mob soucis de directx, j'ai installé le dernier sdk datant de... Juin 2010. Oui le dernier sdk dispo est celui de windows 8.1, et j'ai l'impression que c'est un peu une coquille vide, merci Microsoft...

[rOut]

C'est un peu longuet à expliquer, mais si tu veux faire du parallélisme de façon performante et propre, c'est complètement ça qu'il faut faire.

C'est pas si différent des interfaces/implémentation. La différence c'est que les interface ça s'appellera des concepts, et que les implémentations n'ont pas besoin de dire quel concept elles implémentent.

Je veux bien un exemple concret parce que je ne vois pas du tout le rapport entre concepts et parallélisme.

[Tramb]

C'est un peu longuet à expliquer, mais si tu veux faire du parallélisme de façon performante et propre, c'est complètement ça qu'il faut faire.

C'est pas si différent des interfaces/implémentation. La différence c'est que les interface ça s'appellera des concepts, et que les implémentations n'ont pas besoin de dire quel concept elles implémentent.

Vas-y j'ai tout mon temps
Vu que tu parles de parallélisme, je pense que tu veux faire un peu de programmation fonctionnelle pure en C++, c'est ça? D'où ma référence à ML (qui n'est pas si pur que ça).
Mais même si tout le monde est d'accord que le code stateless permettrait de leverager du parallélisme depuis la nuit des temps programmatoires, on attend toujours une implémentation pratique et efficace de ce fait.
Ça plus le fait qu'il faut embarquer un runtime conséquent pour faire ce genre de chose, ce qui n'est pas vraiment dans l'esprit C++. Ou alors embarquer un framework bien bien intrusif et baser tout son code dessus.
Et puis la syntaxe de C++ est bien trop moche et verbeuse pour faire du code générique généralisé. En échange, elle permet de descendre très très bas et d'écrire du code générique stateful assez performant qui itère sur des raw pointers.
Dis m'en plus, histoire de savoir si j'ai bien lu entre tes lignes.

[Tomaka17]

Quand t'as par exemple ça :

struct ObjetQuiContientDesDonnees { ... };

void faireTrucA(ObjetQuiContientDesDonnees&);
void faireTrucB(ObjetQuiContientDesDonnees&);

T'es obligé d'appeler d'abord "faireTrucA" puis "faireTrucB" l'un après l'autre.
Si tu templatise ces deux fonctions, tu peux créer un objet "ObjetQuiContientDesDonnesTransaction" ou bien un objet "TransformateurDappelsDeFonctionsEnListeDeMessages " ou bien un "ObjetQuiContientDesDonnesMaisAvecUnMutexDevantCha queAppel", passer cet objet à faireTrucA et faireTrucB, et donc paralléliser les appels.

Tu peux déjà faire ça actuellement en passant directement un objet intermediaire plutôt qu'utiliser un template, mais ça fait une perte de performance si tu veux appeler l'une des ces fonctions en single-threaded.

Tu me diras qu'avec de l'héritage c'est déjà possible, mais il y a pas mal de trucs très pratiques (les itérateurs, les callbacks, etc.) qui sont soit inutilisables soit font perdre beaucoup de perfs.

---------- Post added at 09h49 ---------- Previous post was at 08h57 ----------

D'ailleurs j'attends toujours la solution du GotW 96 à ce sujet : http://herbsutter.com/2014/01/14/gotw-96-oversharing/
Je pense qu'il va dire un truc similaire à moi pour la question #3

Et sinon je déteste la programmation fonctionnelle

[Møgluglu]

Une de mes implémentations préférées, c'est les packages de Ada.
Quasiment tout bon, et ce en 83.

Ça vient pas de Modula-2 au départ ?

[Tramb]

Fort possible, c'est la même famille après tout, mais j'en ai jamais fait.

[TiNitro]

Ça vient pas de Modula-2 au départ ?

Si, mais c'est vrai que les modules de ADA sont super propres, j'approuve.

---------- Post added at 13h08 ---------- Previous post was at 13h05 ----------

Pour les temps de compilation, j'ai pris des chiffres venant d'un vrai projet.
Ca mettait vraiment 30 à 40 secondes pour compiler. Un jour pour essayer j'ai mis en commentaire toutes les lignes qui utilisaient boost, et pouf presque instantané. Mais je ne me souviens plus de la machine que j'avais.

Si tu mets les en-têtes (oui header se traduit en Français par en-tête, logique) Boost dans les en-têtes pré-compilés, ça devrait quand même pas mettre 40 secondes de plus.

D'ailleurs, je suppose que les implémentations de modules s'inspireront pas mal de ce qui se fait avec les la pré-compilation des en-têtes.

[rOut]

Quand t'as par exemple ça :

struct ObjetQuiContientDesDonnees { ... };

void faireTrucA(ObjetQuiContientDesDonnees&);
void faireTrucB(ObjetQuiContientDesDonnees&);

T'es obligé d'appeler d'abord "faireTrucA" puis "faireTrucB" l'un après l'autre.
Si tu templatise ces deux fonctions, tu peux créer un objet "ObjetQuiContientDesDonnesTransaction" ou bien un objet "TransformateurDappelsDeFonctionsEnListeDeMessages " ou bien un "ObjetQuiContientDesDonnesMaisAvecUnMutexDevantCha queAppel", passer cet objet à faireTrucA et faireTrucB, et donc paralléliser les appels.

Tu peux déjà faire ça actuellement en passant directement un objet intermediaire plutôt qu'utiliser un template, mais ça fait une perte de performance si tu veux appeler l'une des ces fonctions en single-threaded.

Tu me diras qu'avec de l'héritage c'est déjà possible, mais il y a pas mal de trucs très pratiques (les itérateurs, les callbacks, etc.) qui sont soit inutilisables soit font perdre beaucoup de perfs.

---------- Post added at 09h49 ---------- Previous post was at 08h57 ----------

D'ailleurs j'attends toujours la solution du GotW 96 à ce sujet : http://herbsutter.com/2014/01/14/gotw-96-oversharing/
Je pense qu'il va dire un truc similaire à moi pour la question #3

Et sinon je déteste la programmation fonctionnelle

C'est clairement pas en cachant les primitives de synchronisation dans tes données que tu vas rendre ton code scalable. Tu vas peut être éviter d'avoir à prendre en compte le parallélisme dans tes algos, mais tu vas rendre ton code complètement obscur et faire appraitre des contentions impossibles à débugguer.

La clef du code scalable, et parallélisable ce sont des données immutables et/ou non-partagées, c'est tout. Tu appelles ta fonction en single thread ou multithread, ça ne change rien puisque ton input/output n'est pas partagé (ou supposé constant). C'est le principe de la programmation fonctionelle et du pourquoi elle est, en théorie, beaucoup plus adaptée au parallélisme.

[Tomaka17]

Imaginons un cas concret : un programme prend une commande de l'utilisateur, puis transmet cette commande à deux fonctions distinctes qui vont chacune écrire dans un std::ostream.

Tu ne vas pas me dire que parce que les fonctions écrivent dans le même output stream, alors on est obligé de les appeler l'une après l'autre.

Soit tu modifies les fonctions pour qu'elles renvoient les données à écrire plutôt que de les écrire directement (approche fonctionnelle), mais c'est carrément chiant pour l'écriture des fonctions en question, soit tu leur donnes un dérivé de std::ostream qui fait des écritures synchronisées.
Et si tu utilises des templates au lieu de prendre un dérivé de ostream, alors la deuxième approche est aussi carrément plus rapide que d'écrire des strings un std::vector.

[Tramb]

C'est un stream de debugging ou l'ordre d'écriture est important?
Enfin là avec deux tâches, on ne parle pas de scalabilité, de toute façon.

[Tomaka17]

L'ordre d'écriture ne peut pas être important. Le programme doit bien fonctionner même si l'une des deux fonctions démarre alors que l'autre a déjà terminé.

[Møgluglu]

Soit tu modifies les fonctions pour qu'elles renvoient les données à écrire plutôt que de les écrire directement (approche fonctionnelle), mais c'est carrément chiant pour l'écriture des fonctions en question, soit tu leur donnes un dérivé de std::ostream qui fait des écritures synchronisées.

Boaf, c'est qu'une monade ton truc.