July 2006 - Boost - lists.preview.boost.org

Proposed addition to the iterator library for iterating over all tuples.
by Alex Mendes da Costa 19 Jun '09

19 Jun '09

Hi folks: I quite often have to write code to do the following: Given N sequences, generate all the N-tuples s.t. the i'th element in each tuple is drawn from the i'th sequence. For example, if sequence S1 is { 1, 2, 3 } and sequence S2 is { 10, 20 }, I need to generate these tuples: (1, 10), (2, 10), (1, 20), (2, 20). I think this problem could be solved elegantly with a iterator similar to zip_iterator. I have some questions: (1) Is there already a way to do this in boost? (2) If not, would this be a worthwhile addition to the iterator library? (3) If so, could I contribute code for this, or must the existing library owners write it? (4) If so, how would I go about getting my code added? Most of the docs seem to be about submitting entire libraries, rather than extensions to existing libraries. Thanks, Alex

4 18

[fusion] list/detail/at_impl.hpp, Suggest recrusive elem_at_c instead of recursive apply
by Larry Evans 24 Oct '07

24 Oct '07

In boost/fusion/.../list/detail/at_impl.hpp the apply is recursive; however, the only reason for the recursion is to "find the right element type". The other reason for apply is the same as that of the apply in.../vector/detail/at_impl.hpp. "find the right element type" in vector's at_impl is done with mpl::at. The similarity between list and vector at_impl would be more apparent if: template <typename Sequence, int N> struct elem_at_c { typedef typename mpl::eval_if< mpl::bool_<N == 0> , mpl::identity<typename Sequence::car_type> , elem_at_c<typename Sequence::cdr_type, N-1> >::type type; }; were used to find the right element type. Then the frist part of list::at_impl::apply would be: template <typename Sequence, typename N> struct apply { typedef elem_at_c<Sequence, N::value> element; typedef typename mpl::eval_if< is_const<Sequence> , detail::cref_result<element> , detail::ref_result<element> >::type type; which is very similar to the counterpart in vector: template <typename Sequence, typename N> struct apply { typedef mpl::at<typename Sequence::types, N> element; typedef typename mpl::eval_if< is_const<Sequence> , detail::cref_result<element> , detail::ref_result<element> >::type type;

2 3

[defer] - comments?
by simon meiklejohn 14 Mar '07

14 Mar '07

Anyone had a play with the defer library in the vault and want to comment on its usefulness? It clearly shares much in common with the asio Dispatcher concept but with the freedom to define more general Dispatchers. (e.g. 'Create thread per callback' and 'Dispatch Callback via Message Pump', both of which violate the specific guarantees of the asio Dispatcher concept, that the callback occur in a thread that has called asio::demuxer::run().) One potential application for defer would be in conjunction with asio, creating the thread(s) which call demuxer::run() in a succinct form. Cheers Simon

3 2

interest in pair projection iterators?
by Lewis Hyatt 22 Dec '06

22 Dec '06

Hi All, I am in the middle of writing a large body of numerical code for data analysis and have found the boost library very useful for a number of things. I do a lot of work with std::map and with containers of std::pair objects, and one thing I've always felt annoyed with is the difficulty of interfacing a value_type of std::pair with the STL algorithms. Frequently, for instance, it is nice to represent data as a std::list< std::pair<double,double> > and then to be able to work with the first and second coordinates independently and pass them to std::accumulate() or whatever. The SGI extensions select1st() and select2nd() are somewhat useful but also non-standard, and they frequently require memory-wasting buffers to store only the first or second elements. I have a relatively simple system for solving this problem and it strikes me as the kind of quick thing that might be worth including in boost. The idea is to define a template class, template<typename Iterator> class first_iterator_t { Iterator pair_iter; public: first_iterator_t(Iterator const&); /*...*/ }; which overloads operator*() and operator->() to access the element named "first" of the object returned by Iterator::operator*(). (With something analagous for second_iterator_t.) A function named first_iterator() provides a convenient creation function a-la std::make_pair(). That's it for the most part, the class only needs to provide the required iterator interface which mostly consists of just calls to Iterator::operator functions. There is also the need to define the appropriate iterator_traits typedefs. There is a small issue of deducing whether the iterator needs to be a const iterator or not, which can be solved with partial specialization of a second template class containing nested typedefs. The end result is that something like this is now conveniently available: map<int, double> m; m[1] = 0.1; m[2]=0.2; m[5]=0.5; //prints: 1 2 5 copy(first_iterator(m.begin()), first_iterator(m.end()), ostream_iterator<int>(cout, "\t")); //prints: 0.1 0.2 0.5 copy(second_iterator(m.begin()), second_iterator(m.end()), ostream_iterator<double>(cout, "\t")); I don't see a way to do this otherwise without resorting to something like select1st(), and that also requires the use of std::transform(), which I find distasteful since the required operation is really just a simple copy. So anyway do you think this is useful enough to possibly include in boost somewhere, or is it too trivial? I have what I believe to be correct code, which could be made boost-ready with little effort. Thanks for your advice! -Lewis

