Discussion :

[ac_wingless]

Plutôt que d'ajouter encore plus de choses à Boost, il vaudrait mieux élaguer, simplifier, éliminer les redondances, documenter correctement et de façon consistante. Je pense que le comité C++ le fait petit à petit, mais très très lentement.

Je pense aussi qu'il faudrait une documentation pour débutants. Non pas que Boost soit fait pour les débutants, comme dit ci-dessus, mais parce que les débutants ont besoin de ce qu'il y a dans Boost, et que malheureusement ils ont peu d'expérience pour choisir la bonne librairie, pour faire la part des fonctionnalités de base et avancées, ou pire ils sont tentés de réécrire, avec les résultats qu'on imagine (ou bien qu'on se prend en pleine tête quand on détricote un dépôt pourri par le dernier stagiaire).

[Kurisu]

+1 pour les structures de singleton.
En fait, je me sers souvent de la lib Loki (d'Andrei Alexescu) qui contient ce genre de chose, donc je n'ai pas de problème, mais ce serait un plus de l'avoir integré à Boost

Sinon, une lib de lecture XML (SAX) templatée et basée sur base_string<> et les iostream (ainsi que sur Boost.Spirit?) serait bien cool...

[Klaim]

Des libs de Singleton (une) et de Log (deux) ont été proposés au cours de l'année mais n'ont pas été acceptées (pour des raisons détaillées sur le site).
A priori des versions améliorées sont prévues pour être réentrées.

Concernant l'elagage et marge de ce qui est redondant, apparamment c'est ce qu'ils sont en train de prévoir par exemple au niveau de PhoenixV3 qui risque de devenir le nouveau Boost Lambda.

A priori sur la mailing list il y en a qui envisagent de proposer des libs concernant la geometrie, ce qui peut être utile.

Personellement je regrette juste qu'il n'y ait pas (a ma connaissance) une implémentation bufferisée de boost::signal.
Sinon pas de doléance particulière pour l'instant.

[Alp]

Personellement je regrette juste qu'il n'y ait pas (a ma connaissance) une implémentation bufferisée de boost::signal.
Sinon pas de doléance particulière pour l'instant.

Fais-la

Edit : comment ça bufférisée ?

[Klaim]

En gros au lieu que l'envoi du signal provoque immediatement l'appel des listeners, il faudrait attendre qu'une methode soit appelée pour effectuer tous les appels dans l'ordre où sont arrivés les signaux.

Un systeme d'event classique en somme. Parfois on ne veut pas traiter les signaux immédiatement quand ils sont transmis et du coup boost::signal est pas adequate dans ces cas là.

[Matthieu Brucher]

Par exemple si on veut que le signal soit traité dans un deuxième thread, c'est ça ?

[Klaim]

Hmm...oui et non : a priori ça c'est possible avec la nouvelle version qui va être en evaluation bientot (a ce que j'ai lu dans la mailing list). Peut être que ça reviens au même dans l'implementation mais j'en doute.

En fait l'idée c'est plutot de permettre de temporiser le traitement des signaux parcequ'on doit le faire dans un contexte qui n'est valide immédiatement mais plus tard dans le processus de traitement.
C'est un cas plutot "rare", je n'ai vu ça que dans des jeux. En fait dés le moment ou on veut se servir d'un system centralisé d'evenements pour "synchroniser" différents systems interdémendants ( par exemple quand on veut faire du MVC bien séparé), on ne peut pas toujours permettre l'execution des callback immédiatement quand le signal est reçu.

A priori, temporiser le lancement du signal semble equivalent a ce que je dis, du coup une sorte de wrapper marcherait peut être.
Ca implique potentiellement pas mal de souci, comme par exemple le fait que soit les signaux/events doivent être garantis de toujours être "dispos et valides" lors de leur traitement (bien plus tard que lorsqu'ils sont envoyés), soit être copiables, avec tout ce que ça peut impliquer.

Ca me fais penser aux versions bufferisés des systems d'input par exemple (DirectInput, OIS, etc) ou la faon de gérer les "messages" (potentiellement constitué de plusieurs paquets) qu'on reçoit de l'exterieur dans un systeme de network : généralement on va avoir un "buffer" qui reçoit au fur et a mesure les messages et ce n'est qu'a un moment précis où on traite ce qu'il y a dans le buffer avant de continuer le traitement.

J'imagine que c'est la même idée que quand on diffuse le signal a d'autres threads mais je suppose que la version thread_safe de signal va être "optimisée" pour le cas des threads, ce qui ne sera pas forcément suffisamment générique pour le cas ou on veut juste séparer les appels de callback du reste.

Je sais pas si je suis clair v__v;

Il se peut qu'il y ait un moyen simple d'utiliser signal de cette façon mais j'ai pour l'instant une solution (rapidement écrite) pour faire ce dont je parle qui est loin d'être idéale mais pour l'instant suffisante.

edit> Juste pour préciser, j'ai en plus un cas spécial ou les signaux/events peuvent être modifiés/retirés avant l'appel des callbacks. C'est un cas vraiment super spécial et pas courant du tout donc je suppose que c'est normal que ce genre de manipulation n'a pas été prévu dans signal.

[Alp]

Déjà, la version thread_safe de signal va contenter beaucoup de monde...

Et ce n'est pas tous les jours (bien que ça arrive de temps en temps je pense) que les gens ont besoin d'une version bufférisée... Mais tu peux toujours soumettre l'idée sur la ML et voir ce que ça donne... ?

M'enfin, ce qui est attendu pour le moment c'est un système de signal/slot qui puisse se balader de thread en thread.

[HanLee]

En fait l'idée c'est plutot de permettre de temporiser le traitement des signaux parcequ'on doit le faire dans un contexte qui n'est valide immédiatement mais plus tard dans le processus de traitement.
C'est un cas plutot "rare", je n'ai vu ça que dans des jeux. En fait dés le moment ou on veut se servir d'un system centralisé d'evenements pour "synchroniser" différents systems interdémendants ( par exemple quand on veut faire du MVC bien séparé), on ne peut pas toujours permettre l'execution des callback immédiatement quand le signal est reçu.

A priori, temporiser le lancement du signal semble equivalent a ce que je dis, du coup une sorte de wrapper marcherait peut être.
Ca implique potentiellement pas mal de souci, comme par exemple le fait que soit les signaux/events doivent être garantis de toujours être "dispos et valides" lors de leur traitement (bien plus tard que lorsqu'ils sont envoyés), soit être copiables, avec tout ce que ça peut impliquer.

[...]

Je sais pas si je suis clair v__v;

Ca me fait penser à un truc.
Je faisais un système multi-agent, une sorte d'expérience d'IA, et chaque agent réagit à des événements.

Moi aussi je ne voulais pas traiter les événements tout de suite. Je les temporisais.

En fait, je récupérais tous les événements dans un buffer, et je les traitais un par un, à chaque mise à jour de l'IA (c'est le moment où le 'slot' est exécuté).
Je mettais à jour l'IA maximum une fois par frame.

Ca ressemble vachement à ce que tu veux dire, je crois.

[Klaim]

Voilà c'est typique dans ce type de systeme, donc souvent dans les jeux.

Dans mon cas je dois aussi séparer les events d'input du joueur de leur traitement effectif, parceque le principe du jeu est qu'un module externe peut ajouter un bout de code dans la boucle principale pour "modifier" les traitements, comme par exemple annuler ou inverser les informations d'input du joueur...
Un cas quasi unique donc.

Alp> Je me pencherai sur la question plus dans le détail quand je reviendrais sur la réécriture de ma solution actuelle, parceque je vais devoir la réécrire. Mais c'est pas pour immédiatement.

[Invité2]

des nouvelles ?

[Alp]

Pour la traduction ?

[Invité2]

oui

[Alp]

Je vais me renseigner.

[Alp]

Il y a quelques français/francophones sur la mailing list de Boost qui seraient intéressés. J'attends l'approbation des "patrons"

Par contre, combien de vous seraient intéressés pour s'investir dans un tel projet ?

Il n'est ici pas question de traduire une page et d'en avoir marre. De plus, il faudra une structure qui permette d'évoluer facilement de version en version.

Il y a énormément de boulot à prévoir, soyez en conscient. Il faudrait donc des personnes motivées et consciencieuses.

Qui serait intéressé ?

[3DArchi]

Pour la traduction, je peux mettre la main à la pâte (boost.preprocessor ou boost::optional, ou boost::in place factory ou boost::spirit ou boost::iterator).

Je maintient et signe!

[Florian Goo]

Toutefois, trouvez-vous qu'il manque des choses à Boost ?

Une lib pour créer et gérer les processus !
L'API Windows me file des boutons…

[Invité2]

Où je signe ? donnez moi un stylo

[HanLee]

Il y a quelques français/francophones sur la mailing list de Boost qui seraient intéressés. J'attends l'approbation des "patrons"

Par contre, combien de vous seraient intéressés pour s'investir dans un tel projet ?

Il n'est ici pas question de traduire une page et d'en avoir marre. De plus, il faudra une structure qui permette d'évoluer facilement de version en version.

Il y a énormément de boulot à prévoir, soyez en conscient. Il faudrait donc des personnes motivées et consciencieuses.

Qui serait intéressé ?

Hop hop hop.

En plus, avant de commencer le boulot, il y a un vrai travail d'organisation ingénieresque.

Boost c'est quand même un truc énorme, alors évidemment, les taches seront partagées par plusieurs personnes.
Dans Boost, les Concepts sont importants, des techniques purement C++-iennes qui se sont fait baptisées, et il faut notamment prévoir et se mettre d'accord sur un petit lexique sur les termes utilisés, les termes qui seront ou non traduits, afin que ce soit homogène.

Ensuite, je pense qu'on peut s'attendre à ce que le reste se déroule comme pour la traduction de Thinking in C++.

[Invité2]

Euh, une question devrat-on traduire tel quel, ou peut-on rajouter des choses ?
Par exemple dans la doc de BOOST.Spirit, les entêtes ne sont précisé que peu de fois, moi je pense que ça serait bien de les préciser au début quand même...

Il faudrait également définir une convention de mise en forme...