August 2005 - Boost - lists.boost.org

[intel-9.0] --arg_dep_lookup, BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL and __EDG_VERSION__=304
by JOAQUIN LOPEZ MU?Z 04 Sep '05

04 Sep '05

A bit of context: * Intel 9.0 has __EDG_VERSION__==304 (under Win32/Linux), whereas prior versions of the compiler have lower values of this macro. * BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL is defined for __EDG_VERSION__<=303, that is, for all Intel compilers up to (and including) 8.1, under Win32/Linux. * Under Win32, all Intel toolset .jams define the compiler option --arg_dep_lookup, which explicitly enables ADL (disabled by default.) I don't know what the situation of ADL is for Intel under Linux, but in any case this switch is *not* used for that OS. Current RC tests for Intel 9.0 under Linux show the problem listed at http://tinyurl.com/8f5g6 One piece of code where the error pops up is like this #if defined(BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL) ::boost::multi_index::detail::swap(i1,get<1>(es2)); #else using std::swap; swap(i1,get<1>(es2)); #endif Given the __EDG_VERSION__ number of this compiler, it is the second preprocessor branch that is compiled, and it fails to use the user-supplied global swap() in favor of std::swap(), hence the error. However, this same tests succesfully passes for Intel 9.0 under Win32 (same __EDG_VERSION__ as the Linux case)!! My conclusions: * The fact that the test passes under Intel 9.0 for Win32, for which BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL is *not* defined, suggests that __EDG_VERSION__<=303 is the right check for setting this macro. * But the same test fails under Intel 9.0 for Linux, which hints at an ADL problem other than that controlled by BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL. Could it be that Intel compilers under Linux also necessitate the --arg_dep_lookup compiler switch (which is currently not set)? This looks like the only sensible conslusion from the facts described. Thanks and sorry for the long post, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 5

[1.33.1] Goals, tasks, schedule
by Doug Gregor 03 Sep '05

03 Sep '05

Certain issues that cropped up with the 1.33.0 release that necessitate a 1.33.1 release. 1.33.1 will be for safe bug fixes to 1.33.0 only, focusing on critical issues such as the already-addressed shared_ptr problem. There are two major issues we need to resolve before we can roll a release candidate of 1.33.1: - Include order dependencies in the Serialization library - GCC 4.0 type_info problems This is also a good opportunity to work in support for three compilers that are performing reasonably well now and should be supported by Boost: - Tru64 CXX - Apple GCC 4.0 on Tiger - Intel 9.0 on Linux We'll prepare the release candidate from the RC_1_33_0 branch, hopefully within a week or so, depending on the resolution of these issues. The release candidates will be available for much longer before the final release, up to a month or so, to root out any remaining issues. No new libraries or features may be added to the RC_1_33_0 branch; they should go onto the main branch, and we'll merge fixes from RC_1_33_0 back once we've released. Doug

14 21

[Thread] read_write_mutex bug?
by Matt Hurd 03 Sep '05

03 Sep '05

Hi, Testing my own wrapper on x86_64 bit linux exposed a seeming deadlock on constructing a read_write_lock with a *::write_locked initial state in the constructor... I've distilled it to the plain code below that exhibits the same failure. Using a read_lock state on the same works without deadlock (or safety is this case) as expected. Using a scoped_write_lock worked once but deadlocked mostly. A normal mutex and recursive mutex works as expected. I'm using 1.33. Is this a known bug or am I using the read_write stuff incorrectly? Regards, Matt. matthurd(a)acm.org ____________________________________ my test in question:... void synch_test_019() { static int global_count = 0; static boost::read_write_mutex doobie( boost::read_write_scheduling_policy::writer_priority ); long number_of_threads = 10; static long inner_loop = 1000; ZOMOJO_WORKER_THREAD_BEGIN( inner_loop ) { boost::read_write_mutex::scoped_read_write_lock lk(doobie, boost::read_write_lock_state::write_locked); global_count = global_count + 1; } ZOMOJO_WORKER_THREAD_END( number_of_threads ) BOOST_MESSAGE( "orderly progression = " << inner_loop * number_of_threads ); BOOST_MESSAGE( "concurrent progression from this run = " << global_count ); BOOST_CHECK_PREDICATE(std::equal_to<int>(), (global_count)( inner_loop * number_of_threads) ); } _________________________________________________ The helper macros _________________________________________________ #ifndef ZOMOJO_THREAD_TEST_HELPER_HPP_20050816 #define ZOMOJO_THREAD_TEST_HELPER_HPP_20050816 // A poor man's barrier helper to assist in unit test cases for parallel execution #define ZOMOJO_WORKER_THREAD_BEGIN( LoopIterations ) \ static boost::read_write_mutex m_arbitrary_( boost::read_write_scheduling_policy::writer_priority ); \ struct simple_function_arbitrary_ \ { \ static void do_work_arbitrary_() \ { \ boost::read_write_mutex::scoped_read_lock lk_arbitrary_(m_arbitrary_); \ for (int j_arbitrary_ = 0; j_arbitrary_ < (LoopIterations); j_arbitrary_++) \ { #define ZOMOJO_WORKER_THREAD_END( NumberOfThreads ) \ } \ } \ }; \ \ boost::thread_group pool_arbitrary_; \ \ { \ boost::read_write_mutex::scoped_write_lock lk(m_arbitrary_); \ for (int i_arbitrary_=0; i_arbitrary_ < NumberOfThreads; ++i_arbitrary_) \ { \ pool_arbitrary_.create_thread( simple_function_arbitrary_::do_work_arbitrary_ ); \ } \ } \ \ pool_arbitrary_.join_all(); #endif // ZOMOJO_THREAD_TEST_HELPER_HPP_20050816

