- Boost - lists.boost.org

"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

Boost 1.36.0 release notice
by Beman Dawes 15 Aug '08

15 Aug '08

Boost 1.36.0 has been released and is available from SourceForge. See http://sourceforge.net/projects/boost/ This release include four new libraries: * Accumulators: Framework for incremental calculation, and collection of statistical accumulators, from Eric Niebler. * Exception: A library for transporting of arbitrary data in exception objects, and transporting of exceptions between threads, from Emil Dotchevski. * Units: Zero-overhead dimensional analysis and unit/quantity manipulation and conversion, from Matthias Schabel and Steven Watanabe * Unordered: Unordered associative containers, from Daniel James. Updated libraries include Asio, Assign, Function, Hash, Interprocess, Intrusive, Math, MPI, Multi-index Containers, PtrContainer, Spirit, Thread, Wave, and Xpressive. The release managers were Beman Dawes, Rene Rivera, and Daniel James. One note of caution: the initial SourceForge release files were missing some of the documentation. If you downloaded before 16:00 UTC, August 14th, please download again to be sure to get the full distribution. Sorry for the inconvenience! --Beman Dawes PS: The 1.36.0 version of the web site should be up within a few hours. If you can't wait, see http://beta.boost.org now!

4 5

AIX xlC error on static_move_ptr.hpp
by Gary Fu 15 Aug '08

15 Aug '08

Hi, Could anyone help why the AIX (5.3) xlC complains on the include file 'static_move_ptr.hpp' and how to solve the problem if possible ? I tried on Linux g++ without problem. Thanks, Gary 8:52pm > xlC -I $HOME/BOOST/boost_1_36_0 example.cpp -o example "/home_dir/Ggfu/BOOST/boost_1_36_0/boost/ptr_container/detail/static_move_ptr.hpp", line 182.22: 1540-2611 (S) The name "typename move_ptrs::enable_if_convertible<TT,T,boost::ptr_container_detail::static_move_ptr &>::type::type" can only be used to declare a constructor. #include <boost/ptr_container/detail/static_move_ptr.hpp> #include <iostream> #include <string> using namespace std; int main() { //print out the text string, "Hello, World!" cout << "Hello, World!" << endl; return 0; }

1 0

Issue building boost libs 1_35_0 on sparcv8 arch. with gcc 4.0.2
by Bhat, Aniket 15 Aug '08

15 Aug '08

FYI, I ran across a problem with the boost inline assembly code in boost_1_35_0/boost/detail/sp_counted_base_gcc_sparc.hpp. This file has inline assembly which uses the "cas" instruction. __asm__ __volatile__( "cas %0, %2, %1" : "+m" (*dest_), "+r" (swap_) : "r" (compare_) : "memory" ); Sparcv8 and pre-v8 architectures seem to be using the "swap" instruction instead. The native sparcv8 assembler therefore complains on trying to parse this: gcc.compile.c++ /home/cmchan/boost_libs/boost/bin.v2/libs/date_time/build/gcc-4.0.2/debu g/threading-multi/greg_month.o /var/tmp//ccMoGlpR.s: Assembler messages: /var/tmp//ccMoGlpR.s:1936: Error: Architecture mismatch on "cas". /var/tmp//ccMoGlpR.s:1936: (Requires v9|v9a|v9b; requested architecture is v8.) The file mentioned above is new in boost_1_35_0 and is included from boost_1_35_0/boost/detail/sp_counted_base.hpp: #elif defined(__GNUC__) && ( defined( __sparcv8 ) || defined( __sparcv9 ) ) Simply removing the pre-processing for __sparcv8 fixes the issue. I am not sure if this is really a tool-chain issue or the problem with the header boost_1_35_0/boost/detail/sp_counted_base.hpp Thanks, Aniket. <DIV><FONT size="1"> E-mail confidentiality. -------------------------------- This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system. If you require assistance, please contact our IT department at helpdesk(a)spirent.com. Spirent Communications plc Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom. Tel No. +44 (0) 1293 767676 Fax No. +44 (0) 1293 767677 Registered in England Number 470893 Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom. Or if within the US, Spirent Communications, 26750 Agoura Road, Calabasas, CA, 91302, USA. Tel No. 1-818-676- 2300 </FONT></DIV>

1 0

Documentation skinning
by Emil Dotchevski 15 Aug '08

15 Aug '08

Perhaps I did something wrong, or failed to follow documentation rules, but the fact that the HTML files that I generated for Boost Exception were processed and wrapped in additional HTML caught me by surprise. Obviously I'm not against using uniform skin throughout Boost, but in general we can't just get HTML+CSS and wrap it with more HTML+CSS, there might be class name collisions, and whatnot. Besides the fact that now the Boost Exception documentation doesn't validate as XHTML 1.0, another problem is that some headings are simply function and class names, which the Boost CSS converts to allcaps, making them look like macros. It seems like other libraries have similar problems, I saw an instance of library documentation having its own tags indicating that it's HTML compliant, to which Boost is adding an additional XHTML 1.0 compliance tag, the end result being that the file is neither HTML or XHTML compliant. This is unfortunate and unprofessional. Is there a standardized XML format that can be used as documentation source? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

2 1