4 5

Asio, run-time polymorphism
by stas garifulin 15 Nov '06

15 Nov '06

Hello. I have some experience with http protocol and i have question/suggestion about implementing this protocol using asio library. Http/1.1 supports "protocol upgrades": during persistent connection client ot server can ask remote peer to upgrade protocol (push additional protocol(s) in protocol stack just before HTTP). After successful upgrading client can continue to send http-requests to server over new protocol stack. See "Upgrading to TLS Within HTTP/1.1" (http://www.faqs.org/rfcs/rfc2817.html) for examples. Currently asio doesn't allow me to implement this facility (to transform socket using simple transport protocol, like TCP, to SSL-socket in run-time). Another problem. HTTP/1.1 supports transfer-encoded bodies of packets, i.e. bodies transformed for transmission between sender and recipient (compressed, chunked etc.). Such transfer-encoded bodies are always chunked, splitted to chunks, each chunk have header with his size, zero sized chunk signals end of body. In some step of my program i would like to eliminate difference between plain bodies (reading/writing to socket) and transfer-encoded bodies (reading/writing to chain of filters). In other words i'm talking about some infrastructure like boost::iostreams but built on top of asio dispatcher. Async analogue of boost::iostreams which allows me to create async chains of filters in run-time. For example, it can be done with non-templated versions of functions async_read, async_write, handler parameter of this functions will have type like boost::function<void (asio::error, size_T)>. SSL class could be implemented as such async filter and would allow attaching at run-time.

4 4

[variant, MPL] Is there a variant -> mpl sequence metafunction ?
by Jaakko Järvi 13 Nov '06

13 Nov '06

make_variant_over<Seq>::type creates a variant type from an MPL Sequence. Is there an operation that would do the opposite, create an MPL sequence from a variant? I cannot just use the type parameter list as such because the types that stand for an empty type are different in both libraries: boost::detail::variant::void_ in variant, and something else in MPL. Best, Jaakko -- Jaakko Järvi, jarvi(a)cs.tamu.edu

8 12

[jamboost] Boost.Build V2, Milestone 10 released
by Vladimir Prus 04 Nov '06

04 Nov '06

I'm pleased to announce that the next milestone release of Boost.Build V2 is available at http://prdownloads.sourceforge.net/boost/boost-build-2.0-m10.tar.bz2 http://prdownloads.sourceforge.net/boost/boost-build-2.0-m10.zip See also http://boost.org/boost-build2/ for online docs (a copy is included in distribution). Due to large number of improvements all users are encouraged to upgrade. Changes in this release: Many toolsets were added: Intel, Metrowerks, Comeau, aCC, vacpp. Documentation was converted to BoostBook and improved. Performance was improved. - Toolsets initialization syntax is much more uniform. Compiler and linker flags can now be specified. - The algorithm for computing build properties was improved. Conditional requirements can be chained, and a number of bugs were fixed. - Specific order of properties can be specified. - The main target rules can be called from everywhere, not necessary from Jamfile. - Check for "unused sources" removed. - The <library> feature affects only linking now. - The <file> feature now works only for libraries. - Simpler syntax for "searched" libraries was added. - New <dependency> feature. Unix: The right order of static libraries on Unix is automatically computed. The <hardcode-dll-paths> feature is the default. gcc: The -fPIC option is passed when creating shared libraries. Problems with distcc were solved. Sun: It's now possible to use the sun linker (as opposed to gnu), and to compile C files. Darwin: Shared libraries are now supported. MSVC: Before resource files compilation, the setup script is invoked. Options deprecated in 8.0 are not longer used. The following bugs were fixed: - The <unit-test> rule did not handle the <library> property. - Don't add "bin" to the build directory explicitly specified by the user. - Allow <include-type> to select staged targets, even with <traverse-dependencies>off. - Includes for the form '# include <whatever>" did not work. - (Qt) Add paths to all dependent libs to uic command line, which helps if the UI files uses plugins. - Using <toolset-msvc:version>xxx in requirements was broken. - Error message printed when target can be found is much more clear. - Inline targets in sources of 'stage' did not work. - Don't produce 'independent target' warnings on Windows - (gcc) The <link-runtime>static did not work. - (gcc) Suppress warnings from the 'ar' tool on some systems. - (gcc) Don't try to set soname on NT. Developer visible changes: - Generator priorities are gone, explicit overrides are used. - 'Active' features were removed - Support for VMS paths was added. Thanks to Christopher Currie, Pedro Ferreira, Philipp Frauenfelder, Andre Hentz, Jurgen Hunold, Toon Knapen, Johan Nilsson, Alexey Pakhunov, Brock Peabody, Michael Stevens and Zbynek Winkler who contributed code to this release. - Volodya

3 5

[Python] Slice test fails on Intel 8.1 at runtime
by Stefan Slapeta 23 Oct '06

23 Oct '06

This is not a new failure, but the failure is reported for the first time. Please could anybody have a look at it? See http://tinyurl.com/4n2fx Thanks, Stefan

5 12

[thread] Race condition(?) on tss_data
by Felipe Magno de Almeida 04 Oct '06

04 Oct '06

Hello, I'm using an AMD64 X2 and sometimes the program fails with the debugger showing me this call stack: > basic.exe!`anonymous namespace'::get_slots(bool alloc=false) Line 108 + 0x5 C++ basic.exe!boost::detail::tss::get() Line 164 + 0x7 C++ basic.exe!boost::thread_specific_ptr<boost::weak_ptr<boost::spirit::impl::grammar_helper<boost::spirit::grammar<smtp_client::impl::grammars::greeting_response,boost::spirit::parser_context<boost::spirit::nil_t> >,smtp_client::impl::grammars::greeting_response,boost::spirit::scanner<char *,boost::spirit::scanner_policies<boost::spirit::iteration_policy,boost::spirit::match_policy,boost::spirit::action_policy> > > > >::get() Line 89 + 0x16 C++ basic.exe!boost::spirit::impl::get_definition<smtp_client::impl::grammars::greeting_response,boost::spirit::parser_context<boost::spirit::nil_t>,boost::spirit::scanner<char *,boost::spirit::scanner_policies<boost::spirit::iteration_policy,boost::spirit::match_policy,boost::spirit::action_policy> > >(const boost::spirit::grammar<smtp_client::impl::grammars::greeting_response,boost::spirit::parser_context<boost::spirit::nil_t> > * self=0x005a6664) Line 226 + 0xa C++ basic.exe!boost::spirit::impl::grammar_parser_parse<0,smtp_client::impl::grammars::greeting_response,boost::spirit::parser_context<boost::spirit::nil_t>,boost::spirit::scanner<char *,boost::spirit::scanner_policies<boost::spirit::iteration_policy,boost::spirit::match_policy,boost::spirit::action_policy> > >(const boost::spirit::grammar<smtp_client::impl::grammars::greeting_response,boost::spirit::parser_context<boost::spirit::nil_t> > * self=0x005a6664, const boost::spirit::scanner<char *,boost::spirit::scanner_policies<boost::spirit::iteration_policy,boost::spirit::match_policy,boost::spirit::action_policy> > & scan={...}) Line 279 + 0x9 C++ basic.exe!boost::spirit::grammar<smtp_client::impl::grammars::greeting_response,boost::spirit::parser_context<boost::spirit::nil_t> >::parse_main<boost::spirit::scanner<char *,boost::spirit::scanner_policies<boost::spirit::iteration_policy,boost::spirit::match_policy,boost::spirit::action_policy> > >() Line 53 + 0x1f C++ basic.exe!boost::spirit::grammar<smtp_client::impl::grammars::greeting_response,boost::spirit::parser_context<boost::spirit::nil_t> >::parse<boost::spirit::scanner<char *,boost::spirit::scanner_policies<boost::spirit::iteration_policy,boost::spirit::match_policy,boost::spirit::action_policy> > >() Line 63 + 0x42 C++ basic.exe!boost::spirit::parse<char *,smtp_client::impl::grammars::greeting_response>(char * const & first_=0x006e4374, char * const & last=0x006e439a, const boost::spirit::parser<smtp_client::impl::grammars::greeting_response> & p={...}) Line 30 C++ basic.exe!smtp_client::impl::detail::initialize_smtp_connection::match<char *,smtp_client::impl::grammars::greeting_response>() Line 34 + 0x15 C++ basic.exe!smtp_client::impl::detail::initialize_smtp_connection::handle_greetings_read(boost::asio::error & error={...}, unsigned int bytes_received=38) Line 61 + 0x2b C++ basic.exe!boost::_mfi::mf2<void,smtp_client::impl::detail::initialize_smtp_connection,boost::asio::error &,unsigned int>::operator()(smtp_client::impl::detail::initialize_smtp_connection * p=0x006e42c8, boost::asio::error & a1={...}, unsigned int a2=38) Line 274 + 0x12 C++ basic.exe!boost::_bi::list3<boost::_bi::value<smtp_client::impl::detail::initialize_smtp_connection *>,boost::arg<1>,boost::arg<2> >::operator()<boost::_mfi::mf2<void,smtp_client::impl::detail::initialize_smtp_connection,boost::asio::error &,unsigned int>,boost::_bi::list2<boost::asio::error &,unsigned int &> >() Line 348 C++ basic.exe!boost::_bi::bind_t<void,boost::_mfi::mf2<void,smtp_client::impl::detail::initialize_smtp_connection,boost::asio::error &,unsigned int>,boost::_bi::list3<boost::_bi::value<smtp_client::impl::detail::initialize_smtp_connection *>,boost::arg<1>,boost::arg<2> > >::operator()<boost::asio::error,unsigned int>() Line 62 C++ basic.exe!boost::detail::function::void_function_obj_invoker2<boost::_bi::bind_t<void,boost::_mfi::mf2<void,smtp_client::impl::detail::initialize_smtp_connection,boost::asio::error &,unsigned int>,boost::_bi::list3<boost::_bi::value<smtp_client::impl::detail::initialize_smtp_connection *>,boost::arg<1>,boost::arg<2> > >,void,boost::asio::error,unsigned int>::invoke(boost::detail::function::function_buffer & function_obj_ptr={...}, boost::asio::error a0={...}, unsigned int a1=38) Line 146 C++ basic.exe!boost::function2<void,boost::asio::error,unsigned int,_STL::allocator<void> >::operator()(boost::asio::error a0={...}, unsigned int a1=38) Line 682 + 0x2d C++ basic.exe!smtp_client::smtp_connection::handle_read(boost::asio::error & error={...}, unsigned int bytes_readed=38, boost::function<void __cdecl(boost::asio::error,unsigned int),_STL::allocator<void> > handler={...}) Line 48 C++ basic.exe!boost::_mfi::mf3<void,smtp_client::smtp_connection,boost::asio::error &,unsigned int,boost::function<void __cdecl(boost::asio::error,unsigned int),_STL::allocator<void> > >::operator()(smtp_client::smtp_connection * p=0x006d85b0, boost::asio::error & a1={...}, unsigned int a2=38, boost::function<void __cdecl(boost::asio::error,unsigned int),_STL::allocator<void> > a3={...}) Line 384 + 0x24 C++ basic.exe!boost::_bi::list4<boost::_bi::value<smtp_client::smtp_connection *>,boost::arg<1>,boost::arg<2>,boost::_bi::value<boost::function<void __cdecl(boost::asio::error,unsigned int),_STL::allocator<void> > > >::operator()<boost::_mfi::mf3<void,smtp_client::smtp_connection,boost::asio::error &,unsigned int,boost::function<void __cdecl(boost::asio::error,unsigned int),_STL::allocator<void> > >,boost::_bi::list2<boost::asio::error &,unsigned int &> >() Line 413 C++ basic.exe!boost::_bi::bind_t<void,boost::_mfi::mf3<void,smtp_client::smtp_connection,boost::asio::error &,unsigned int,boost::function<void __cdecl(boost::asio::error,unsigned int),_STL::allocator<void> > >,boost::_bi::list4<boost::_bi::value<smtp_client::smtp_connection *>,boost::arg<1>,boost::arg<2>,boost::_bi::value<boost::function<void __cdecl(boost::asio::error,unsigned int),_STL::allocator<void> > > > >::operator()<boost::asio::error,unsigned int>() Line 62 C++ basic.exe!boost::asio::detail::win_iocp_socket_service<_STL::allocator<void> >::receive_operation<boost::_bi::bind_t<void,boost::_mfi::mf3<void,smtp_client::smtp_connection,boost::asio::error &,unsigned int,boost::function<void __cdecl(boost::asio::error,unsigned int),_STL::allocator<void> > >,boost::_bi::list4<boost::_bi::value<smtp_client::smtp_connection *>,boost::arg<1>,boost::arg<2>,boost::_bi::value<boost::function<void __cdecl(boost::asio::error,unsigned int),_STL::allocator<void> > > > > >::do_completion_impl(boost::asio::detail::win_iocp_operation * op=0x006e45a8, unsigned long last_error=0, unsigned int bytes_transferred=38) Line 562 C++ basic.exe!boost::asio::detail::win_iocp_operation::do_completion() Line 59 + 0x14 basic.exe!boost::asio::detail::win_iocp_demuxer_service::run() Line 104 basic.exe!boost::asio::demuxer_service<_STL::allocator<void> >::run() Line 87 basic.exe!boost::asio::basic_demuxer<boost::asio::demuxer_service<_STL::allocator<void> > >::run() Line 107 basic.exe!_main() Line 62 basic.exe!mainCRTStartup() Line 259 + 0x19 C kernel32.dll!77e523cd() As you can see, the problem is within get_slots, exactly on this line: #if defined(BOOST_HAS_WINTHREADS) slots = static_cast<tss_slots*>( TlsGetValue(tss_data->native_key)); The disassembler shows me: #if defined(BOOST_HAS_WINTHREADS) slots = static_cast<tss_slots*>( TlsGetValue(tss_data->native_key)); 004DE3D9 mov eax,dword ptr [tss_data (5A8608h)] 004DE3DE mov ecx,dword ptr [eax+20h] 004DE3E1 push ecx 004DE3E2 call dword ptr [__imp__TlsGetValue@4 (5AB3B8h)] And failing on the 004DE3DE with an access to 0x00000020. Which means that it is reading tss_data as being 0. This is being executed inside a parsing of a spirit grammar. A static grammar that's accessed by two threads (on a dual core CPU). It always strikes on the last "job". I'm using asio and create 100 sockets, connect them to a SMTP and start receiving and sending SMTP commands (using spirit to parse the responses). Everything is done asynchronously and the demuxer is executed by two threads. I'm not very sure why tss_data is being seen as 0, and more strangely in the last message. But prior any returning thread. (The main joins the second thread, but is always the main thread that hits this). Any help would be greatly appreciated, Thanks in advance, -- Felipe Magno de Almeida

4 9

[thread] catch(...) removed
by Peter Dimov 26 Sep '06

26 Sep '06

I've taken the liberty of applying the patch at the end of this post to thread.cpp. When I was doing some work with boost::thread, I had to remove the catch(...) in my local copy because testing was a nightmare. Since then, I've been getting the M before thread.cpp every time I did a cvs update. The discussion about this catch(...) clause didn't end with a definitive decision one way or the other, so... let me be the one who actually does something about it. :-) Index: thread.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/thread/src/thread.cpp,v retrieving revision 1.21 diff -u -r1.21 thread.cpp --- thread.cpp 14 Jul 2005 15:46:50 -0000 1.21 +++ thread.cpp 6 Jul 2006 13:39:48 -0000 @@ -105,7 +105,7 @@ static OSStatus thread_proxy(void* param) #endif { - try +// try { thread_param* p = static_cast<thread_param*>(param); boost::function0<void> threadfunc = p->m_threadfunc; @@ -115,12 +115,12 @@ on_thread_exit(); #endif } - catch (...) - { -#if defined(BOOST_HAS_WINTHREADS) - on_thread_exit(); -#endif - } +// catch (...) +// { +//#if defined(BOOST_HAS_WINTHREADS) +// on_thread_exit(); +//#endif +// } #if defined(BOOST_HAS_MPTASKS) ::boost::detail::thread_cleanup(); #endif

7 10

Any interests in a template library for distributed message passing and event dispatching?
by Yigong Liu 25 Sep '06

25 Sep '06

Hello All, Is there any interests in libraries for distributed message passing and event dispatching? There are many aspects involved in the design of these systems, such as choosing proper message/event id types, routing/dispatching algorithms, synchronization strategies for routing data structures and remote connection transport, etc.. Various application domains present different requirements for performance and functionalities (in embedded systems, integers or sub-int (bit-fields) are used as ids and routing is based on registration table, while in the e-commerce applications, class/structs with key attributes can be used as ids to facilitate more advanced routings). I am working on a C++ template library for generic publish/subscribe called Channel. Channel's major components (message IDs, routing algorithms...) are configurable as template parameters. As a namespace shared by peer threads, channels support publish/subscribe scope control, message filtering, and translation. Channel is used the same way as we use STL containers; by instantiating Channel template with proper id type, id trait and routing algorithms, user can create customized message passing and event dispatching facility for a particular application. More documentations and code can be found at : http://channel.sourceforge.net Right now Channel is built on top of ACE (adaptive communication environment) to gain platform independence. Besides classes related to socket connections and message marshaling, most channel classes are quite platform independent. I am refactoring the code and move the platform dependent code into a few policy classes. I would like to know is there any interests in boost for such frameworks. If so, I'll be glad to present a boostified version of the framework for a review process and use existing boost classes for platform abstractions. Thanks Yigong

6 11

TR2 and C++0x heads up
by Beman Dawes 23 Sep '06

23 Sep '06

The C++ standards committee's Library Working Group has proposed a schedule for library changes and extensions: * October 2005: cutoff date for C++0x major library proposals * October 2006: cutoff date for library TR2 proposals * April 2007: cutoff date for C++0x library clean-up papers The usual rule-of-thumb is that new library components go in TR2, while changes to existing components go in C++0x. The LWG will consider exceptions to the rule on a case-by-case basis. The LWG is planning to issue a "Call for Proposals" with details, but in the meantime Boost developers might want to start thinking about which Boost libraries they want to propose to the LWG. Because most proposals go through one or more revisions before being accepted, it helps a proposal's chances if it reaches the committee as many meetings as possible before the final cut-off. So far there are plans to propose Boost.Threads, Boost.Filesystem, and Boost.Signals. As well as proposals for some of the more major libraries, I personally hope someone will do a sweep through Boost looking at some of the smaller utilities and helpers for a possible "Small Additions" proposal. --Beman

36 149

[shared_Ptr] [1.34] URGENT: Outstanding HP-UX / itanium bug
by John Maddock 12 Sep '06

12 Sep '06

Folks we still haven't solved the outstanding issue summarised here: http://lists.boost.org/boost-users/2005/12/15692.php Defining BOOST_SP_USE_PTHREADS is at least a workaround. Should I apply this to Boost.Config or should the sp_counted_base.hpp logic be altered (to keep everything in one place)? Or does anyone believe they have a fix for the assembly code in time for 1.34? Thanks, John.

7 21

[linear algebra] - question to David Abrahams
by Janek Kozicki 01 Sep '06

01 Sep '06

Hello, Not so long ago you have mentioned that you are working on a linear algebra library. I'm very interested in this topic, because I'm using such library in my project. I have looked into the vault but couldn't find this library. Can we have a sneak peek? Questions: 1. will your library provide functions useful when working with small vectors like: cross_product(), dot_product(), normalize() (scale vector so its length()==1), norm() (returns squared length), length(), etc... ? 2. will your library allow Boost.Quaternions to be extended in a way that those two libraries together will be useful for geometrical rotations? 3. will your library provide a way to solve equation Ax=b (A is matrix, b and x are vectors, and x is the unknown). The background for question 2 above: Author of Boost.Quaternions tried to extend the library with code that would allow geomtetrical rotations, but at that time only Boost.Ublas library was available. After some investigation he discovered that matrices and vectors from ublas are unsuitable for the task, and finally he gave up. Following functions would be needed: operator*(vector<3,T1>,quaternion<T2>) // most important from_rotation_matrix(matrix<3,3,T>) to_rotation_matrix() from_axis_angle(vector<3,T1> axis, T2 angle) to_axis_angle() to_euler_angles() and few others. Similar functionality is already in boost vault: directory "Math - Numerics", file Quaternion.h Without quaternion rotations this linear algebra library would be pretty useless for me, so I hope it'll be there :) -- Janek Kozicki |

