April 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

[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

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

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

Patch for smart pointers assignation of plain pointers
by Pierre THIERRY 15 Jun '06

15 Jun '06

It seems to me that smart pointers could have the same semantics that plain pointers have (it's also the orientation taken by other smart pointers, like those in Glibmm). Here is my proposed patch against CVS HEAD: Index: boost/scoped_ptr.hpp =================================================================== --- boost/scoped_ptr.hpp.orig +++ boost/scoped_ptr.hpp @@ -101,6 +101,12 @@ return *this; } + scoped_ptr & operator=(T * rhs) + { + this_type(rhs).swap(*this); + return *this; + } + T * get() const // never throws { return ptr; Index: boost/shared_ptr.hpp =================================================================== --- boost/shared_ptr.hpp.orig +++ boost/shared_ptr.hpp @@ -246,6 +246,12 @@ #endif // BOOST_NO_SFINAE, BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION + shared_ptr & operator=(T * r) + { + this_type(r).swap(*this); + return *this; + } + #endif // BOOST_NO_AUTO_PTR #if !defined(BOOST_MSVC) || (BOOST_MSVC >= 1300) Regards, Nowhere man -- nowhere.man(a)levallois.eu.org OpenPGP 0xD9D50D8A

2 5

boost::typeof, MSVC7.1 & 8.0, and precompiled headers
by Bertrand Augereau 10 Jun '06

10 Jun '06

Hello to all, I just wanted to let you know that boost::typeof doesn't work (in today CVS) when included in a precompiled header with recent MSVC, because of a (seemingly common in other boost libs) anonymous-namespace error. I'm waiting for boost::typeof to work like a charm in MSVC8 so that I can ditch the evil-hack MSVC7 typeof implementation and migrate to MSVC8 :) Thanks, Bertrand PS : Arkadiy, I took the liberty to CC you because you were the one who pointed me to boost::typeof on clc++m and you seem to be in charge for this :)

4 14

Re: [boost] [multi_index]terminology/design concern
by JOAQUIN LOPEZ MU?Z 21 May '06

21 May '06

----- Mensaje original ----- De: Gennadiy Rozental <gennadiy.rozental(a)thomson.com> Fecha: Miércoles, Abril 12, 2006 8:41 pm Asunto: Re: [boost] [multi_index]terminology/design concern Joaquín wrote: > > From your description above, seems to me what you understand > > as an "order" is verily what the index concept (as used in > > Boost.MultiIndex) tries to model. Basically, an index is > > an access interface to a set of objects jointly owned > > by several other indices --in contrast with regular STL > > containers who own their elements in an exclusive fashion. > > > > [...] > > > "Order" would be a good candidate, except that it's generally > > tied to fixed-order containers (sets, maps), and > > Boost.MultiIndex also includes sequence-like constructs. > > I do not see a problem with term "Order". You could have > mulit_order_container. While STL present single order ones. As I said, I'm reluctant to name sequenced indices as "orders", since it is precisely the lack of any fixed order that defines them. Besides, the differences between index interfaces are huge, and referring to them collectively as orders tends to blur (IMHO) these differences, as if the interfaces were homogeneous, which they aren't. Anyway, names were already chosen, published, and pretty much cast in stone when the library was first released in 2004. Back then, this conversation could have had more practical implications, right now I can only concede/deny your points, but no name change is likely to occur. > > > > I'm afraid I'm not quite getting what you mean by "index" > > in this context. Certainly, the kind of operations you describe > > Index is something that provided direct (constant-time) access > somewhere > within selected order. > > > can be performed in Boost.MultiIndex by means of so-called > > "compatible keys" as described in http://tinyurl.com/rouet, > > I am not sure how this is related. > > > so that, for instance, given an ordered index sorted by > > (last name, first name) one can jump to the records > > beginning with some given last name. Is this what you're > > referring to? > > Essencially. The same way as book index allows to jump to proper > page based > on keyword. Could you show some code example? What I want is to > iterate > through all persons with last name "Smith". All operations should > have > contant complexity. So, if your multi-index container is defined like this: typedef multi_index_container< address, indexed_by< ordered_non_unique< // (last_name,first_name) index composite_key< address, member<address,std::string,&address::last_name>, member<address,std::string,&address::first_name> > > ... // other indices > > address_book_t; address_book_t b; then you can write the following: void list(const std::string& last_name) { std::pair<address_book_t::iterator,address_book_t::iterator> p= b.equal_range(last_name); std::copy( p.first,p.second, std::ostream_iterator<address>(std::cout)); } You require that all ops are constant complexity, which is not entirely fulfilled by my example, since equal_range is O(log n). On the other hand, I cannot see why your indexing concept must guarantee constant complexity and not only fast lookup. > > If so, the only thing I can say is I never > > thought of these operations as directly related to an > > index concept. If you could elaborate on your discussion > > maybe I'll be seeing your point more clearly. > > > > Thanks for discussing your concerns, I hope at least I've > > shed some light on them. > > IMO we need another level of indirection that would support Index > within an > Order concept. I do not see how existing design could handle this. > If the need for the kind of bookmarking (allow me to use this term so as to not mix the different meanings we're giving to the word "index") you describe is sufficiently general, such a facility can be built separately from B.MI itself (like a standalone view-like library) or integrated into B.MI as an index decorator: typedef multi_index_container< element, indexed_by< bookmarked< ordered_unique<...> > ... > > So, the bookmarked<...> construct can embed any preexistent index ("order" in your terminology) type and supplement it with bookmarking facilities, provided we had a precise definition of what bookmarking boils down to. This kind of stuff can be done within the current design, but then again I yet fail to see how what you describe is a general need not sufficiently covered by current facilities, like for instance compatible keys in ordered indices --clarification here most welcome. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 4