4 10

asio networking proposal
by Christopher Kohlhoff 02 Sep '05

02 Sep '05

As discussed in the "surveying async network io libraries" thread, I'd like to turn asio (asio.sourceforge.net) into a proposal for a boost networking library. As promised, here is a list of areas where asio could use some refinement. I'd appreciate input on: - What people think of the relative importance of the items. For example, what would be required for an initial implementation vs what could or should be left until a later revision. - Whether the proposed changes are of any value. - Any other things that should be on the list. What's Missing ============== * Asynchronous DNS operations. I think it would be reasonable to say that any operation that can block should have an asynchronous equivalent. Should these operations be cancellable (not necessarily portably implementable anyway)? * IPv6 support. I have no experience with IPv6, so it would be great if someone with experience could help out with the design here. * Asynchronous socket close. In certain circumstances closing a socket can block, so it would be reasonable to expect an asynchronous close operation. * Scatter-gather operations (sendv and recvv). * The BSD socket functions sendmsg/recvmsg (which I believe are necessary to support protocols such as SCTP). * SSL/TLS and DTLS support. This would require an external library, and how does that fit in with boost? * Other protocols (PF_UNIX, ...)? * Some type of integration (or support for) a higher-level iostreams-based socket library. * More examples. * Documentation on design and rationale. What Should Be Included and What Shouldn't ========================================== * Obviously asio::thread should not be part of a boost proposal, since that functionality is already covered by Boost.Thread. * The asio::time class should probably not be included, and wherever it's used replaced by Boost.Date-Time. Naming and Structure ==================== * The use of the word "Stream" can be confusing because its existing association in C++ with iostreams. Can anyone suggest an alternative? * Should stream_socket and dgram_socket be merged into a single socket class? There other types of sockets (e.g. sequenced packet) that would require additional classes if the current approach is retained. This would not be required if the BSD socket APIs were covered by a single class. Alternatively, should additional classes be added for the other socket types? * The current separate socket_connector implementation does not correspond to an OS resource, unlike socket_acceptor. This can be problematic, e.g. it prevents a Windows implementation using ConnectEx, and doesn't allow you to set socket options before the connection is established. Therefore I propose adding connect and async_connect operations to socket classes. Should the separate socket_connector be retained? * In designing asio I considered that people may want to customise the demultiplexing strategy associated with each resource. For example the basic_stream_socket template looks like: template <typename Service> class basic_stream_socket; where Service is a "facet" of the demuxer that provides demultiplexing facilities for the socket. The typedef for stream_socket specifies the Service type based on the target platform. However in practice I don't believe this level of customisation is required (to the best of my knowledge no existing asio user customises it), particularly if asio uses the "best" demultiplexing mechanism for each platform. Or another way of looking at it: developers who need this level of control might not use a general purpose networking library anyway. An alternative approach would to have the only template parameter be an allocator (since there is often memory allocation associated with asynchronous operations). For example: template <typename Allocator> class basic_demuxer; template <typename Allocator> class basic_stream_socket; where a stream_socket can only be used with a demuxer that has the same allocator type. The typedefs for demuxer and stream_socket would just use the default allocator. Cheers, Chris

