Version imprimable
Bonsoir,
J'aurais voulu avoir votre avis sur cette question un peu paradoxale...
Boost (pour ceux qui ne connaissent pas : voir ici) est le plus gros rassemblement de bibliothèques C++. Toutefois, trouvez-vous qu'il manque des choses à Boost ?
Quelles seraient vos idées de bibliothèques ?
A vos claviers :)
Bonsoir,
De la doc en français?? Pacque les truc un peu compliqué comme spirit, j'y comprend rien. :?Citation:
A votre avis, que manque-t-il dans Boost ?
Sinon plus sérieusement, ce sont peut être des idées bêtes, voir impossibles, mais je me lance:
Les trucs qu'on arrive jamais a faire proprement soit même:
Permettre de gérer soit même les allocations/desalocations(surcharge de new merci bien)
Permettre de récupérer la pile d'appel.
Sinon un boost::bind auquel on aurait pas besoin de passer _1, _2, _3, ... c'est a dire ou l'on aurait pas besoin de connaitre le nombre d'argument de la fonction qu'on lui passe, pourrai être sympa, pour transformer des fonctions membre en fonction non membre.
Plein de trucs.
Pourquoi, tu veux implémenter des choses ?
Dans un premier temps, ça va juste être un sondage, tu sais très bien que si j'avais plus de temps j'aurais des projets intéressants en dehors de Boost :aie:Citation:
Envoyé par loufoque
J'ai entendu des gens se plaindre qu'il n'y ait pas de bibliothèque de GUI dans Boost... Vous en pensez quoi ?
Tout ce qu'il y a déjà un peu partout ne suffit pas à votre avis ? Qt, GTK+/mm, wxWidgets, FLTK, Adam & Eve d'Adobe, ...
BOOST est très complet, mais une gestion des sockets, une gestion de l'interface graphique serait bien aussi...
J'ai pas grand chose d'autre qui me vient à l'esprit
Pour moi, ce qui manque le plus dans boost, c'est de la documentation vraiment orientée débutants.
Salut,
+1Citation:
Envoyé par JolyLoic
Si l'on n'a déjà pas trop l'habitude des template, la doc est souvent indigeste et les exemples trop minimalistes...
J'aurais même tendance à rajouter "en français" car j'ai remarqué que, si la capacité de lecture de l'anglais va en s'accentuant lorsque l'on a en permanence le nez dans les docs de développeurs, il faut parfois s'accrocher très sérieusement pour comprendre, au début, alors que toute notre connaissance d'anglais peut se limiter à ce que l'on a appris en quelques années de lycée :aie:
C'est dans Boost depuis la version 1.35...Citation:
BOOST est très complet, mais une gestion des sockets [...] serait bien aussi
En effet, oui, une doc française serait pas mal, et une nouvelle version de BOOST.Spirit aussi :yaisse2:Citation:
Envoyé par loufoque
PS : Et si on traduisait la doc ? :mouarf:
Si des gens sont près à s'investir dans ce projet, je peux voir s'ils seraient d'accord ;)Citation:
Envoyé par katagoto
Et sinon, il y a Boost.Asio pour le réseau depuis la 1.35, comme l'a dit loufoque...
Ca porte mal son nom... C'est pas ma faute :mouarf:
Si non, moi je serait prêt à traduir BOOST.Spirit, ça me fera pratiquer...
Mais ça serait cool, oui :king:
Ne sont-ils pas d'accord a priori, avec la licence de boost ?Citation:
Envoyé par Alp
Pas sûr, je sais que sur BOOST.Spirit y a un copyright, mais une license...
Si mais bon, on ne sait jamais, et je procède toujours comme ça, question de principe :aie:Citation:
Envoyé par JolyLoic
Oui, et puis, c'est plus "officiel"Citation:
Envoyé par Alp
Un coypright, tu auras toujours, y compris dans le monde de l'open-source, et meme si cela tient parfois du "copyleft" ;)Citation:
Envoyé par katagoto
Par contre, mais je peux toujours me tromper sur ce point, pour être intégrée dans boost, il me semble que les différentes bibliothèques se doivent d'adopter leur licence (ou toute licence similaire, en terme de droits des utilisateurs), non :question:
Une bibliothèque Boost peut très bien dépendre d'une autre bibliothèque sous une autre licence.
Bonjour à tous,
Les notions comme l'IHM (outre la dépendance inhérente aux différentes plateforme) me semblent difficiles. Un système fenêtré avec de contrôles, une souris etc... n'épuise pas le sujet IHM. LCD petit format dans les systèmes embarqués, jeux, multimédia, téléphone sont dans d'autres façon d'aborder l'IHM. Les bibliothèques telles que citées dans un post précédent sont plus pertinentes à mon avis.
De même, un parser XML ou de quoi faire le lien entre un XSD et des classes, mais je vois pas trop comment aborder ça avec un paradigme méta-programmation.
Ce qui peut manquer et dont je me sert souvent: un framework sur les automates, un framework de singleton.
En terme de doc, ce qu'il manque (outre une doc en français), c'est un point d'entrée un peu plus globale. Car, il y a tellement de librairie, qu'on a du mal à savoir si on peut trouver une solution à son problème dedans (merci developpez d'avoir des experts qui en signalent l'existence le cas échéant lors d'une innocente question).
Avec phoenix::bind, tu peux déjà faire ça.Citation:
Envoyé par Nogane
C'est qu'il faut être familier avec des notions comme les template ou les foncteurs. Donc, boost ne s'adresse pas au débutant C++.Citation:
Envoyé par JolyLoic
Après, il y a des librairies où je me demande quelle est leur intérêt: boost::for each, boost::array (je suis pas convaincu), boost::program option (me semble pas aboutit).
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).
Boost.StateChart (il y avait une proposition Boost.FSM qui a été rejetée...)Citation:
Envoyé par 3DArchi
Ca dépend. Un débutant C++ doit savoir utiliser les templates dans les cas d'utilisations simples, comme std::vector<>, std::list<>. C'est la base.Citation:
C'est qu'il faut être familier avec des notions comme les template ou les foncteurs. Donc, boost ne s'adresse pas au débutant C++.
Les foncteurs ? Si on a eu l'occasion de sortir du mode de pensée impératif avec des langages fonctionnels, ça n'est absolument pas un problème.
Il faut juste savoir surcharger des opérateurs, c'est la chose la moins naturelle pour le but escompté, parce que c'est quand même une astuce pour faire des fonctions des valeurs à part entière en C++.
----
Après, la métaprogrammation, c'est un contournement de l'usage auquel les templates étaient prédestinés, c'est normal que ce soit difficile d'accès.
boost::for_each : tu trouves que std::for_each() est pratique à utiliser dans l'état actuel des choses ? Vu les limitations pour faire des fonctions anonymes, boost::for_each reste bien plus pratique, même si c'est à base de macros.Citation:
Après, il y a des librairies où je me demande quelle est leur intérêt: boost::for each, boost::array (je suis pas convaincu), boost::program option (me semble pas aboutit).
boost::array : ben, c'est plus pratique qu'un tableau C au sens où c'est copiable, assignable. Et on ne perd pas en performances par rapport à std::vector<>. Dans le cas de petits tableaux, c'est non négligeable.
Moi j'aimerai bien qu'il y ait une lib de log (avec un watchdog et tout le toutim, ce serait le top, mais assez utopique forcément).
Et un client/serveur SOAP, genre en adaptant gSoap, ce serait génial (parce que j'utilise beaucoup gSoap et ce n'est pas toujours la panacée).
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).
+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...
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.
Fais-la :mrgreen:Citation:
Envoyé par Klaim
Edit : comment ça bufférisée ?
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à.
Par exemple si on veut que le signal soit traité dans un deuxième thread, c'est ça ?
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.
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.
Ca me fait penser à un truc.Citation:
Envoyé par Klaim
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.
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.
des nouvelles ?
Pour la traduction ?
oui :yaisse2:
Je vais me renseigner.
Il y a quelques français/francophones sur la mailing list de Boost qui seraient intéressés. J'attends l'approbation des "patrons" :aie:
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é ?
Je maintient et signe!Citation:
Envoyé par 3DArchi
Une lib pour créer et gérer les processus !Citation:
Envoyé par Alp
L'API Windows me file des boutons…
Où je signe ? donnez moi un stylo :king:
Hop hop hop.Citation:
Envoyé par Alp
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++.
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...