[optional] boost/bind/apply.hpp bad interaction
by Daniel Wallin 20 May '06

20 May '06

#include <boost/bind/apply.hpp> #include <boost/optional.hpp> Results in: dev/boost/boost/optional/optional.hpp: In member function 'void boost::optional_detail::optional_bas e<T>::construct(const Expr&, const boost::in_place_factory_base*)': dev/boost/boost/optional/optional.hpp:309: error: invalid use of 'struct boost::apply<T>' On GCC4.0.2. The offending line is: factory.BOOST_NESTED_TEMPLATE apply<value_type>(m_storage.address()) ; A simple fix is to move the apply() call out of the boost namespace. The attached patch fixes the problem. OK to commit? -- Daniel Wallin Index: optional.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/optional/optional.hpp,v retrieving revision 1.9 diff -u -r1.9 optional.hpp --- optional.hpp 10 Feb 2006 20:52:25 -0000 1.9 +++ optional.hpp 18 Mar 2006 11:40:32 -0000 @@ -76,6 +76,16 @@ #define BOOST_OPTIONAL_WEAK_OVERLOAD_RESOLUTION #endif +namespace boost_optional_construct +{ + + template <class T, class Factory> + void construct(Factory const& factory, void* address) + { + factory.BOOST_NESTED_TEMPLATE apply<T>(address); + } + +} // namespace boost_optional_construct namespace boost { @@ -295,7 +305,9 @@ void construct ( Expr const& factory, in_place_factory_base const* ) { BOOST_STATIC_ASSERT ( ::boost::mpl::not_<is_reference_predicate>::value ) ; - factory.BOOST_NESTED_TEMPLATE apply<value_type>(m_storage.address()) ; + boost_optional_construct::construct<value_type>( + factory, m_storage.address() + ); m_initialized = true ; }

2 1

[SoC] multi precision arithmetic library proposal.
by Mateusz Rukowicz 11 May '06

11 May '06

Hi, I would like to participate in summer of code 2006. I was very surprised that boost doesn't have multi precision arithmetic, and since I'm quite algorithm/C++ concerned, I wish to propose/make it as a SoC project. I'll appreciate any response about that idea, what do you feel about that etc. Best regards, Mateusz Rukowicz.

12 32

Problem with shared_ptr in MSVC8.0 (only when compiled in /clr mode ?)
by Loïc Joly 10 May '06

10 May '06

Hello everybody, In boost::shared_ptr, there is a trick to get a type convertible to bool that is not a bool... unspecified_bool_type is a function pointer. However, with MSVC8.0, and at least when I compile with /clr, I seem to have some problem with it : The null fct ptr seems to be coded 0xffffffff. That is just fine in non /clr compilation, where it gets evaluated as false when converted in boolean. But in /clr mode, it is converted to true. I guess this is a problem with the compiler, but would it not be possible to use a not so clever unspecified_bool_type with this compiler as a work-around ? Best regards, -- Loïc

2 5

[intrusive_ptr] atomic ref counting?
by Eric Niebler 09 May '06

09 May '06

