June 2009 - Boost - lists.boost.org

Re: [boost] unique_ptr for C++0x exprimental compilers?
by Artyom 05 Jun '09

05 Jun '09

Hi, You can test it using g++-4.3 and g++-4.4. - g++-4.3 supportd rvalue - g++-4.4 implements unique_ptr You may send the code to me if you don't have an access to them Artyom P.S.: I eraced your previous mail accidently > Hi, > > Is there anybody already implementing an auto_ptr > replacement > (unique_ptr) for Boost? I've got a really simple > implementation that > I'm attaching to this email (with tests) that I'm > submitting for > review.

1 0

[fusion] improving compile times
by Eric Niebler 05 Jun '09

05 Jun '09

I'm attaching a simple patch to vector_n_chooser.hpp that replaces some template metaprogramming with preprocessor metaprogramming in the interest of improving compile times. I found this hotspot through profiling, and there are likely to be many more such patches in the near future. I could open a trac ticket and attach all the patches there, or I could just commit them to trunk as I go. Thoughts? P.S. It would be great to get some other heavy users of template metaprogramming interested in making other such changes to bring down the compile times of the core TMP libraries like MPL, Fusion, Proto, etc., etc. -- Eric Niebler BoostPro Computing http://www.boostpro.com Index: vector_n_chooser.hpp =================================================================== --- vector_n_chooser.hpp (revision 53535) +++ vector_n_chooser.hpp (working copy) @@ -25,11 +25,13 @@ #include <boost/fusion/container/vector/vector50.hpp> #endif -#include <boost/mpl/distance.hpp> -#include <boost/mpl/find.hpp> -#include <boost/mpl/begin_end.hpp> #include <boost/preprocessor/cat.hpp> +#include <boost/preprocessor/arithmetic/dec.hpp> +#include <boost/preprocessor/arithmetic/sub.hpp> +#include <boost/preprocessor/facilities/intercept.hpp> #include <boost/preprocessor/repetition/enum_params.hpp> +#include <boost/preprocessor/repetition/enum_trailing_params.hpp> +#include <boost/preprocessor/repetition/enum_params_with_a_default.hpp> namespace boost { namespace fusion { @@ -38,40 +40,23 @@ namespace boost { namespace fusion { namespace detail { - template <int N> - struct get_vector_n; + template <BOOST_PP_ENUM_PARAMS(FUSION_MAX_VECTOR_SIZE, typename T)> + struct vector_n_chooser + { + typedef BOOST_PP_CAT(vector, FUSION_MAX_VECTOR_SIZE)<BOOST_PP_ENUM_PARAMS(FUSION_MAX_VECTOR_SIZE, T)> type; + }; template <> - struct get_vector_n<0> + struct vector_n_chooser<BOOST_PP_ENUM_PARAMS(FUSION_MAX_VECTOR_SIZE, void_ BOOST_PP_INTERCEPT)> { - template <BOOST_PP_ENUM_PARAMS(FUSION_MAX_VECTOR_SIZE, typename T)> - struct call - { - typedef vector0 type; - }; + typedef vector0 type; }; #define BOOST_PP_FILENAME_1 \ <boost/fusion/container/vector/detail/vector_n_chooser.hpp> -#define BOOST_PP_ITERATION_LIMITS (1, FUSION_MAX_VECTOR_SIZE) +#define BOOST_PP_ITERATION_LIMITS (1, BOOST_PP_DEC(FUSION_MAX_VECTOR_SIZE)) #include BOOST_PP_ITERATE() - template <BOOST_PP_ENUM_PARAMS(FUSION_MAX_VECTOR_SIZE, typename T)> - struct vector_n_chooser - { - typedef - mpl::BOOST_PP_CAT(vector, FUSION_MAX_VECTOR_SIZE) - <BOOST_PP_ENUM_PARAMS(FUSION_MAX_VECTOR_SIZE, T)> - input; - - typedef typename mpl::begin<input>::type begin; - typedef typename mpl::find<input, void_>::type end; - typedef typename mpl::distance<begin, end>::type size; - - typedef typename get_vector_n<size::value>::template - call<BOOST_PP_ENUM_PARAMS(FUSION_MAX_VECTOR_SIZE, T)>::type - type; - }; }}} #endif @@ -85,14 +70,12 @@ #define N BOOST_PP_ITERATION() - template <> - struct get_vector_n<N> + template <BOOST_PP_ENUM_PARAMS(N, typename T)> + struct vector_n_chooser< + BOOST_PP_ENUM_PARAMS(N, T) + BOOST_PP_ENUM_TRAILING_PARAMS(BOOST_PP_SUB(FUSION_MAX_VECTOR_SIZE, N), void_ BOOST_PP_INTERCEPT)> { - template <BOOST_PP_ENUM_PARAMS(FUSION_MAX_VECTOR_SIZE, typename T)> - struct call - { - typedef BOOST_PP_CAT(vector, N)<BOOST_PP_ENUM_PARAMS(N, T)> type; - }; + typedef BOOST_PP_CAT(vector, N)<BOOST_PP_ENUM_PARAMS(N, T)> type; }; #undef N