9 20

boost::scoped_array::release?
by Ralf W. Grosse-Kunstleve 30 Aug '06

30 Aug '06

Does this patch for boost/scoped_array.hpp look useful? < T * release() // never throws < { < T * result = ptr; < ptr = 0; < return result; < } < It allows me to use boost::scoped_array almost like an auto_ptr: int* foo(size) { boost::scoped_array<int> result(new int[size]); // do something to result // if an exception is thrown result will be cleaned up return result.release(); } void bar() { boost::scoped_array<int> foo_result(foo(1000)); // code is still exception safe } I wouldn't need this if - we had std::auto_array (don't think it exists) - std::vector<int>(size) wouldn't do the default construction of all elements and I didn't care about having two pointers instead of just one (sometimes I actually do care) - boost::scoped_array::ptr was protected instead of private so that I could inherit and add release() Are there arguments for not adding release()? Cheers, Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

11 21

Boost regression notification (2005-10-26 [RC_1_33_0])
by Douglas Gregor 23 Aug '06

23 Aug '06

Boost regression test failures ------------------------------ Report time: 2005-10-26T14:54:08Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 82 failures in 3 libraries: parameter (1) range (3) serialization (78) |parameter| tutorial: gcc-2.95.3-linux |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_class_info_load_binary_archive: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_binary_archive_dll: borland-5_6_4 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_text_archive: borland-5_6_4 cw-8_3 cw-9_4 gcc-3_4_3-sunos mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_text_archive_dll: borland-5_6_4 cw-9_4 gcc-3_4_3-sunos intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_text_warchive: borland-5_6_4 cw-8_3 cw-9_4 gcc-3_4_3-sunos vc-7_0 test_class_info_load_text_warchive_dll: borland-5_6_4 cw-9_4 gcc-3_4_3-sunos intel-win32-8_1 vc-7_0 test_class_info_load_xml_archive: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_xml_archive_dll: borland-5_6_4 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_xml_warchive: borland-5_6_4 cw-8_3 cw-9_4 gcc-3_4_3-sunos vc-6_5 vc-7_0 test_class_info_load_xml_warchive_dll: borland-5_6_4 cw-9_4 gcc-3_4_3-sunos intel-win32-8_1 vc-6_5 vc-7_0 test_demo_xml_load: borland-5_6_4 gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-8_1 mingw-3_4_2 test_demo_xml_load_dll: borland-5_6_4 gcc-3_4_3-sunos gcc-4_0-darwin mingw-3_4_2 test_shared_ptr_132_text_warchive: intel-win32-8_1