I'm thinking about replacing some uses of shared_ptr with intrusive_ptr, but I've got questions. One of the nice things about shared_ptr is the lock-free thread-safe ref counting. I want my intrusive_ptr to have the same safety and efficiency, but I don't see how to get it. I see $boost_root/detail/atomic_count.hpp, but shared_ptr doesn't use it. Why not? And why is it in detail/? Should I not consider using it? Taking in the bigger picture, intrusive_ptr requires people to write their own add_ref and release functions, most of which will probably end up using ++ and -- on a plain integer. This is totally broken in multi-threaded applications, right? Isn't it dangerous to not provide complementary utilities for correctly managing reference counts? It seems to me intrusive_ptr is impossible to use safely and portably. What have I missed? -- Eric Niebler Boost Consulting www.boost-consulting.com

4 13

[asio] Draft version uploaded to vault
by Christopher Kohlhoff 08 May '06

08 May '06

Hello all, I have just uploaded a draft version of Boost.Asio to the vault (in the "Input - Output" folder). I'm particularly interested in feedback on the handler-based custom memory allocation and IPv4/v6 protocol independence. Please note: this is not a properly tested release. Caveat emptor. It has the following known issues: - It uses getaddrinfo/getnameinfo, but these functions are not thread-safe on Mac OS X. They will be replaced by thread-safe emulation using getipnodebyname and getipnodebyaddr. - Although builds using MSVC or Borland C++ automatically emulate getaddrinfo/getnameinfo on Windows 2000 and earlier, MinGW does not. Therefore MinGW currently only supports Windows XP and Windows Server 2003 targets. - It has not been compiled or tested at all on Solaris. It has been tested on Mac OS X 10.4, Debian Sarge with 2.6 linux kernel and Windows XP. Cheers, Chris Changes since 0.3.6 =================== (Excluding minor bug fixes and in no particular order.) * Renamed demuxer to io_service. * All services inherit from a common base io_service::service. As part of this change, the demuxer::get_service() member template function has been replaced with three free template functions: use_service(), add_service() and has_service(). * Resource classes inherit from basic_io_object. Sockets, timers, etc inherit from basic_io_object<Service>. This class automatically obtains the correct service object from the io_service, and provides the typedefs and functions that all objects must provide (e.g. an io_service() member function for obtaining the associated io_service object). * All handler objects destroyed during io_service destruction. Previously, if you did not allow demuxer::run() to continue until it had no more work to do, and then destroyed the demuxer, uninvoked handlers would never be destroyed. All stored handler objects that are "owned" by the io_service or any associated services are now destroyed automatically from inside the io_service. This allows quick, clean shutdown of programs using io_service::interrupt(). This handler cleanup has been implemented using "two-phase" service shutdown. Every service that inherits from io_service::service must implement a virtual function called shutdown_service(). The service's implementation of this function is required to destroy all copies of handlers that it owns (directly or indirectly). The cleanup must be done in a separate phase prior to the destruction of the service objects, since the handler destructors may try to access other services. * Renamed locking_dispatcher to strand. A strand is defined as a strictly sequential invocation of event handlers (i.e. no concurrent invocation). Use of strands allows execution of code in a multithreaded program without the need for explicit locking (e.g. using mutexes). Strands may be either implicit or explicit, as illustrated by the following alternative approaches: - Calling io_service::run() from only one thread means all event handlers execute in an implicit strand, due to the io_service's guarantee that handlers are only invoked from inside run(). - Where there is a single chain of asynchronous operations associated with a connection (e.g. in a half duplex protocol implementation like HTTP) there is no possibility of concurrent execution of the handlers. This is an implicit strand. - An explicit strand is an instance of asio::strand. All event handler function objects need to be wrapped using asio::strand::wrap() or otherwise posted/dispatched through the asio::strand object. * Add macros to disable platform-specific implementations. The following macros can be used to disable platform-specific implementation code and revert to portable select-based asynchronous I/O emulation: - BOOST_ASIO_DISABLE_EPOLL - BOOST_ASIO_DISABLE_IOCP - BOOST_ASIO_DISABLE_KQUEUE * Handler-based custom memory allocation. Many asynchronous operations need to allocate an object to store state associated with the operation. For example, the Win32 implementation needs OVERLAPPED-derived objects to pass to Win32 API functions. Furthermore, programs typically contain easily identifiable chains of asynchronous operations. A half duplex protocol implementation (e.g. an HTTP server) would have a single chain of operations per client (receives followed by sends). A full duplex protocol implementation would have two chains executing in parallel. Programs should be able to leverage this knowledge to reuse memory for all asynchronous operations in a chain. Given a copy of a user-defined Handler object h, if asio needs to allocate memory associated with that handler it will execute the code: void* pointer = asio_handler_allocate(size, &h); Similarly, to deallocate the memory it will execute: asio_handler_deallocate(pointer, &h); These functions are located using ADL. The asio library provides default implementations of the above functions in the global namespace: void* asio_handler_allocate(size_t, ...); void asio_handler_deallocate(void*, ...); which are implemented in terms of ::operator new() and ::operator delete() respectively. The implementation guarantees that the deallocation will occur before the associated handler is invoked, which means the memory is ready to be reused for any new asynchronous operations started by the handler. Custom memory allocation support is not yet used throughout the asio implementation. In particular, the reactor-based emulation still uses dynamically allocated objects. It is fully implemented for the Win32-specific I/O completion port code. The custom memory allocation support has also been disabled for Borland C++, since it generated obscure compiler errors. See libs/asio/example/allocation/server.cpp for an example of how to use the handler-based custom memory allocation. * Allocator template parameter removed. Removing the Allocator template parameter reduces the number of core types in asio and makes it easier to develop custom services (i.e. you don't have to worry what Allocator object the io_service has been templated on). It should also make it simpler to create a shared or static library-based implementation. A combination of handler-based custom memory allocation, and the ability for the asio implementation to embed objects directly into object internals (e.g. socket implementations), should minimise dynamic memory allocations. If there is a demonstrable need, I may consider adding an io_service::service-based allocator to allow memory allocation to be further customised on a per-io_service-object basis. * Add support for building without thread support. POSIX platforms only. The Windows implementation still requires threads. * Async waits cancelled by deadline_timer expires_*() setters. Outstanding asynchronous wait operations are now automatically cancelled if you call expires_at() or expires_from_now() to modify the expiry time of a deadline_timer. The previous documented behaviour was that it was "undefined" to modify the expiry time while there were outstanding waits. * Support for reference-counted buffers. The Const_Buffers and Mutable_Buffers concepts have been modified to allow reference counted buffers to be used. In particular: - The {Const|Mutable}_Buffers::iterator typedef and non-const begin()/end() functions have been removed from the concepts' requirements. Implementations of the concepts now need only provide const_iterator support, and do not need to allow in-place modification of the elements. - The asio implementation guarantees that at least one copy of the buffers object will be maintained for as long as the system may need access to the data. - The asio implementation explicitly converts the dereferenced const_iterator into mutable_buffer or const_buffer as needed. See the libs/asio/example/buffers/reference_counted.cpp example program. * Strongly-typed socket classes. Rather than asio::stream_socket, asio::datagram_socket and asio::socket_acceptor classes that were used for all protocols, these socket classes are now specific to each protocol. For example, we now have: ip::tcp::socket ip::tcp::acceptor ip::udp::socket and in the future we might have: unix::stream_protocol::socket bluetooth::rfcomm::socket and so on. These protocol-specific classes are simply typedefs for templates instantiated on the corresponding Protocol class. E.g.: template <typename Protocol> class stream_socket_service; template <typename Service> class basic_stream_socket; class tcp { ... typedef stream_socket_service<tcp> socket_service; typedef basic_stream_socket<socket_service> socket; ... }; New protocols can be added by creating classes like tcp above. * Use inheritance in socket types to prevent "layer violations". The basic_stream_socket and basic_datagram_socket templates now inherit from basic_socket<Service>. This class includes all functions that are common to stream and datagram sockets (everything except send/receive and friends). Stream layers such as ssl::stream return a reference to basic_socket<> from the lowest_layer() function. * IPv4 and IPv6 protocol independence. Socket, endpoint and address classes for IP (i.e. TCP and UDP) are independent of the particular IP version (4 or 6) used. The ipv4 namespace has been removed. For example: - The ipv4::address class has become IP version-independent ip::address. If you need to manipulate addresses for a specific IP version use ip::address_v4 or ip::address_v6. - The protocol classes are now ip::tcp and ip::udp, and the corresponding endpoint types are ip::tcp::endpoint and ip::udp::endpoint. - To open a socket you must specify the protocol version, e.g.: ip::tcp::socket socket(io_service); ... socket.open(ip::tcp::v4()); // IPv4 ... socket.open(ip::tcp::v6()); // IPv6 Note: if you already have an endpoint you can avoid this by using the protocol associated with the endpoint object: socket.open(endpoint.protocol()); - When constructing an endpoint with just a port number, you must specify the IP version: ip::tcp::endpoint(ip::tcp::v4(), 12345); The development of programs that are independent of the IP version is further aided by the new resolver interface outlined below. * Resolver replaces ipv4::host_resolver. The ipv4::host_resolver and ipv4::host classes have been removed in favour of an endpoint-oriented interface that can support different protocols. The functionality of this new interface is based on getaddrinfo and getnameinfo. Use the resolver by constructing a query, calling resolve() (or async_resolve()), and using the returned forward-only iterator to enumerate the endpoints that match the query. For example: ip::tcp::resolver resolver(io_service); ip::tcp::resolver::query query("foobar.com", "http"); ip::tcp::resolver::iterator iter = resolver.resolve(query); ip::tcp::resolver::iterator end; while (iter != end) { ip::tcp::endpoint ep = *iter; std::cout << iter->endpoint() << std::endl; std::cout << iter->host_name() << std::endl; std::cout << iter->service_name() << std::endl; ++iter; } The asynchronous equivalent is: void my_class::start_resolve() { ip::tcp::resolver resolver(io_service); ip::tcp::resolver::query query("foobar.com", "http"); resolver.async_resolve(query, boost::bind(&my_class::resolve_handler, this, asio::placeholders::error, asio::placeholders::iterator)); } void my_class::resolve_handler(const asio::error& e, ip::tcp::resolver::iterator iter) { if (!e) { ip::tcp::resolver::iterator end; while (iter != end) { ... ++iter; } } } There are overloads of resolve()/async_resolve() that take an endpoint and return an iterator. These are intended for reverse lookups. Since the ipv4::host_resolver had a local_host() function that returned information about the local system, a new function ip::host_name() has been added which returns a string containing the name of the system. * Multicast socket options renamed. The IP-specific socket options for multicast have been renamed. They are now also independent of the IP version. The name changes are: - add_membership is now join_group - drop_membership is now leave_group - time_to_live is now hops These multicast socket options are now found in the ip::multicast namespace. * String-to-address conversion now uses from_string function. This change was driven by three things: - The need to indicate an error without throwing if a conversion from string to address fails. - String literal addresses would not be common and so support for them does not need to be convenient. - It is more common to use a resolver to convert strings into complete endpoints. To convert a string into an address you would now write: ip::address address = ip::address::from_string("1.2.3.4"); which throws an asio::error on failure, or: asio::error error; ip::address address = ip::address::from_string( "1.2.3.4", asio::assign_error(error)); to convert without throwing. Similar functions exist on the ip::address_v4 and ip::address_v6 classes. * IPv4 and IPv6 addresses can be converted to and from bytes. The ip::address_v4 and ip::address_v6 classes contain: - A typedef called bytes_type, which is a boost::array<unsigned char, N>. For IPv4, N is 4. For IPv6, N is 16. - A constructor that takes a bytes_type value. - A function to_bytes() that returns a bytes_type value. * Order of endpoint constructor params reversed. The old ipv4::tcp::endpoint class (and udp equivalent) had a constructor that took a port and address in that order. The new ip::tcp::endpoint and ip::udp::endpoint classes have the order reversed, since that is more idiomatic. * Change position of flags param on send_to, receive_from. The order of parameters on the basic_datagram_socket's send_to, async_send_to, receive_from and async_receive_from functions have been changed to put the endpoint before the message flags. Overloads of these functions have been added that do not include the flags parameter, which gives the flags a default value of 0. A similar change has been made for the send, async_send, receive and async_receive functions on basic_datagram_socket and basic_stream_socket. * Don't globally block SIGPIPE if an alternative is available. On Linux, the MSG_NOSIGNAL flag is now passed to the sendmsg function. On Mac OS X, the SOL_SOCKET/SO_NOSIGPIPE socket option is set on all sockets when they are created. The SIGPIPE signal is globally ignored on Solaris. * Reactor implementations run operations until complete. The reactor socket implementation sets non-blocking I/O for asynchronous emulation (non-blocking mode is enabled for a socket the first time an async call is made on that socket). Operations are now restarted automatically if the asynchronous operation returns would_block or try_again, meaning that asynchronous operations are guaranteed never to return these errors. Changes planned for 0.3.7 ========================= * Fix tutorials/examples to not use "C style" code. * Emulation of getaddrinfo/getnameinfo on platforms where it is unavailable or broken. Changes planned for post-0.3.7 ============================== * Iostreams support. * Split_error handler function object. * Overloads of io_service::run() that take a timeout parameter. This is to allow calls to run() to be interleaved with other application code. The run() function will return an enum value indicating why it finished (e.g. timed_out, out_of_work, interrupted, etc). * Polymorphic wrapper for the Dispatcher concept. * Polymorphic wrapper for the Stream concept. * Investigate handler-invocation hooking. * Develop a performance test framework. * Rework reactor implementations to support handler-based custom memory allocation. * New reactor implementations, e.g. /dev/poll and Solaris 10 ports. * Use the Windows API call ConnectEx where available for true asynchronous socket connect operations. * Add better support for line-based protocols. This might take the form of an {async_}read_line function or equivalent. * Add UNIX domain socket support. * Documentation, documentation, documentation. I hope that's everything!

