- Boost - lists.boost.org

[accumulators] combine/parallel_reduce
by Pavol Droba 18 Aug '08

18 Aug '08

Hi, I've just started to use the accumulators library. I must say that I like it a lot. However, I found one feature that I'm missing in the interface. In the time of multicore processors and Thread Building Blocks at hand, it would be nice to be able to use accumulators in parallel computations. To do so, one would need to combine partial computations. In other words, we need accumulator_set::combine(). This would combine the partial computation state from another accumulator_set. This operation would enable the accumulators to be used with parallel_reduce. I'm not expert in statistical computations, but as far as I can see, this should be doable quite easily. Best Regards, Pavol.

3 4

[doc] General Boost documentation suggestion
by Edward Diener 18 Aug '08

18 Aug '08

This is an impassioned plea for all library developers writing documentation about classes and/or functions ( including class templates and function templates ). Please, please put somewhere in the low-level description/explanation of that class and function both the full namespace it is in and the header file which must be included. Numerous times, using the functionality of an otherwise wonderful Boost library, I have had to hunt through the rest of that library's documentation to find the full namespace and header file which must be included in order to correctly use a particular function or class. This is irritatingly time consuming and can be remedied in all cases by the suggestion above. Thank you !

3 3

[shared_ptr][exception] Support for disabled RTTI
by Daniel James 18 Aug '08

18 Aug '08

Using boost with RTTI disabled was recently discussed on the user list, and I had a quick look into it. It seems that shared_ptr added support for the BOOST_NO_TYPEID macro in 1.35: http://svn.boost.org/trac/boost/ticket/1108 But because it now depends on the new exception library, which requires RTTI, it no longer works. Would it be possible to support the macro in Boost.Exception? Daniel

5 8

[shifted_ptr] STL support: 99%
by Phil Bouchard 18 Aug '08

18 Aug '08

Ok, this is awesome. Last week I made changes in the Sandbox I had to revert and rework all over... Now the changes I made in both the pointer and the STL containers are clearly to ones I want to stick with. This brings up interesting concepts at the same time, such as: what should be the right parameter of allocator::deallocate() ? We can't use a raw pointer over there. We can see the non-official patch inside the bits folder and shifted_allocator.hpp which I think solves the problem correctly. Furthermore allocator::allocate() I beleive shouldn't return yet a smart pointer because it creates unnecessary temporaries which can be costly, depending on the smart pointer used. So the typedefs inside shifted_allocator are the way I think they should be understood by the containers... Thanks, -Phil

4 15

"SuperC"
by Phil Bouchard 18 Aug '08

18 Aug '08

Here is a discussion I started with Gordon 2 weeks ago and I wanted to share globally because of its interesting features which aren't related to smart pointers: "I think a huge container inside an application will always suffer from imperfections and this could be a decent alternative to the problem. A map mixed with a list, a vector mixed with a set or all four together offers an infinite set of properties. Let's put it this way. All new "unordered" and multiset containers could easily be implemented as: 1) superc1st<double, list, vector> s1; 2) superc2nd<string, double, map, vector> s2; 3) superc2nd<string, double, map, map> s3; Where (explicit specializations for sake of example and please disregard missing "typename"s): 1) template <> class superc1st<double, list, vector> : public _list<0, void, double>, _vector<1, void, double> {...}; Here are examples of its usage: s1.push_back(5.7); s1[0] = 5.8; 2) template <> class superc2nd<string, double, map, vector> : public _map<0, string, double>::base, _vector<1, string, double>::base {...}; This one can be accessed as such: s2["Height"] = 6.3; // <-- O(log n) s2[10] = 5.9; // <-- O(1) 3) template <> class superc2nd<string, double, map, map> : public _map<0, string, double>::base, _map<1, string, double>::base {...}; To access 3) we could add indexed types we can cast the container to:s3.get<0>()["Age"] = 31; The underscored containers will be defined as: template <int I, typename T, typename U> struct _map : std::map<T, U> { typedef std::map<T, U> base; base & get<I>() { return * this; } // explicit function spec. won't work here (should be Ith type pack cast) }; And: template <int I, typename T, typename U> struct _vector : std::vector<U> { typedef std::vector<U> base; ... }; ... I think this is very easy to implement, cleaner and much more flexible (can use vectors and no container can be forgotten). My brain kernel example already needs something similar extensively..." Thanks, -Phil