7 11

Boost inspection notifications (RC_1_34_0)
by Rene Rivera 14 Aug '06

14 Aug '06

Boost Inspection Reports An inspection program <http://www.boost.org/tools/inspect/index.html> checks each file in the current Boost CVS for various problems, generating this as output. Problems detected include tabs in files, missing copyrights, broken URL's, and similar misdemeanors. This email is the common top email for the dated daily reports for the Boost 1.34.0 branch (RC_1_34_0). Please see the follow ups for the individual reports. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

3 50

Re: [boost] Exception Visitor
by Ames Andreas 12 Aug '06

12 Aug '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Alexander Nasonov > Sent: Friday, July 28, 2006 12:54 PM > Subject: Re: [boost] Exception Visitor > > Please, NO! > It's my experience that one catch(...) in a program may be a > source of many annoying glitches that users report > periodically but developers don't understand what's going on. > Removing this often helps. Users start reporting crashes. > Most difficult at this stage is to find a user who is able to > run Dr. Watson, check 'Create Crash Dump File' and send a > dump to developers :) > > Also worth noting that SEH is not standard C/C++. FWIW, I'd like to strongly second that. When catching SEH exceptions (like catch(...) does), predictable behaviour is only possible if you compile for 'asynchronous exception handling', which according to the docs increases the generated code size (I don't know about the runtime performance cost). If you compile for 'synchronous exception handling' (the more usual thing, I believe), you should either be prepared to live with bad cleanup of the stack or you install a global SEH-exception handler in each thread you start, which does nothing but rethrow and therefore crash the app. IMHO, that's nothing a library should impose on its apps. Anyway, I fail to see what's the benefit of catching segfaults _as the default behaviour_ (that's not to say there aren't applications that need to do). FWIW again, I won't use a solution which includes catch(...) anytime soon (and esp. not if it's done in a pervasive manner). cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 69 7505 3213 | ames AT avaya DOT com