5 10

[SoC-2006] Associative containers...
by Rene Rivera 04 May '06

04 May '06

To Whomever added the " Associative containers specialized for low memory footprint and fast lookup" item to the project list <http://tinyurl.com/lprgp>. I curious which containers in particular you have in mind? I'm asking because I'm working on such a container, both for myself and for Boost, bjam, and binutils/ld/bfd. The particular container is the radix tree <http://en.wikipedia.org/wiki/Radix_tree>. -- -- 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 2

[serialization] Serialisation/deserialisation of floating-point values
by Paul Giaccone 03 May '06

03 May '06

I'm having problems with deserialising floating-point (double) values that are written to an XML file. I'm reading the values back in and comparing them to what I saved to ensure that my file has been written correctly. However, some of the values differ in about the seventeenth significant figure (or thereabouts). I thought Boost serialization used some numerical limit to make sure that values are serialised exactly to full precision, so what is happening here? Example: Value in original object, written to file: 0.0019075645054089487 Value actually stored in file (by examination of XML file): 0.0019075645054089487 [identical to value written to file] Value after deserialisation: 0.0019075645054089489 It looks like there is a difference in the least-significant bit, as examining the memory for these two values gives: Original value: b4 83 9b ca e7 40 5f 3f Deserialised value: b5 83 9b ca e7 40 5f 3f (where the least-significant byte is on the left) Note the difference in the first bytes. I'm using Boost 1.33.1 with Visual Studio 7.1.3088 in debug mode. Paul

