- Boost - lists.boost.org

[iterator] std::sort on zip_iterator (repost)
by Jeremiah Willcock 05 Jun '09

05 Jun '09

(Resubmitting to Boost list because I did not receive any answers on boost-users, nor any helpful answers on the Boost list.) I would like to sort two separate vectors of numbers, treating corresponding elements of the two vectors as tuples and sorting the tuples. In particular, I am only comparing the first elements of the tuples; that may or may not be relevant to my problem. An example program is: #include <vector> #include <algorithm> #include <iostream> #include <boost/tuple/tuple.hpp> #include <boost/iterator/zip_iterator.hpp> struct compare_first_elements_in_tuples { template <typename Tuple> bool operator()(const Tuple& a, const Tuple& b) const { return (a.template get<0>()) < (b.template get<0>()); } }; int main(int, char**) { size_t a_data[5] = {0, 2, 1, 2, 4}; size_t b_data[5] = {1, 1, 5, 3, 7}; std::vector<size_t> a(a_data, a_data + 5); std::vector<size_t> b(b_data, b_data + 5); std::cout << "Before:"; for (size_t i = 0; i < a.size(); ++i) { std::cout << " (" << a[i] << ", " << b[i] << ")"; } std::cout << std::endl; typedef std::vector<size_t>::iterator vec_iter; typedef boost::zip_iterator<boost::tuple<vec_iter, vec_iter> > zip_iter; std::sort(zip_iter(boost::make_tuple(a.begin(), b.begin())), zip_iter(boost::make_tuple(a.end(), b.end())), compare_first_elements_in_tuples()); std::cout << "After:"; for (size_t i = 0; i < a.size(); ++i) { std::cout << " (" << a[i] << ", " << b[i] << ")"; } std::cout << std::endl; return 0; } On gcc 4.0.1, the sort operation results in the element (2, 1) (a pair of corresponding elements in a and b) being duplicated, while the element (1, 5) does not appear in the result at all: Before: (0, 1) (2, 1) (1, 5) (2, 3) (4, 7) After: (0, 1) (2, 1) (2, 1) (2, 3) (4, 7) I suspect the problem is related to the fact that zip_iterator does not return a "real" reference when dereferenced. Am I mistaken about this? Is the code above supposed to work? If not, is there an alternative way to sort one sequence while swapping elements in another in a corresponding way? I am not able to join the two input sequences into a single sequence of pairs because of other factors in the use case for this code. Thank you for your help. -- Jeremiah Willcock

6 24

[Bug Sprint] [variant] #2839 ambiguous swap call
by Daniel Hulme 05 Jun '09

05 Jun '09

I've just added a test program to ticket #2839: it fails on vc9. The ticket, I think, explains the problem pretty well, but I would like an expert to look at the code. I believe that the program is ill-formed, and it only works on gcc because the BOOST_WORKAROUND disables the code in question. The issue is that variant/detail/move.hpp:114 introduces a templated swap() overload in the same scope it will be called from, to allow move emulation. But, if the variant bounds a type defined in std::, like std::vector, then std::swap is another templated swap() and will be found by ADL. This makes the call ambiguous. My recommendation is that the move-emulation code be removed -- or enable_if'd, if that's possible -- until the generalised Boost.Move implementation is ready to be adopted. If we believe the code as it stands is correct, then I think the test case should be added to trunk and release, and additional BOOST_WORKAROUNDs added for all the compilers where the test fails. -- “Papa Hegel he say that all we learn from history is that we learn noth- hing from history. I know people who can't even learn from what happened this morning. Hegel must have been taking the long view.” -- John Brunner, ‘Stand on Zanzibar’

4 9

Re: [boost] boost.timer library submission...
by JohnQ 05 Jun '09

05 Jun '09

Hi Dmitry, Answers in-line... >> Do you hold a mutex locked while invoking a callback? yes, I'm holding a boost::unique_lock<boost::mutex>... as a result, the callback method shouldn't do much. Mine only records the fact that the timer fired and the data passed back and puts it on a queue for another of my app threads to handle. >>What mechanism do you use to suspend till it's time to fire a callback? boost::condition_variable m_timed_cond.timed_wait(timer_lock, cur_timer) >>What is the precision of your library? I mean if you instruct the >>library to invoke your callback in so many ms usually your callback will >>be invoked at bit later. The question is how long later? Or earlier? Typically fires later than earlier... the tolerance window I've been using is 5 ms - 10ms. The unit test included in the lib I uploaded to boost value includes a test that puts 100 timers up and measures when they fire. Occassionally out of that window. So far I've been running this on my mac and there's a lot running on it typically, so I'm suspicious of my results and think they could be better. >>Does the precision degrade when you register lots of callbacks? Not that I know of... I've put a couple of hundred thousand in there... so far the time to rebalance the underlying map for insertion / deletion hasn't shown up as an effect. >>What's the smallest possible timeout the library lets to register a >>callback with? How does the library handle small (e.g. 1 ms) timeout >>requests? Currently, millisecond resolution but totally happy to change it to reflect the greatest accuracy the underlying system timer can achieve. I've been testing this with a timing window (i.e., anything within, say, 10ms of the original timer also gets called back). The timing window is configurable. What platforms does the library work on? Been compiling this on my mac. Will have it running on Centos shortly. Haven't tried it at all on Win platform yet. >>BR, Dmitry Thanks, John Q.

2 1

Re: [boost] sorting library proposal
by Steven Ross 05 Jun '09

05 Jun '09

Is there a good way to issue a compile-time warning telling people that integer_sort or float_sort isn't being used, because they passed in an incompatible data type? I see static assertions, but what I need is an equivalent static warning, after which I use std::sort. integer_sort won't run on long longs, because it uses size_t for distance codes. I've added a check to see whether the key type being used is of the same size or smaller than a size_t to handle this problem. I don't think integer_sort is an appropriate algorithm for data types larger than a size_t, unless comparisons are ridiculously slow, as the k/s factor starts becoming quite large. Also, I'm using a simple if to decided this: if(sizeof(Div_type) <= sizeof(size_t)) because enable_if appears to only work with classes. I'm assuming here that the compiler is smart enough to figure out that the expression is constant and to only bring in the code if it's true. It would be nice to be able to eliminate the compiler warnings about size, and issue a more concise and meaningful message telling the user that their data type is too big for integer_sort (or incompatible with float_sort, as appropriate).

3 3

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 04 Jun '09

04 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 04 Jun '09

04 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