1 0

[1.36.0: Graph] unused variable warning in topological_sort.hpp
by Christoph Duelli 18 Aug '08

18 Aug '08

in boost/graph/topological_sort.hpp, line 40 is an unused variable (u): template <typename Edge, typename Graph> void back_edge(const Edge& u, Graph&) { throw not_a_dag(); } Would be great if that could be fixed for the next release. Keep up the great job! Best regards Christoph

1 0

[1.36.0: Serialization] unused variable warning in shared_ptr.hpp
by Christoph Duelli 18 Aug '08

18 Aug '08

in boost/serialization/shared_ptr.hpp, line 133: in the case of NOT "#ifdef BOOST_SERIALIZATION_SHARED_PTR_132_HPP" the variable file_version is not used. Could be fixed by replacing else #endif by else #else (void)file_version; #endif or something similar. Would be great if that could be fixed for the next release. Keep up the great job! Best regards Christoph

1 0

Roland Puntaier ist außer Haus.
by Roland Puntaier 18 Aug '08

18 Aug '08

Ich werde ab 18.08.2008 nicht im Büro sein. Ich kehre zurück am 30.08.2008.

1 0

[asio]: extending asio
by Andreas Pokorny 17 Aug '08

17 Aug '08

Hello, I would like to add more asynchronous event sources to asio, like: - input events for mouse, keyboard and joystick .. - window exposure, move, resize events in some generic form, - generic "quit" events - file alteration With directFB/X11/Unix/Linux most of that can be done directly through select or epoll. But since reading the message and parsing events is mostly done by a third party library, I would only need the reactor part for these. Is this possible with asio? According to msdn it seems to be possible to create so called event objects for direct input devices. I am no win32 expert so I do not know if one can combine that with completion ports? Regards Andreas Pokorny

7 16

[swap] Renaming boost_swap_impl::swap_impl and/or its namespace?
by Niels Dekker - mail address until 2008-12-31 16 Aug '08

16 Aug '08

The boost::swap utility forwards its task to a helper function, ::boost_swap_impl::swap_impl. I /think/ that this top-level namespace, "boost_swap_impl", is there only "for historical reasons", because it was part of an ADL barrier. This ADL barrier is now replaced by a superior technique to avoid ambiguity, giving boost::swap an extra template argument as suggested by Steven Watanabe: // From http://svn.boost.org/svn/boost/trunk/boost/utility/swap.hpp namespace boost { template<class T1, class T2> void swap(T1& left, T2& right) { ::boost_swap_impl::swap_impl(left, right); } } So now I think it's preferable to remove the top-level namespace, "boost_swap_impl", and move the helper function into the boost namespace. For instance within a new nested namespace, boost::swap_impl_detail. Right? The name "boost::swap_impl_detail" should indicate to the user that she should not call swap_impl directly, because it's only an "implementation detail" of boost::swap. Or would it be preferable to have the swap_impl function "officially" accessible to the end user? If so, we might move swap_impl to the boost namespace, and rename it to something more "user friendly". (I would like to have it named, e.g., "boost::swap_using_adl".) I can think of two reasons why end-users might want to call swap_impl directly, instead of calling boost::swap: It /might/ in some cases, on /some/ platforms, perform /slightly/ better than boost::swap, because it would skip one function call. And secondly, swap_impl allows the user to specify the type of both function arguments by one single template argument. While the current boost::swap utility no longer does. For example: class animal_base_class {}; class cat_class : public animal_base_class {}; class dog_class : public animal_base_class {}; void swap(animal_base_class &, animal_base_class &) {} int main() { cat_class cat; dog_class dog; std::swap<animal_base_class>(cat, dog); // Okay. boost_swap_impl:: swap_impl<animal_base_class>(cat, dog); // Better: using ADL. boost::swap<animal_base_class>(cat, dog); // Compile error! } Of course we could also just keep the swap_impl function as an unsupported "implementation detail" for a while, until a user might want to use it... What do you think? -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

4 13