14 59

[MPL] bug in quote.hpp?
by Jaakko Järvi 03 May '06

03 May '06

Hi, Starting from line 61: template< typename T, bool has_type_ > struct quote_impl // GCC has a problem with metafunction forwarding when T is a // specialization of a template called 'type'. # if BOOST_WORKAROUND(__GNUC__, BOOST_TESTED_AT(4)) \ && BOOST_WORKAROUND(__GNUC_MINOR__, BOOST_TESTED_AT(0)) \ && BOOST_WORKAROUND(__GNUC_PATCHLEVEL__ BOOST_TESTED_AT(2)) There seems to be a comma missing from the last line, before BOOST_TESTED_AT(2), is that right?

2 2

Graph library concept check problem
by Matthias Troyer 03 May '06

03 May '06

Hi, Trying to compile our ALPS project sources (http://alps.comp- phys.org) with the CVS HEAD I encountered a number of problems with the BGL concept checking. In particular on MacOS X, using the Apple g+ + 4.0.1, I encounter problems in depth_first_search.hpp with: template <class Visitor, class Graph> class DFSVisitorConcept { public: void constraints() { function_requires< CopyConstructibleConcept<Visitor> >(); vis.initialize_vertex(u, g); vis.start_vertex(u, g); vis.discover_vertex(u, g); vis.examine_edge(e, g); vis.tree_edge(e, g); vis.back_edge(e, g); vis.forward_or_cross_edge(e, g); vis.finish_vertex(u, g); } private: Visitor vis; Graph g; typename graph_traits<Graph>::vertex_descriptor u; typename graph_traits<Graph>::edge_descriptor e; }; Somehow this tries to instantiate a default constructor for the visitor and the graph. Since some graph types do not have a default constructor and no default constructor should actually be required, I want to ask whether this is a bug in the compiler or in the concept checks? Matthias

3 4