5 6

[test] Buglet in floating point comparison code.
by John Maddock 11 Aug '06

11 Aug '06

I'm using Boost.Test, specifically BOOST_CHECK_CLOSE with non-built-in floating point types. In particular I have a type "real_concept" that models the concepts I want an arbitrary real number type to adhere to. This type does *not* specialise std::numeric_limits: deliberately so because I want to support types with whose precision varies at runtime. This causes a problem inside safe_fpt_division which uses std::numeric_limits without the check to see if it's specialised or not. In turn this causes almost all comparisons using real_concept to succeed because safe_fpt_division will almost always return 0 for real_concept. The obvious fix is simply to place the numeric_limits checks inside an if(std::numeric_limits<FPT>::is_specialized) block, and to perform no safety checks in this case and just go ahead and perform the division regardless (there are no checks that can be performed in this case anyway). Thanks, John.

3 12

[utility] nonconstructible
by Chris Weed 11 Aug '06

11 Aug '06

Hi, I think it would be nice to have a "nonconstructible" class to derive from similar to noncopyable. Recently I was burned by a traits class that was getting constructed. I think this should also be used for template metafunctions. I envision something like the following: struct nonconstructible { private: nonconstructible() {} } template<typename T> struct my_traits : nonconstructible { typedef int my_type; }; Chris