9 21

Change to documentation writing guidelines
by Daniel James 05 Jun '09

05 Jun '09

Hi, I'd like to change the guideline for writing reference documentation to include header and namespace information in the detailed documentation. If you arrive at a page by a link or from a search engine, it isn't always easy to work this out. I'll add them to the list here: http://beta.boost.local/doc/libs/release/more/writingdoc/structure.html#det… Boostbook documentation already includes this. Any objections? Daniel

6 15

[threads] final decision on making parts of Boost.Threads header-only
by JOAQUIN M. LOPEZ MUÑOZ 05 Jun '09

05 Jun '09

Hi, A few weeks ago we had a discussion about the convenience of making part of Boost.Threads, namely mutexes and locks, header-only. Some (including Anthony Williams) supported the idea, others disliked it: http://lists.boost.org/Archives/boost/2009/04/150524.php What the final decision on this issue is? If positive (i.e. favoring the change), can it be expected to be done for Boost 1.40? As a remainder, I've created an associated trac ticket: https://svn.boost.org/trac/boost/ticket/2964 Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

boost trac for upcoming libraries?
by Barend Gehrels 05 Jun '09

05 Jun '09

Hi, Is the Boost Trac system intended for official libraries only, or can we also use it for (to be) proposed libraries? Thanks, Barend

6 6

Discussion on compilation-error-when-using-ptr-container
by Eric Niebler 04 Jun '09

04 Jun '09

You should direct questions to boost(a)lists.boost.org.

1 0

[lexical_cast] Locale used during conversion
by Adam Badura 04 Jun '09

04 Jun '09

lexical_cast does not allow to pass the locale to be used during conversion. This is justified with analogy of lexical_cast to other casts which all take only one parameter. So lexical_cast always uses the current global locale. A reasonable choice. However I wanted to propose some additional features. It would be useful to provide (lets call it so for now) classic_lexical_cast which would use std::locale::classic() instead of the global one. I just finalized globalization/localization of our application by adding setting of the global locale to appropriate value according to the selected language. I noticed that all of sudden serialized data (mainly projects) stopped loading/saving correctly. The reason was easy to find. Where previously we had XML node named "item1000" we now have "item1,000" in English or "item1 000" in Polish for example. The projects are no longer interchangeable between applications running in different language version. I corrected this by adding our own lexical_cast which resets the global locale to the classic one, calls boost::lexical_cast and finally resets the global locale back. This special cast is used now whenever we are dealing with texts which are not presented to the final user. This works fine however it seems that resetting the global locale often (each time we save a number in the project for example...) is causing significant performance overhead. (Exact tests have not been yet performed but this seems the only change which might have affected all serialization slowdown.) I might reset it before saving the project and then save the project as usually but this is not very handy as I would have to remember to do it each time I am serializing any data. Also other problems are implied. Other threads for the short period of time see different global locale as well and thus might produce bad strings. And in the end it is impractical. It would be handy to have classic_lexical_cast as well as it could introduce some optimizations knowing that the requested locale is the classic one. Another thing is that it would be handy to introduce a function textual_convert (another example name) which would act like lexical_cast but would take the requested locale as a parameter (this is no longer a cast so it may). lexical_cast might take that locale as a second parameter with default value being the global locale so it could still be used just as any other casting. But I suppose this would not be well seen. Thus why not introduce a different function for that (or maybe there already is one?). It seems those changes would not be difficult to implement and could be hidden in the details of lexical_cast easily. What do you think of that? Finally lexical_cast's documentation might mention explicitly that current global locale is used as it does not mention that if I am not mistaken (I haven't found "locale" word in that document). Adam Badura