20 65

bizarre test results: foreach, gcc-4_0-darwin
by Eric Niebler 01 Sep '05

01 Sep '05

I need help understanding some of the recent regression results. At http://tinyurl.com/72q3k you can see the most recent Foreach test results. The first and the third columns both purport to be gcc-4_0-darwin, but the results are different! How can that be? Both tests were run today, and I haven't touched the code since yesterday. -- Eric Niebler Boost Consulting www.boost-consulting.com

3 4

Please help understanding regression results
by Arkadiy Vertleyb 01 Sep '05

01 Sep '05

What does a blank space (as opposed to "pass"/"fail"/"n/a") mean in the regression table? Thanks, Arkadiy

2 5

[mpl] broken count and at metafunctions
by Matt Calabrese 01 Sep '05

01 Sep '05

As much as I love MPL, I have come across a couple more problems. First, on MSVC++ 7.1, "count" returns 0 with maps, when there is an element in the map with the specified key (and probably on other compilers as well, though I haven't checked the implementation). As well, while a 3-argument form of "at" is described in documentation (where the third argument is the default type returned by "at" if an element with the provided key does not exist in the container), it does not appear to be implemented in 1.33. -Matt Calabrese

4 13

[Boost-bugs] [ boost-Bugs-1277742 ] Serialization 1.33 assertion failure when deserializing STL
by SourceForge.net 01 Sep '05

01 Sep '05

Bugs item #1277742, was opened at 2005-08-31 15:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1277742&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: serialization Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zach Laine (tzlaine) Assigned to: Robert Ramey (ramey) Summary: Serialization 1.33 assertion failure when deserializing STL Initial Comment: I am seeing an assertion failure in reset_object_address. The assertion output is: /tmp/boost_cvs/libs/serialization/src/basic_iarchive.cpp:266: void boost::archive::detail::basic_iarchive_impl::reset_object_address(const void*, const void*): Assertion `object_id_vector[i].address >= ol d_address' failed. These are the values in the failed assertion: i == 1 object_id_vector[i].address == 0x43ef0920 old_address == 0xbfffe240 For good measure, new_address == 0x43ee7830 and this == 0x43eeffc0 at the point of failure. I don't know if that indicates that old_address is garbage, or if it is supposed to be that far away from the other addresses. This is the same assertion failure reported in bug #1262084, but I am not using polymorphic archives. I verified that the test code submitted for that bug fails for me as well, but when I converted it to non-polymorphic archives, it works fine. Therefor I have no idea if these bugs are related. The code producing the failure worked fine under version 1.32. Unfortunately, the code that produces this failure is pretty involved. All my attempts to produce a minimal set of code that provokes the failure have failed. The object producing the failure is being serialized through a pointer-to-base. The inheritance of the object's class is Wnd -> Control -> TextControl. The object within the TextControl that is actually producing the failure is m_line_data, which is a std::vector. I have two fairly minimal serialize methods that I have created for the object being loaded when the failure occurs -- one of which works and on of which does not. Method A works: template <class Archive> void GG::TextControl::serialize(Archive& ar, const unsigned int version) { ar & BOOST_SERIALIZATION_NVP(m_line_data); } Method B fails: template <class Archive> void GG::TextControl::serialize(Archive& ar, const unsigned int version) { ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(Control) & BOOST_SERIALIZATION_NVP(m_line_data); } The XML file produced using A: <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="3"> <new_plan_text_control class_id="0" tracking_level="1" version="0" object_id="_0"> <m_line_data class_id="1" tracking_level="0" version="0"> <count>1</count> <item class_id="2" tracking_level="0" version="0"> <char_data class_id="3" tracking_level="0" version="0"> <count>0</count> </char_data> <justification>8</justification> </item> </m_line_data> </new_plan_text_control> </boost_serialization> The XML file produced using B: <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="3"> <new_plan_text_control class_id="0" tracking_level="1" version="0" object_id="_0"> <Control class_id="1" tracking_level="1" version="0" object_id="_1"> <Wnd class_id="2" tracking_level="1" version="0" object_id="_2"> <m_text></m_text> <m_done>0</m_done> <m_parent class_id="-1"></m_parent> <m_children class_id="3" tracking_level="0" version="0"> <count>0</count> </m_children> <m_zorder>0</m_zorder> <m_visible>1</m_visible> <m_clip_children>0</m_clip_children> <m_upperleft class_id="4" tracking_level="0" version="0"> <x>0</x> <y>0</y> </m_upperleft> <m_lowerright> <x>150</x> <y>25</y> </m_lowerright> <m_min_size> <x>0</x> <y>0</y> </m_min_size> <m_max_size> <x>1073741824</x> <y>1073741824</y> </m_max_size> <m_filters class_id="5" tracking_level="0" version="0"> <count>0</count> </m_filters> <m_filtering class_id="6" tracking_level="0" version="0"> <count>0</count> </m_filtering> <m_layout class_id="-1"></m_layout> <m_containing_layout class_id="-1"></m_containing_layout> <m_flags>0</m_flags> </Wnd> <m_color class_id="8" tracking_level="0" version="0"> <r>0</r> <g>0</g> <b>0</b> <a>0</a> </m_color> <m_disabled>0</m_disabled> </Control> <m_line_data class_id="9" tracking_level="0" version="0"> <count>1</count> <item class_id="10" tracking_level="0" version="0"> <char_data class_id="11" tracking_level="0" version="0"> <count>0</count> </char_data> <justification>8</justification> </item> </m_line_data> </new_plan_text_control> </boost_serialization> Below is the stack at the point of failure. I Hope this helps. #0 0xffffe410 in ?? () #1 0xbfffe050 in ?? () #2 0x00000006 in ?? () #3 0x4062bf79 in abort () from /lib/tls/libc.so.6 #4 0x40623fe3 in __assert_fail () from /lib/tls/libc.so.6 #5 0x404be06f in boost::archive::detail::basic_iarchive_impl::reset_object_address (this=0x43eeffc0, new_address=0x43ee7830, old_address=0xbfffe240) at /tmp/boost_cvs/libs/serialization/src/basic_iarchive.cpp:266 #6 0x404bd7b1 in boost::archive::detail::basic_iarchive::reset_object_address (this=0xbfffebc0, new_address=0x43ee7830, old_address=0xbfffe240) at /tmp/boost_cvs/libs/serialization/src/basic_iarchive.cpp:529 up 5#7 0x0809c679 in boost::serialization::stl::archive_input_seq<boost::archive::xml_iarchive, std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > >::operator() (this=0xbfffe27e, ar=@0xbfffebc0, s=@0x43ef099c) at collections_load_imp.hpp:91 #8 0x0809c495 in rebuild_collection<boost::archive::xml_iarchive, std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> >, boost::serialization::stl::archive_input_seq<boost::archive::xml_iarchive, std::ve ctor<GG::Font::LineData, std::allocator<GG::Font::LineData> > >, boost::serialization::stl::reserve_imp<std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > > > (ar=@0xbfffebc0, s=@0x43ef099c) at collections_load_imp.hpp:208 #9 0x0809c41c in load_collection<boost::archive::xml_iarchive, std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> >, boost::serialization::stl::archive_input_seq<boost::archive::xml_iarchive, std::vecto r<GG::Font::LineData, std::allocator<GG::Font::LineData> > >, boost::serialization::stl::reserve_imp<std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > > > (ar=@0xbfffebc0, s=@0x43ef099c) at collections_load_imp.hpp:230 #10 0x0809c402 in load<boost::archive::xml_iarchive, GG::Font::LineData, std::allocator<GG::Font::LineData> > (ar=@0xbfffebc0, t=@0x43ef099c) at vector.hpp:58 #11 0x0809c3e9 in boost::serialization::free_loader<boost::archive::xml_iarchive, std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > >::invoke (ar=@0xbfffebc0, t=@0x43ef099c, file_version=0) at split_free.hpp:58 #12 0x0809c3ad in split_free<boost::archive::xml_iarchive, std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > > (ar=@0xbfffebc0, t=@0x43ef099c, file_version=0) at split_free.hpp:74 #13 0x0809c391 in serialize<boost::archive::xml_iarchive, GG::Font::LineData, std::allocator<GG::Font::LineData> > (ar=@0xbfffebc0, t=@0x43ef099c, file_version=0) at vector.hpp:76 #14 0x0809b937 in serialize_adl<boost::archive::xml_iarchive, std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > > (ar=@0xbfffebc0, t=@0x43ef099c, file_version=0) at serialization.hpp:140 #15 0x0809b3b0 in boost::archive::detail::iserializer<boost::archive::xml_iarchive, std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > >::load_object_data (this=0x814c7e8, ar=@0xbfffebc0, x=0x43ef099c, file_version=0) at iserializer.hpp:158 #16 0x404be3c6 in boost::archive::detail::basic_iarchive_impl::load_object (this=0x43eeffc0, ar=@0xbfffebc0, t=0x43ef099c, bis=@0x814c7e8) at /tmp/boost_cvs/libs/serialization/src/basic_iarchive.cpp:378 #17 0x404bd7e1 in boost::archive::detail::basic_iarchive::load_object (this=0xbfffebc0, t=0x43ef099c, bis=@0x814c7e8) at /tmp/boost_cvs/libs/serialization/src/basic_iarchive.cpp:537 #18 0x08095170 in boost::archive::detail::load_non_pointer_type<boost::archive::xml_iarchive, std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > >::load_standard::invoke (ar=@0xbfffebc0, t=@0x43ef099c) at iserializer.hpp:362 #19 0x08095144 in boost::archive::detail::load_non_pointer_type<boost::archive::xml_iarchive, std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > >::invoke (ar=@0xbfffebc0, t=@0x43ef099c) at iserializer.hpp:412 #20 0x08094c6a in load<boost::archive::xml_iarchive, std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > > (ar=@0xbfffebc0, t=@0x43ef099c) at iserializer.hpp:559 #21 0x08094c28 in boost::archive::basic_xml_iarchive<boost::archive::xml_iarchive>::load_override<std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > > (this=0xbfffebc0, t=@0xbfffe540) at basic_xml_iarchive.hpp:80 #22 0x08094bdc in boost::archive::xml_iarchive_impl<boost::archive::xml_iarchive>::load_override<boost::serialization::nvp<std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > > const> ( this=0xbfffebc0, t=@0xbfffe540) at xml_iarchive.hpp:74 #23 0x08094bb3 in operator>><const boost::serialization::nvp<std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > > > (this=0xbfffebc0, t=@0xbfffe540) at interface_iarchive.hpp:84 #24 0x08093aab in operator&<const boost::serialization::nvp<std::vector<GG::Font::LineData, std::allocator<GG::Font::LineData> > > > (this=0xbfffebc0, t=@0xbfffe540) at interface_iarchive.hpp:91 #25 0x080947de in GG::TextControl::serialize<boost::archive::xml_iarchive> (this=0x43ef0920, ar=@0xbfffebc0, version=0) at GGTextControl.h:223 #26 0x08094775 in serialize<boost::archive::xml_iarchive, GG::TextControl> (ar=@0xbfffebc0, t=@0x43ef0920, file_version=0) at access.hpp:109 #27 0x08094759 in serialize<boost::archive::xml_iarchive, GG::TextControl> (ar=@0xbfffebc0, t=@0x43ef0920, file_version=0) at serialization.hpp:81 #28 0x0808e7cd in serialize_adl<boost::archive::xml_iarchive, GG::TextControl> (ar=@0xbfffebc0, t=@0x43ef0920, file_version=0) at serialization.hpp:140 #29 0x0809b672 in boost::archive::detail::iserializer<boost::archive::xml_iarchive, GG::TextControl>::load_object_data (this=0x814cad0, ar=@0xbfffebc0, x=0x43ef0920, file_version=0) at iserializer.hpp:158 #30 0x404be323 in boost::archive::detail::basic_iarchive_impl::load_object (this=0x43eeffc0, ar=@0xbfffebc0, t=0x43ef0920, bis=@0x814cad0) at /tmp/boost_cvs/libs/serialization/src/basic_iarchive.cpp:363 #31 0x404bd7e1 in boost::archive::detail::basic_iarchive::load_object (this=0xbfffebc0, t=0x43ef0920, bis=@0x814cad0) at /tmp/boost_cvs/libs/serialization/src/basic_iarchive.cpp:537 #32 0x0809b2c4 in boost::archive::detail::load_non_pointer_type<boost::archive::xml_iarchive, GG::TextControl>::load_standard::invoke (ar=@0xbfffebc0, t=@0x43ef0920) at iserializer.hpp:362 #33 0x0809b298 in boost::archive::detail::load_non_pointer_type<boost::archive::xml_iarchive, GG::TextControl>::invoke (ar=@0xbfffebc0, t=@0x43ef0920) at iserializer.hpp:412 #34 0x0809af74 in load<boost::archive::xml_iarchive, GG::TextControl> (ar=@0xbfffebc0, t=@0x43ef0920) at iserializer.hpp:559 #35 0x0809af28 in boost::archive::basic_xml_iarchive<boost::archive::xml_iarchive>::load_override<GG::TextControl> (this=0xbfffebc0, t=@0xbfffe760) at basic_xml_iarchive.hpp:80 #36 0x0809aedc in boost::archive::xml_iarchive_impl<boost::archive::xml_iarchive>::load_override<boost::serialization::nvp<GG::TextControl> const> (this=0xbfffebc0, t=@0xbfffe760) at xml_iarchive.hpp:74 #37 0x08098aaf in operator>><const boost::serialization::nvp<GG::TextControl> > (this=0xbfffebc0, t=@0xbfffe760) at interface_iarchive.hpp:84 #38 0x080984c7 in boost::archive::detail::pointer_iserializer<GG::TextControl, boost::archive::xml_iarchive>::load_object_ptr (this=0x814c8c0, ar=@0xbfffebc0, x=@0x43ed4518, file_version=0) at iserializer.hpp:308 #39 0x404be9b6 in boost::archive::detail::basic_iarchive_impl::load_pointer (this=0x43eeffc0, ar=@0xbfffebc0, t=@0xbfffed44, bpis_ptr=0x814c8c0, finder=0x8081928 <boost::archive::detail::archive_pointer_iserializer<boost::archive::xml_iarchive>::find(boost::serialization::extended_type_info const&)>) at /tmp/boost_cvs/libs/serialization/src/basic_iarchive.cpp:482 #40 0x404bd817 in boost::archive::detail::basic_iarchive::load_pointer (this=0xbfffebc0, t=@0xbfffed44, bpis_ptr=0x814c8c0, finder=0x8081928 <boost::archive::detail::archive_pointer_iserializer<boost::archive::xml_iarchive>::find(boost::serialization::extended_type_info const&)>) at /tmp/boost_cvs/libs/serialization/src/basic_iarchive.cpp:549 #41 0x0808b34b in boost::archive::detail::load_pointer_type<boost::archive::xml_iarchive, GG::TextControl*>::invoke (ar=@0xbfffebc0, t=@0xbfffed44) at iserializer.hpp:473 #42 0x08089d8e in load<boost::archive::xml_iarchive, GG::TextControl*> (ar=@0xbfffebc0, t=@0xbfffed44) at iserializer.hpp:559 #43 0x08089d4c in boost::archive::basic_xml_iarchive<boost::archive::xml_iarchive>::load_override<GG::TextControl*> (this=0xbfffebc0, t=@0xbfffed90) at basic_xml_iarchive.hpp:80 #44 0x08089d00 in boost::archive::xml_iarchive_impl<boost::archive::xml_iarchive>::load_override<boost::serialization::nvp<GG::TextControl*> const> (this=0xbfffebc0, t=@0xbfffed90) at xml_iarchive.hpp:74 #45 0x08089cd7 in operator>><const boost::serialization::nvp<GG::TextControl*> > (this=0xbfffebc0, t=@0xbfffed90) at interface_iarchive.hpp:84 #46 0x08087555 in operator&<const boost::serialization::nvp<GG::TextControl*> > (this=0xbfffebc0, t=@0xbfffed90) at interface_iarchive.hpp:91 #47 0x08085cb8 in SerializationTestGGApp::Initialize (this=0xbfffef50) at serialization.cpp:458 #48 0x400312cc in SDLGGApp::Run (this=0xbfffef50) at src/SDL/SDLGGApp.cpp:291 #49 0x402259ce in GG::App::operator() (this=0xbfffef50) at src/GGApp.cpp:257 #50 0x40030988 in SDLGGApp::operator() (this=0xbfffef50) at src/SDL/SDLGGApp.cpp:62 #51 0x08085fe8 in main (argc=1, argv=0xbfffeff4) at serialization.cpp:497 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1277742&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

2 1

Very fast delimited record parsing with boost
by David Abrahams 01 Sep '05

01 Sep '05

This appeared on comp.lang.c++.moderated a few days ago. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2

[1.33.1][multi_index] permission for changes in the branch
by JOAQUIN LOPEZ MU?Z 31 Aug '05

31 Aug '05

I've comitted two changes for multi_index into the trunk: 1. A bugfix for a multithreading problem with safe mode. 2. A fix to sync with std DR 130, see http://tinyurl.com/9lhfs These changes were planned for 1.34, but I'd like to move them to 1.33.1 if given permission. Am I? Another question, is there an estimated date for 1.33.1 RC1? Thanks, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1