3 4

Sun-5.8 failures
by Gennaro Prota 10 Aug '06

10 Aug '06

Hi guys, among the various Sun CC failures that permeate our regression tests there's one which seems quite straightforward to fix (so it probably isn't :-)): the compiler claims ambiguity between test_tools::tt_detail::print_helper<char[1]> (const char(&)[1]) test_tools::tt_detail::print_helper<const char, 1>(const char(&)[1]) in "boost/test/test_tools.hpp". AFAICT, that's correct and we should fix the code between lines 377 and 389. -- [ Gennaro Prota, C++ developer for hire ]

6 22

Spurious warning in lexical_cast.hpp
by Joe Gottman 09 Aug '06

09 Aug '06

When I compile lexical_cast.hpp using MSVC 03 I get a spurious warning: warning C4701: local variable 'result' may be used without having been initialized. It comes from the following function: template<typename Target, typename Source> Target lexical_cast(const Source &arg) { typedef typename detail::array_to_pointer_decay<Source>::type NewSource; detail::lexical_stream<Target, NewSource> interpreter; Target result; if(!(interpreter << arg && interpreter >> result)) throw_exception(bad_lexical_cast(typeid(NewSource), typeid(Target))); return result; } Of course this code is perfectly safe, as either result will be initialized or an exception will be thrown. However, it would be nice if you can change this code to the following: template<typename Target, typename Source> Target lexical_cast(const Source &arg) { typedef typename detail::array_to_pointer_decay<Source>::type NewSource; detail::lexical_stream<Target, NewSource> interpreter; Target result; if(!(interpreter << arg && interpreter >> result)) { throw_exception(bad_lexical_cast(typeid(NewSource), typeid(Target))); static Target notused ; return notused; //We never get here, but some compilers require it to prevent an uninitialized variable warning } else { return result; } } That will remove the warning. There is similar code in boost::array. Joe Gottman

5 20

Boost's future, one big download?
by Steven Burns 09 Aug '06

09 Aug '06

When I read posts like "proposal: boost library for african insect classification" (joke) and things like that, I wonder what's going to happen to boost in the future. Some boost libraries are already too specific and this seems to be on the rise. Is boost going to be always a single download? Is boost's goal to become a "code wikipedia"? Thanks, Steven

5 4

Exception Visitor
by Jeremy Day 09 Aug '06

09 Aug '06

All, A message a few days ago, along with my current reading of the book 'C++ Template Metaprogramming', piqued my interest in the idea of an "exception visitor". I put together a little something, and I'm wondering if people might be interested in my (rather poor, at the moment) code. Problem: When using exceptions it is very easy to end up with code that looks something like this: try { //Some code that might throw exceptions. } catch(std::logic_error&) { //Handle the exception. } catch(std::exception&) { //Handle exception. } catch(...) { //Handle everything else } With my code you can transform the above into something along these lines: struct my_exception_handler { typedef boost::mpl::vector<std::logic_error, std::exception> exceptions; void operator()(std::exception& oError) { std::cout << "my_exception_handler::operator()(std::exception&)" << std::endl; } void operator()(std::logic_error& oError) { std::cout << "my_exception_handler::operator()(std::logic_error&)" << std::endl; } void operator()(void) { std::cout << "my_exception_handler::operator()(void)" << std::endl; } }; //Application code. try { //Some code that might throw exceptions, such as: throw std::logic_error("A sample logic error."); } catch(...) { //Magic happens here. catcher(my_exception_handler()); //This prints out "my_exception_handler::operator()(std::logic_error&)" } If anyone is interested I will post what I have for critique (I'm a relative newbie with MPL, so I will likely need a lot of help). I look forward to any and all comments. Jeremy

7 11

Inspect Tool Update (was: Boost regression testing status)
by Gennaro Prota 07 Aug '06

07 Aug '06

On Fri, 28 Jul 2006 02:19:38 +0200, Gennaro Prota <gennaro_prota(a)yahoo.com> wrote: >On Thu, 27 Jul 2006 14:23:31 -0500, Rene Rivera ><grafikrobot(a)gmail.com> wrote: > >>It's the false negatives that are worrisome. For example: >> >>const char * x = "//foo"; int x = min(10,20); >> >>Not that I think anyone would write such code. But strange things do >>happen :-) > >Yep. I have just committed a major update to the inspect tool. Besides some fixes and improvements there's a *cautious* attempt to avoid false positives with min/max invocations. Basically, if min and max appear in a line beginning with "//" they are ignored, unless the presence of a quote or of a "*/" sequence makes the case dubious (resolving such a doubt would require scanning ahead/behind, to other lines, which is a bit uneasy with the current code and probably overkill anyway). In short, if you have something like: /* * This is a formula: * * result = min { X, Y } * ... */ it's enough to rewrite the min line as // * result = min { X, Y } to avoid spurious "detections". Changes have only been committed to the HEAD. All log messages (edit summaries) belonging to this update begin with "Inspect Tool Update" to ease future merge to the RC_1_34_0 branch. More changes may follow, with the same edit summary convention. -- [ Gennaro Prota, C++ developer for hire ]

1 1