3 6

Bug Sprint Report for Wednesday, June rd
by Marshall Clow 04 Jun '09

04 Jun '09

The boost bug sprint started Friday, May 29th, and runs through Sunday June 7th. Wednesday was not a good day in terms of bug closing; the good news is that we've already (as of 6 AM) closed more bugs on Thursday than all of Wednesday. Status <https://svn.boost.org/trac/boost/report/1> 7:00 AM PDT 5/29: 797 open tickets. 7:45 AM PDT 5/30: 772 open tickets. 6:00 AM PDT 5/31: 761 open tickets. 6:00 AM PDT 6/2: 747 open tickets. 6:00 AM PDT 6/3: 748 open tickets. 6:00 AM PDT 6/4: 739 open tickets. Activity: 5/29: 6 new tickets, 77 modifications, 25 tickets closed 5/30: 2 new tickets, 42 modifications, 17 tickets closed 5/31: 2 new tickets, 27 modifications, 8 tickets closed 6/1: 2 new tickets, 42 modifications, 17 tickets closed 6/2: 5 new tickets, 18 modifications, 5 tickets closed. 6/3 4 new tickets, 19 modifications, 2 tickets closed. [ Numbers may not add up because I am counting via two different methods, using data that is time-stamped in two different time zones. Also, tickets can be closed and reopened. ] What can you do? See <https://svn.boost.org/trac/boost/wiki/BugSprintJune2009> for details. I've added four new reports to the trac: Open ticket count by owner: <https://svn.boost.org/trac/boost/report/18> Open ticket count by component: <https://svn.boost.org/trac/boost/report/19> Open ticket count by ticket type: <https://svn.boost.org/trac/boost/report/20> Open ticket count by milestone: <https://svn.boost.org/trac/boost/report/21> There's been a lot of discussion on the list about tickets; and there are about a dozen patches that have been tested and are ready to be applied. If you're looking to help, you can look at some of the older bugs, say, the ones for Boost 1.36, and determine if they still apply. If they do, note that in the ticket. There are 35 tickets that are still open that are marked as "to be fixed in Boost 1.36" See <https://svn.boost.org/trac/boost/report/3> for a list of open tickets by milestone. --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) 9) Steven Watanabe <watanabesj(a)gmail.com> (bug fixes, como) 10) vicente.botet" <vicente.botet(a)wanadoo.fr> 11) Stjepan Rajko <stjepan.rajko(a)gmail.com> (fusion) 12) Daniel Wallin (parameter, ...) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

Trac unwell?
by Vladimir Prus 04 Jun '09

04 Jun '09

Hi, it looks like Trac is not feeling very well: 1. Opening an issue takes at least 10 seconds, sometimes a minute. 2. Adding a comment to an issue takes equally weird time. 3. From time to time it gives: "Database locked" errors. The page with the error does not have any additional information. Can somebody look into this? - Volodya

5 6

Ticket #637 - Adjusts mpl::pair concept to be compatible with STL pairs
by Joel Falcou 04 Jun '09

04 Jun '09

https://svn.boost.org/trac/boost/ticket/637 Is this feature request still sensible or does fusion make this useless somehow ? If not, I can provide patch+test -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

4 4