Discussion :

[Matthieu Brucher]

Ca y est ! La version 1.39 est sortie.

Elle est téléchargeable ici : http://sourceforge.net/project/showf...ease_id=679861

La seule nouvelle bibliothèque est signal2, une version des signaux et slots thread-safe (contrairement à la 1 ?). Dommage, PropertyTree était dans le repository, mais apparemment n'a pas fini dans la release

Bref, les release notes :

New Libraries

* Signals2: Managed signals & slots callback implementation (thread-safe version 2), from Frank Mori Hess.

Updated Libraries

* Asio:
o Implement automatic resizing of the bucket array in the internal hash maps. This is to improve performance for very large numbers of asynchronous operations and also to reduce memory usage for very small numbers. A new macro BOOST_ASIO_HASH_MAP_BUCKETS may be used to tweak the sizes used for the bucket arrays.
o Add performance optimisation for the Windows IOCP backend for when no timers are used.
o Prevent locale settings from affecting formatting of TCP and UDP endpoints (#2682).
o Fix a memory leak that occurred when an asynchronous SSL operation's completion handler threw an exception (#2910).
o Fix the implementation of io_control() so that it adheres to the documented type requirements for IoControlCommand (#2820).
o Fix incompatibility between Asio and ncurses.h (#2156).
o On Windows, specifically handle the case when an overlapped ReadFile call fails with ERROR_MORE_DATA. This enables a hack where a windows::stream_handle can be used with a message-oriented named pipe (#2936).
o Fix system call wrappers to always clear the error on success, as POSIX allows successful system calls to modify errno (#2953).
o Don't include termios.h if BOOST_ASIO_DISABLE_SERIAL_PORT is defined (#2917).
o Cleaned up some more MSVC level 4 warnings (#2828).
o Various documentation fixes (#2871).
* Flyweight:
o The refcounted component was not thread-safe due to an incorrect implementation and could deadlock under heavy usage conditions. This problem has been corrected.
* Foreach:
o Eliminate shadow warnings on gcc for nested FOREACH loops
o Portability fix for Intel-Win toolset
* Hash:
o Remove deprecated headers for hashing containers. Everything that was in them is included in <functional/hash.hpp> (#2412).
o Other minor changes, full details in the library change log.
* Interprocess:
o Increased portability and bug fixes. Full details in the library change log.
* Intrusive:
o Optimizations and bug fixes. Full details in the library change log.
* Program.Options:
o Multitoken options fixed (#469).
* Proto:
o Work around incompatibility with standard Linux header.
o Add proto::noinvoke<> to block metafunction invocation in object transforms.
* PtrContainer:
o Bug fixes from Trac applied.
* Range:
o Bug fixes from Trac applied.
* Unordered:
o Fixed regression in 1.38 that prevented unordered from using more than about 1.5 million buckets (#2975).
o Minor implementation changes, including #2756. Full details in the library change log.
* Xpressive:
o Work around for gcc optimization problem resulting in pure virtual function call runtime error (#2655).

Updated Tools

* Boostbook:
o Improved PDF generation.
o Preliminary HTMLHelp support.
o Add default path for callout images.
o Include data members' <purpose> in the class synopsis.
o Fix bug where a function's <purpose> wasn't displayed if it was just plain text.
o Support the alt tag in <headername> and <macroname>. Use this if the header or macro name is different to the contents of the tag (#1977).
o Support links relative to the boost root in <ulink> tags, using a custom url, see the linking documentation for details (#1166).
o Avoid generating filenames that only differ in case for function, method and macro documentation.
o Run the docbook chunker quietly, unless boostbook.verbose is set. This parameter might be used in other places in future releases.
o Make the 1.1 DTD available.
o Fill in some missing reference documentation (partially fixes #2153).
o Changes to doxygen integration:
+ Support \throw.
+ Support global variables and enums.
+ Better support for documentation written in function and method bodies.
+ Workaround a problem with doxygen 1.5.8's xml output (#2937).
* Quickbook:
o Return an error code and error count if there are any errors (#1399).
o Support both windows and cygwin paths at the compile line when compiled with cygwin.
o Fix some issues with C++ and Python code:
+ Fail gracefully for a mismatched ''.
+ Warn if any unexpected character are encountered and write them out properly (#1170).
+ Fix a bug for hex encoded characters in strings (#2860).
o Improved testing, including tests for expected failures.
o Generate valid document info for document types other than library (#2711):
+ Remove library specific attributes.
+ Put title before info block.
o Fix a bug when calling templates.
o Less warnings when built using gcc.
o Small documentation improvements (#1213, #2701).
o Fix a bug with xinclude pages when outdir is the current directory (#2921).

Compilers Tested

Boost's primary test compilers are:

* OS X:
o GCC 4.0.1 on Intel Tiger and Leopard
o GCC 4.0.1 on PowerPC Tiger
* Linux:
o GCC 4.3.2 on Ubuntu Linux.
o GCC 4.3.3 on Debian "unstable".
* Windows:
o Visual C++ 7.1 SP1, 8.0 SP1 and 9.0 SP1 on Windows XP.

Boost's additional test compilers include:

* Linux:
o Intel 9.0 on Red Hat Enterprise Linux
o Intel 10.0 on Red Hat Enterprise Linux
o Intel 10.1 on 64-bit Linux Redhat 5.1 Server.
o Intel 10.1 on Suse Linux on 64 bit Itanium
o Intel 11.0 on Red Hat Enterprise Linux
o GCC 4.1.1, 4.2.1 on 64-bit Red Hat Enterprise Linux
o GCC 4.1.2 on 64-bit Redhat Server 5.1
o GCC 4.1.2 on Suse Linux on 64 bit Itanium
o GCC 3.4.3, GCC 4.0.1, GCC 4.2.4 and GCC 4.3.2 on Red Hat Enterprise Linux
o GCC 4.3.2 with C++0x extensions on Red Hat Enterprise Linux
o GCC 4.2.1 on OpenSuSE Linux
o QLogic PathScale(TM) Compiler Suite: Version 3.1 on Red Hat Enterprise Linux
o GNU gcc version 4.2.0 (PathScale 3.2 driver) on 64-bit Red Hat Enterprise Linux
o Sun 5.9 on Red Hat Enterprise Linux
* OS X:
o Intel 9.1, 10.1 on Tiger
o Intel 10.1, 11.0 on Leopard
o GCC 4.2.1 on Leopard
* Windows:
o Visual C++ 9.0 on Vista.
o Visual C++ 9.0, using STLport 5.2, on XP and Windows Mobile 5.0.
o Borland 5.9.3
o Borland 6.1.0
o Intel C++ 11.0, with a Visual C++ 9.0 backend, on XP 32-bit.
o Intel C++ 11.0, with a Visual C++ 9.0 backend, on Vista 64-bit. (TODO: not recently)
o GCC 4.3.3, on Mingw
* AIX:
o IBM XL C/C++ Enterprise Edition for AIX, V10.1.0.0, on AIX Version 5.3.0.40
* NetBSD:
o GCC 4.1.2 on NetBSD 4.0/i386 and NetBSD 4.0/amd64.
* Solaris:
o Sun C++ 5.7, 5.8, 5.9 on Solaris 5.10
o GCC 3.4.6 on Solaris 5.10

Dommage aussi que certains compilateurs ne soient pas officiellement supportés (je pense aux compilateurs d'IBM et ceux de Portland Groupe, même si ces derniers ont un début de support).

[poukill]

Il serait intéressant de vérifier si les problèmes rencontrés avec MinGW sur DateTime sont encore d'actualités.

[3DArchi]

Salut,

La seule nouvelle bibliothèque est signal2, une version des signaux et slots thread-safe (contrairement à la 1 ?).

Non, la doc précisait bien que Boost.Signal n'était pas thread-safe. Cette nouvelle version est une bonne nouvelle et va certainement ouvrir de nouvelles perspectives

Il serait intéressant de vérifier si les problèmes rencontrés avec MinGW sur DateTime sont encore d'actualités.

Je ne l'ai pas encore téléchargé, mais en lisant les changements, je ne vois pas Boost.DateTime


Sinon, à part Boost.Signal 2, ce sont beaucoup de correctifs et changements mineurs. Indicateur d'une livraison trop rapide de la version précédente ?

[Matthieu Brucher]

Peut-être.
J'hésite à utiliser signal2 tout de suite à la place de Qt pour certains projets...

[hiura]

Y a-t-il un moyen de récupérer les dernières versions de boost avec apt (debianlike) ? Je ne vous que les 1.34 et 1.35.

[Matthieu Brucher]

Y a-t-il un moyen de récupérer les dernières versions de boost avec apt (debianlike) ? Je ne vous que les 1.34 et 1.35.

Non. Boost doit d'abord être packagé par les mainteneurs des distributions. Tu verras sans doute des versions plus récentes en passant en testing ou en unstable (chez Debian)

[hiura]

Ok, merci.
ça ma l'air râpé pour Ubuntu...

[LittleWhite]

Pour ubuntu, cherche sur le site de boost si tu vois pas des dépots spécials ubuntu. Debian et ubuntu n'utilise pas les même dépots, donc normalement y a une chance que tu ai des depots à jour pour ubuntu.

Par contre, il serai grand temps que je me mette à boost mais je ne sais pas trop comment commencer, il y a tellement de chose là dedans.... :s
Bien sur vous allez m'envoyer sur les pages des tutos que vous avez ecrit, merci bien, mais ne perdez pas votre temps, je les ai déjà en favoris, faut juste que je me lance dans la lecture :s

[poukill]

Je crois pas que les dépôts soient à jour pour ubuntu. Pour la 8.10, ils étaient encore à la 1.33 je crois.
Ca m'étonnerai donc !
Par contre, Ubuntu est une plateforme de test officielle, donc aucun problème à compiler boost dessus !

[Goten]

j'allais dire... pourquoi pas recompiler? C'est pas la mort non plus.

[Alp]

Je pense qu'il faudrait se mettre en Debian Experimental si tu veux voir Boost 1.38 ou 1.39, et encore...

Bien que ce ne soit pas catastrophique, les délais de mise à jour de Boost sur les dépôts Ubuntu/Debian ne sont pas idéaux.

Sinon, pas mal de corrections, peu de nouveautés, ce n'est pas plus mal je dirais. Ca permet aux bibliothèques récentes de murir un peu, et avec le Google Summer of Code qui arrive, avoir les bibliothèques existantes qui murissent pour se reposer dessus ce n'est pas plus mal

[Florian Goo]

Je suis le seul que ça choque, d'avoir une lib signals2 ?
Pourquoi ne pas avoir simplement mis à jour signals ?
Et s'il existe un intérêt de continuer à utiliser signals1 (performance pour les programmes monothreads ?), pourquoi ne pas avoir factorisé les deux implémentations et permettre le switch entre les deux avec, disons, un #define qui va bien ?

[3DArchi]

Je suis le seul que ça choque, d'avoir une lib signals2 ?
Pourquoi ne pas avoir simplement mis à jour signals ?
Et s'il existe un intérêt de continuer à utiliser signals1 (performance pour les programmes monothreads ?), pourquoi ne pas avoir factorisé les deux implémentations et permettre le switch entre les deux avec, disons, un #define qui va bien ?

Salut,
Je pense que c'est pour permettre la cohabitation des 2 dans les projets existants et/ou les phases de migration. Ensuite, j'ai pas tout lu, mais il y a peut être des différences de perfs Donc ce serait une lib mono et une lib threadsafe ?

[hiura]

j'allais dire... pourquoi pas recompiler? C'est pas la mort non plus.

C'est la première idée qui vient. En soit, pour une simple utilisation, c'est pas la mort, effectivement.

Mais dès que tu veux faire des paquets (.deb) tu te casses les dents avec les dépendances : inclure les fichiers lib de boost dans ton propre paquet mène à des conflits avec d'autres paquets.

[koala01]

Salut,

C'est la première idée qui vient. En soit, pour une simple utilisation, c'est pas la mort, effectivement.

Mais dès que tu veux faire des paquets (.deb) tu te casses les dents avec les dépendances : inclure les fichiers lib de boost dans ton propre paquet mène à des conflits avec d'autres paquets.

Rien ne t'empêche de "packager" la version de boost que tu as toi même compilée et de la fournir en lien connexe du style "mon projet dépend de boost 1.xx, dont voici une version personnelle du paquet"

[nikko34]

Je suis le seul que ça choque, d'avoir une lib signals2 ?
Pourquoi ne pas avoir simplement mis à jour signals ?
Et s'il existe un intérêt de continuer à utiliser signals1 (performance pour les programmes monothreads ?), pourquoi ne pas avoir factorisé les deux implémentations et permettre le switch entre les deux avec, disons, un #define qui va bien ?

apparement ils n'ont pas pu garder la même interface avec signals d'où le signals2.

Je ne sais pas ce qu'ils comptent faire de tout ça par la suite. Si je me souvient bien, le problème au niveau des threads se posait quand différents threads pouvaient se connecter/se deconnecter (notez je suis plus très sûr, je ne veux pas dire de bétise mais je n'ai pas le temps de vérifier). J'ai utilisé la lib signals avec des threads de manière basique sans problème.

[hiura]

Rien ne t'empêche de "packager" la version de boost que tu as toi même compilée et de la fournir en lien connexe du style "mon projet dépend de boost 1.xx, dont voici une version personnelle du paquet"

Je la sentais venir celle là.

Le problème c'est que je ne suis pas encore assez calé sur le sujet pour me le permettre. Et ça demande pas mal de temps ( s'arranger avec les licences, quelle hiérarchie de packages utiliser ( réutiliser celle existante ? ) , ..., et finalement finir le deb ) . Bref, s'en est beaucoup pour un débutant.