August 2005 - Boost - lists.preview.boost.org

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> 0 <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

cvs watch off (was: Repository access and cvs watch)
by Thomas Witt 31 Aug '05

31 Aug '05

Hi, I've turned the forced read-only files feature on the boost repository off by issuing a 'cvs watch off' command on the boost tree. This means when you get files from the repository they will be writable by default. Those of you who prefer read-only files will have to either set the CVSREAD environment variable or add the -r flag to the _global_ options in your .cvsrc file. If you are using cvs edit you can go on doing that. Nothing has changed in this respect. If you want to watch files you can still do this by using cvs watch add/remove. In this respect the command name 'cvs watch off' is really misleading. Please tell me if this change causes trouble for you. Regards Thomas

1 0

reuse of strip-debug-rule
by Stefan Slapeta 31 Aug '05

31 Aug '05

Hi, the rule turn-off-intel-debug-symbols is now defined/used at least in 3 libraries: graph, python and spirit. There is another similar one ("special-requirements") in multi_index which does the same thing for GCC on Tru64. Does it make sense to provide a common rule for this case that accepts the OS and a wildcard for the toolset as parameter? Where could this rule be defined? Stefan

2 1

[Boost-bugs] [ boost-Bugs-1262084 ] crash deserializing 1.32 data (poly archive + stl container)
by SourceForge.net 31 Aug '05

31 Aug '05

Bugs item #1262084, was opened at 2005-08-17 06:31 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=1262084&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: Nobody/Anonymous (nobody) Assigned to: Robert Ramey (ramey) Summary: crash deserializing 1.32 data (poly archive + stl container) Initial Comment: Hello, i got a problem deserializing STL containers with polymorphic archive interfaces. Serialization/Deserialization with boost 1.32 works fine. Simple object trees with stl containers (maps) and base class registration (no shared_ptr used). When i deserialize the data (xml) with boost 1.33 it asserts/crashes in basic_iarchive.cpp ( basic_iarchive_impl::reset_object_address): --- snip ---- inline void basic_iarchive_impl::reset_object_address( const void * new_address, const void *old_address ){ // if the this object wasn't tracked std::size_t i = moveable_object_position; if(i >= moveable_object_stack.size()) return; if(old_address != object_id_vector[i].address) // skip to any lower level ones ++i; while(i < moveable_object_stack.size()){ // calculate displacement from this level assert(object_id_vector[i].address >= old_address); <---- assert here !!! // warning - pointer arithmetic on void * is in herently non-portable // but expected to work on all platforms in current usage std::size_t member_displacement = reinterpret_cast<std::size_t>(object_id_vector[i].address) - reinterpret_cast<std::size_t>(old_address); ---- snip ---- Callstack: > ddc.exe!boost::archive::detail::basic_iarchive_impl::reset_object_address(const void * new_address=0x00fb67cc, const void * old_address=0x0135c67c) Line 266 + 0x2a C++ ddc.exe!boost::archive::detail::basic_iarchive::reset_object_address(const void * new_address=0x00fb67cc, const void * old_address=0x0135c67c) Line 530 C++ ddc.exe!boost::archive::detail::polymorphic_iarchive_impl<boost::archive::xml_iarchive_impl<boost::archive::xml_iarchive> >::reset_object_address(const void * new_address=0x00fb67cc, const void * old_address=0x0135c67c) Line 78 C++ ddc.exe!boost::serialization::stl::archive_input_map<boost::archive::polymorphic_iarchive,std::map<unsigned int,xxx::LayoutObject *,std::less<unsigned int>,std::allocator<std::pair<unsigned int const ,xxx::LayoutObject *> > > >::operator()(boost::archive::polymorphic_iarchive & ar={...}, std::map<unsigned int,xxx::LayoutObject *,std::less<unsigned int>,std::allocator<std::pair<unsigned int const ,xxx::LayoutObject *> > > & s={...}) Line 118 + 0x1a C++ ddc.exe!boost::serialization::stl::rebuild_collection<boost::archive::polymorphic_iarchive,std::map<unsigned int,xxx::LayoutObject *,std::less<unsigned int>,std::allocator<std::pair<unsigned int const ,xxx::LayoutObject *> > >,boost::serialization::stl::archive_input_map<boost::archive::polymorphic_iarchive,std::map<unsigned int,xxx::LayoutObject *,std::less<unsigned int>,std::allocator<std::pair<unsigned int const ,xxx::LayoutObject *> > > >,boost::serialization::stl::no_reserve_imp<std::map<unsigned int,xxx::LayoutObject *,std::less<unsigned int>,std::allocator<std::pair<unsigned int const ,minimon::base::display::dispman::CLayoutObject *> > > > >(boost::archive::polymorphic_iarchive & ar={...}, std::map<unsigned int,xxx::LayoutObject *,std::less<unsigned int>,std::allocator<std::pair<unsigned int const ,xxx::LayoutObject *> > > & s={...}) Line 209 C++ ddc.exe!boost::serialization::stl::load_collection<boost::archive::polymorphic_iarchive,std::map<unsigned int,xxx::LayoutObject *,std::less<unsigned int>,std::allocator<std::pair<unsigned int const ,xxx::LayoutObject *> > >,boost::serialization::stl::archive_input_map<boost::archive::polymorphic_iarchive,std::map<unsigned int,xxx::LayoutObject *,std::less<unsigned int>,std::allocator<std::pair<unsigned int const ,xxx::LayoutObject *> > > >,boost::serialization::stl::no_reserve_imp<std::map<unsigned int,xxx::LayoutObject *,std::less<unsigned int>,std::allocator<std::pair<unsigned int const ,xxx::LayoutObject *> > > > >(boost::archive::polymorphic_iarchive & ar={...}, std::map<unsigned int,xxx::LayoutObject *,std::less<unsigned int>,std::allocator<std::pair<unsigned int const ,xxx::LayoutObject *> > > & s={...}) Line 230 + 0xd C++ ---- The serializing code is implemented using split members and manual registration and usually read like this: ---- snip --- void DerivedLayoutObject::serialize( boost::archive::polymorphic_oarchive& ar, const unsigned int /* version */) { // register pointer type info ar.register_type(static_cast<LayoutObject*>(0)); // serialize data members ar & boost::serialization::make_nvp( "status", m_status); .... // serialize stl container (std::map here) ar & boost::serialization::make_nvp( "childs", m_childs); } (deserialization vise-versa) --------------------- Whats the problem here? I simply rebuilt the whole project using 1.33. Regards, A. Focht ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1262084&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 2

[program_options] portability patches
by François Dumont 31 Aug '05

31 Aug '05

Here are several patches to improve portability for this library: - options_description.hpp: The m_default_line_length is for me an implementation detail. As static constant are well known as not being portable I propose to use the dedicated BOOST_STATIC_CONSTANT macro in this case. I also move it to the private section as I think it is the place it must be but of course it do not change the portability aspect if it is retore back to the public section. - options_description.cpp: C++ Standard library implementors needs compiler partial template specialization support in order to offer the Standard reverse_iterator definition. Using reverse_iterator in this source introduce a major limitation in terms of compilers able to support it. As the only thing you need is a reverse_iterator on string::const_iterator the simplest solution is to use the string::const_reverse_iterator typedef. This way you simply rely on Standard library quality, I expect that all compilers with partial template specialization have a Standard string coming with a const_reverse_iterator typedef. - variables_map.cpp: A classic for loop internal variable problem, i is defined 2 times with a different type in 2 different for loop. I fix it by using an iterator approach to enumerate the desc.options() container. Thanks to those patches I build the lib with the msvc-stlport toolset with no problem. Bests *** options_description.hpp.orig Tue Aug 30 07:34:41 2005 --- options_description.hpp Tue Aug 30 21:05:22 2005 *************** *** 152,160 **** @sa option_description */ class BOOST_PROGRAM_OPTIONS_DECL options_description { public: - static const unsigned m_default_line_length = 80; - /** Creates the instance. */ options_description(unsigned line_length = m_default_line_length); /** Creates the instance. The 'caption' parameter gives the name of --- 152,159 ---- @sa option_description */ class BOOST_PROGRAM_OPTIONS_DECL options_description { + BOOST_STATIC_CONSTANT(unsigned, m_default_line_length = 80); public: /** Creates the instance. */ options_description(unsigned line_length = m_default_line_length); /** Creates the instance. The 'caption' parameter gives the name of *** options_description.cpp.orig Tue Aug 30 07:42:10 2005 --- options_description.cpp Tue Aug 30 07:43:28 2005 *************** *** 375,382 **** { // find last ' ' in the second half of the current paragraph line string::const_iterator last_space = ! find(reverse_iterator<string::const_iterator>(line_end - 1), ! reverse_iterator<string::const_iterator>(line_begin - 1), ' ') .base(); --- 375,382 ---- { // find last ' ' in the second half of the current paragraph line string::const_iterator last_space = ! find(string::const_reverse_iterator(line_end - 1), ! string::const_reverse_iterator(line_begin - 1), ' ') .base(); *** variables_map.cpp.orig Tue Aug 30 07:46:25 2005 --- variables_map.cpp Tue Aug 30 07:48:48 2005 *************** *** 80,92 **** } xm.m_final.insert(new_final.begin(), new_final.end()); - - // Second, apply default values. ! const vector<shared_ptr<option_description> >& all = desc.options(); ! for(unsigned i = 0; i < all.size(); ++i) { ! const option_description& d = *all[i]; string key = d.key(""); // FIXME: this logic relies on knowledge of option_description // internals. --- 80,91 ---- } xm.m_final.insert(new_final.begin(), new_final.end()); // Second, apply default values. ! vector<shared_ptr<option_description> >::const_iterator optIt(desc.options().begin()), ! optItEnd(desc.options().end()); ! for (; optIt != optItEnd; ++optIt) { ! const option_description& d = *(*optIt); string key = d.key(""); // FIXME: this logic relies on knowledge of option_description // internals.

2 1

Proposed BOOST_FOREACH
by Joel Eidsath 30 Aug '05

30 Aug '05

I like the BOOST_FOREACH macro, and I'm going to be spending a lot of time playing around with it. For working with iterator ranges, however, this sort of thing seems to be the best that I can come up with: //pFirst and pLast are iterators that return an int on dereference //they could be some_containter<int>.rbegin() and some_container<int>.rend(), for example BOOST_FOREACH(int i, vector<int>(pFirst,pLast)); It's not that ugly, but creating a new vector to do a loop is quite an efficiency hit. Is there an better way to do this? Joel Eidsath

2 2

A few questions about regression system
by Arkadiy Vertleyb 30 Aug '05

30 Aug '05

Hello All, I am currently setting up the test system for typeof. My understanding is that I have to do the following: 1) put each test in a separate CPP file; 2) import testing rules; 3) put the following in the Jamfile: compile test1.cpp ; compile test2.cpp ; . . . 4) mention typeof in the file that lists all the boost tests. Is this correct and all that needs to be done? Also, where is it specified which compilers are supportred? Thanks in advance. Regards, Arkadiy

2 4

Boost regression notification (2005-08-30)
by Douglas Gregor 30 Aug '05

30 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-30T15:14:11Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 109 failures in 13 libraries: foreach (24) function (1) graph (3) lambda (2) math (6) mpl (3) parameter (4) python (1) random (2) serialization (50) test (1) thread (8) wave (4) |foreach| array_byref: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin array_byval: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin rvalue_const: gcc-4_0-darwin rvalue_nonconst: gcc-4_0-darwin stl_byref: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin stl_byval: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin user_defined: cw-8_3 cw-9_4 cw-9_4 vc-6_5 vc-6_5-stlport vc-7_0 |function| lambda_test: gcc-4_0-darwin |graph| graphviz_test: vc-7_1 vc-7_1 vc-7_1 |lambda| bind_tests_simple_f_refs: gcc-4_0-darwin exception_test: gcc-4_0-darwin |math| octonion_test: gcc-4_0-darwin gcc-4_0-darwin quaternion_test: gcc-4_0-darwin gcc-4_0-darwin special_functions_test: gcc-4_0-darwin gcc-4_0-darwin |mpl| integral_c: gcc-4_0-darwin size_t: gcc-4_0-darwin gcc-4_0-darwin |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |python| exec: msvc |random| random_demo: gcc-4_0-darwin random_test: gcc-4_0-darwin |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin gcc-4_0-darwin test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin gcc-4_0-darwin test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin gcc-4_0-darwin test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin gcc-4_0-darwin test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |test| token_iterator_test: gcc-4_0-darwin |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: gcc-3.3.6-linux intel-9.0-linux

1 0

[serialization] The constant object problem
by Loïc Joly 30 Aug '05

30 Aug '05

Hello everybody, I've read the rationale for only allowing const trackable objects, but here is my problem : I want to serialize the following class : class C : boost::noncopyable { public: void setData(string s) {data = s;} //... }; int main() { C c; c.setData("Hello world"); vector <C*> v; v.push_back(&c); //... ar << c << c; } To have a c with meaningfull data, it cannot be const. I cannot create a local object that is a copy of the object (it is noncopyable) I do not think making the object untracked would be a good idea in this case (I might be wrong ?) So far, the best way I found to be able to serialize this object is : C const & cForSerialize = c; ar << cForSerialize << cForSerialize; But I do not think this is really elegant code. Is there a better alternative ? -- Loïc

4 6

Re: [boost] Preprocessot question
by Suman Cherukuri 30 Aug '05

30 Aug '05

> a.c > #include "err.h" > static const int err_tag = err_tag_a_c; > enum {err_bad_foobar=1, err_missing_baz, ... }; > > and you use the errors as follows: > > long err = ERR(missing_baz); How is it going to prevent duplication. Suppose, somewhere in a.c if I write long err = ERR(missing_baz), what happens? > > with the macro ERR defined in err.h as: > #define ERR(x) ((err_tag * 65536L) + err_##x) -----Original Message----- From: Martin Bonner [mailto:martin.bonner@pitechnology.com] Sent: Tuesday, August 30, 2005 1:40 AM To: 'Suman Cherukuri' Subject: RE: [boost] Preprocessot question ----Original Message---- From: Suman Cherukuri [mailto:suman@cherukuris.net] Sent: 29 August 2005 22:49 To: boost(a)lists.boost.org Subject: [boost] Preprocessot question > This probably doesn't belong to boost mailing list, but since boost > has a lot of support in preprocessor, there may be someone who can > answer my question. You would have done better to ask this in comp.lang.c.moderated. > I'm using general 'C' compiler in this project (hence I cannot use > boost headers). I want to write a macro as follows; > > #define ERR(x, y) \ > { \ > # ifndef ERR##x \ > # define ERR##x \ > # else \ > # error ERR##x already defined\ > # endif > y = x; \ > } > > When I compile, I get the error saying, > error C2162: expected macro formal parameter > on all the preprocessor lines inside the #define ERR(...) body. Right. You can't write a preprocessor macro that creates preprocessor directives. The #ifndef in your macro will never get parsed. > The reason I want to do something like this is to have some unique > numbers > in the code (like locators. Don't want to use __FILE__ and __LINE__ > for security reasons) and want to capture duplicates at compiletime. > > For example if I say in the code, int err = 10000 in one file, I > don't want any other engineer to use 10000 in the anywhere else in > the code. > > So I started writing something like int err = ERR(10000) but got into > several compiler problems as I mentioned above. The problem I see with your solution (assuming it worked), is that if we have two files a.c and b.c, then somebody could write: a.c: ... int err = ERR(10000); ... b.c: ... int err = ERR(10000); ... ... and the check would fail to detect that both files are using the same value :-( The simple solution is to have a err.h which defines a (long) enumeration, and every time you need a new error value, you add to err.h. That is simple, but of course it means you need to recompile everything every time you add a value. The slightly more complex version is that you have an err.h which has an enumeration which is specific to each .c file. (That means you will have to recompile every time you add an .c file, but that is probably bearable.) So err.h might look like: enum { err_tag_a_c=1, err_tag_b_c, .... }; Then each .c file has at the start: a.c #include "err.h" static const int err_tag = err_tag_a_c; enum {err_bad_foobar=1, err_missing_baz, ... }; and you use the errors as follows: long err = ERR(missing_baz); with the macro ERR defined in err.h as: #define ERR(x) ((err_tag * 65536L) + err_##x) To add a new error code, you update the enumeration at the top of file, and use it via the ERR macro. (Which only requires recompiling the file you were changing anyway). Note that I assumed you could use long for your error codes - if you are in the embedded world, that might not be affordable. On the other hand, in the embedded world you can probably live with only 255 different files, and 255 error codes per file. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

Re: [boost] [statechart] Problems if I make dtorS virtual?
by BRIDGES Dick 30 Aug '05

30 Aug '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Andreas Huber > Sent: Friday, August 26, 2005 3:00 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] [statechart] Problems if I make dtorS virtual? > > BRIDGES Dick wrote: > > Just a thought - might it be worthwhile to introduce a policy to allow > > the > > user to choose between maximum performance and the comforting > > consistency > > of virtual dtorS to go with those virtual functions? :-) > > Ugh, yet another policy or #define? I'd want to avoid that. Since this > is gcc-only problem, I think the best I can do is to make that > destructor virtual for gcc and leave it non-virtual for all other > compilers. > > Thoughts? My $.02 says to leave the destructor non-virtual across the board and I sell -Wno-non-vitual-dtor to my QA group. Otherwise some embedded device will show up that favors non-virtual and I'll be the one asking you to put it back so our gcc-based cross-compilers can use it. ;) That and the threat of a #define. %-P > Regards, > > -- > Andreas Huber > > When replying by private email, please remove the words spam and trap > from the address shown in the header. > Regards, Dick Bridges

2 1

date_time test questions
by John Maddock 30 Aug '05

30 Aug '05

Jeff, I've been playing with date_time to try and get it to do the right thing with VC++ when /Zc:wchar_t is *not* specified, and I've come up with a list of questions for you if you don't mind :-) 1) What's the meaning of USE_DATE_TIME_PRE_1_33_FACET_IO? Without it the testtime_wstream.cpp test case fails even with /Zc:wchar_t, this is a source of confusion if you're building the building the tests in your IDE for whatever reason. 2) Without USE_DATE_TIME_PRE_1_33_FACET_IO the testgrep_wstream.cpp test doesn't compile irrespective of the /Zc:wchar_t option: testgreg_wstream.cpp c:\data\boost\develop\boost\boost\date_time\date_facet.hpp(640) : error C2678: binary '+' : no operator found which takes a left-hand operand of type 'const char [35]' (or there is no acceptable conversion) c:\data\boost\develop\boost\boost\date_time\date_facet.hpp(606) : while compiling class-template member function 'std::istreambuf_iterator<_Elem,_Traits> boost::date_time::date_input_facet<date_type,CharT>::get(InItrT &,InItrT &,std::ios_base &,boost::date_time::date_input_facet<date_type,CharT>::duration_type &) const' with [ _Elem=wchar_t, _Traits=std::char_traits<wchar_t>, date_type=boost::gregorian::date, CharT=wchar_t, InItrT=std::istreambuf_iterator<wchar_t,std::char_traits<wchar_t>> ] c:\data\boost\develop\boost\boost\date_time\gregorian\gregorian_io.hpp(78) : see reference to class template instantiation 'boost::date_time::date_input_facet<date_type,CharT>' being compiled with [ date_type=boost::gregorian::date, CharT=wchar_t ] c:\data\boost\develop\boost\libs\date_time\test\gregorian\testgreg_wstream.cpp(50) : see reference to function template instantiation 'std::basic_istream<_Elem,_Traits> &boost::gregorian::operator >><wchar_t,std::char_traits<wchar_t>>(std::basic_istream<_Elem,_Traits> &,boost::gregorian::date &)' being compiled with [ _Elem=wchar_t, _Traits=std::char_traits<wchar_t> ] 3) Finally there are a lot of places where an unsigned short is written to or read from a stream: unfortunately the dinkumware lib treats these "as if" they were a wide character value, rather than an integer. Casting to unsigned int in these cases would fix that, but it's a horrid cludge, and I don't know what you might think about that! Thanks, John.

3 5

Questions on Serialization
by Daryle Walker 30 Aug '05

30 Aug '05

I just looked over this library (since Robert Ramey mentioned part of it as a solution to a different problem). I'm wondering how (future) Boost library code should implement serialization. Right now, the Serialization library contains code to serialize "shared_ptr" types. Should the Serialization library contain similar code for every potential Boost type, so should each type include the code? If the latter is the answer, then does: class my_type { friend class ::boost::serialization::access; //... }; need a forward (or full) declaration for "access" before it? Or does that only apply to template functions (or is it just template operators)[1]? Also, the Contents entries from "void_cast" to "BOOST_STATIC_WARNING" need to be raised a level so they don't look like child entries for "extended_type_info". And I think some of the demo programs could use a sprinkling of "std::auto_ptr". [1] I know there's at least one wacky friend combination that'll interpret a template function as a non-template function instead if you don't take proper precautions. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

7 11

secure asio using ssl
by Dirk Griffioen 30 Aug '05

30 Aug '05

Hi All, We would like to make the remark we created a first version of a secure (ssl/tls) extension to ASIO. It's use should be regarded as an extension to ASIO and configurable with the type of ssl a user has. From the test code (the server): #define HAS_OPENSSL #include <asio.hpp> When the server accepts a connection it then calls handle_accept to secure the socket: void handle_accept(const asio::error& error) { if (!error) { std::cout << "server connected..." << std::endl; // Secure the connection socket_.async_secure( boost::bind(&impl::handle_secure, this, asio::arg::error) ); After that it's a matter of async_recv/send - but the connection now is secure. the variable needed is: asio::tls_socket socket_; Additions to ASIO are: basic_secure_socket.hpp detail/openssl_crypto_initializer.hpp detail/openssl_secure_service.hpp detail/openssl_secure_session.hpp (And (to a lesser extent) the same for GnuTls.) Our question is, can we donate this to (boost::)asio? And if so, how do we approach this? Cheers, Dirk

2 1

[thread library rework] Ready to start
by Ion Gaztañaga 30 Aug '05

30 Aug '05

Hi to all, As previously discussed here, I'm trying to organize a boost thread rework in order to help C++ thread standarization. In this moment, Kevlin Henney is working on a paper to be presented int the next ISO meeting based in his C++ thread work which is available here, in this presentation-paper: http://www.two-sdg.demon.co.uk/curbralan/papers/accu/MoreC++Threading.pdf This approach proposes futures approach to C++ threads, and also defines lock mechanisms similar to boost::mutex and boost::condition with some changes. I've contacted with Kevlin and he is ready to help as much as he can with the Boost community to develop a good thread proposal. The idea is that we could have a working implementation of the proposal above boost threads. The presentation-paper does not currently cover all the functionality we have, like thread specific storage, barriers and read-write locks neither proposed message-queue, so there is a lot of work to do. There is an active discussion on futures that can be added to this effort since it proposes future-operations that are not incompatible with the proposal, but an extension. We need to keep the thread discussion constructive and effective, although any of us has strong opinions on threading. It would be nice if we could first concentrate in "basic" functionality that does not forbid future proposals. For example, thread cancellation is a hard issue, but it can be added later if the proposal allows to do that. I'm also concerned with (in my opinion) needed compatibility with Embedded C++. C++ will grow a lot in this area and obviously, threads are very used. Embedded C++ specification (http://www.caravan.net/ec2plus/) avoids templates and exceptions, so we need to think some alternatives (apart from exceptions, just like iostreams do) to do error checking. And provide some low-resource specializations or alternatives to the full-scale C++ threading. There are many areas to cover, but in this post I would like to say that the reworking effort is alive and we need to do some serious work. Like always, ideas are good but work is better, so let's try to avoid extremely long discussions so that we can have C++ threads in the following standard. I'm ready to try to organize a bit the effort and Michael Glassford, mantainer of boost threads, is ready to help, although he has no much time. Anyway, we know there are some good thread implementations out there, and we can take some ideas. And let's try to create a basic, simple, working thread tools but without forbidding extensions in the future. For the moment I've implemented the thread-launching mechanism (threader and joiner classes) described in Kevlin's paper above boost threads. It's in Boost Vault, in thread_ex directory. I plan to add more features detailed in the paper soon (mutexes, conditions, etc...) above boost threads, because it provides a good portable framework. Currently there is no other documentation that Kevlin's presentation, but I will start making some boost documentation in this library, once we start defining more elements. I will try to write some posts regarding concrete issues, like barriers, read-write mutexes or message-queues so that we can focus the work. Obviously if anyone wants to join this effort with ideas, code, organization etc... we can split the work on several issues. Regards, Ion P.D.: I plan to continue Shmem development although, I will have less time to work on it because of this threading work. I plan to upload a new snapshot soon.

4 9

serialization support for std::complex and boost::ublas::vector
by Neal Becker 29 Aug '05

29 Aug '05

Here are a couple of useful additions for serialization. std::complex is pretty trivial, and a no-brainer IMHO. I implemented support for ublas::vector unbounded_array only. Would be nice to do more, but that's all I need at the moment. #include <boost/archive/binary_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> #include <boost/serialization/split_free.hpp> template<typename Archive, typename T> inline void save (Archive &ar, const std::complex<T>& z, const unsigned int) { ar << real (z); ar << imag (z); } template<typename Archive, typename T> inline void load (Archive &ar, std::complex<T>& z, const unsigned int) { T i, r; ar >> r; ar >> i; z = std::complex<T> (r, i); } namespace boost { namespace serialization { template<class Archive, class T> inline void serialize (Archive &ar, std::complex<T>& z, const unsigned int file_version) { boost::serialization::split_free (ar, z, file_version); } } } template<class Archive, class U> inline void save (Archive &ar, const vector &v, const unsigned int) { unsigned int count = v.size(); ar << count; typename vector::const_iterator it = v.begin(); while (count-- > 0) { ar << *it++; } } template<class Archive, class U> inline void load (Archive &ar, vector &v, const unsigned int) { unsigned int count; ar >> count; v.resize (count); typename vector::iterator it = v.begin(); while (count-- > 0) { ar >> *it++; } } namespace boost { namespace serialization { template<class Archive, class U> inline void serialize (Archive &ar, vector& v, const unsigned int file_version) { boost::serialization::split_free (ar, v, file_version); } } }

7 23

Boost regression notification (2005-08-29)
by Douglas Gregor 29 Aug '05

29 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-29T15:06:11Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 69 failures in 7 libraries: foreach (28) graph (3) iostreams (1) parameter (4) python (2) serialization (30) wave (1) |foreach| array_byref: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin array_byval: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin pair_byref: vc-6_5 vc-6_5-stlport vc-7_0 pair_byval: vc-6_5 vc-6_5-stlport vc-7_0 stl_byref: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin stl_byval: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin user_defined: cw-8_3 cw-9_4 cw-9_4 vc-6_5 vc-6_5-stlport vc-7_0 |graph| graphviz_test: vc-7_1 vc-7_1 vc-7_1 |iostreams| mapped_file_test: intel-win32-9_0 |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |python| exec: intel-win32-9_0 msvc |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |wave| testwave: gcc-3.3.6-linux

1 0

Re: [boost] [regex] missing header inclusion
by François Dumont 29 Aug '05

29 Aug '05

I don't really agree that the patches for the missing headers are fixes for STLport support. They are rather fixes to make boost less Standard library implementation dependant. There are of course not many available Standard library implementations on the market but it is not a reason to make this kind of shortcut :-) Thanks for applying those, I hope I will have soon a final fix for the bjam STLport toolset as for the moment they are not correctly handling: 1. The fact STLport do not support the wrapper mode anymore 2. The modification in the library naming convention. The last issue will then be the lexical_cast problem if you remember. lexical_cast used to not handle correctly configuration with no wchar_t intrinsic support but with wstring granted by the Standard lib. Have anything change lately ? If no shouldn't this kind of config be officially not supported anymore by boost ? I can do a fix to the stlport.hpp file for that if you need it. Bests

2 2

Boost regression notification (2005-08-28)
by Douglas Gregor 28 Aug '05

28 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-28T14:52:12Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 87 failures in 8 libraries: foreach (37) functional/hash (1) graph (7) iostreams (1) parameter (4) python (6) serialization (30) wave (1) |foreach| array_byref: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_3-darwin array_byval: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_3-darwin call_once: cw-8_3 cstr_byref: cw-8_3 cstr_byval: cw-8_3 dependent_type: cw-8_3 pair_byref: cw-8_3 vc-6_5 vc-6_5-stlport vc-7_0 pair_byval: cw-8_3 vc-6_5 vc-6_5-stlport vc-7_0 rvalue_const: cw-8_3 rvalue_nonconst: cw-8_3 stl_byref: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_3-darwin stl_byval: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_3-darwin user_defined: cw-8_3 cw-9_4 vc-6_5 vc-6_5-stlport vc-7_0 |functional/hash| point: borland-5_6_4 |graph| graphviz_test: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.1-linux vc-7_1 vc-7_1 vc-7_1 |iostreams| mapped_file_test: intel-win32-9_0 |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |python| exec: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.1-linux intel-win32-9_0 msvc |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |wave| testwave: gcc-3.3.6-linux

1 0

[date_time] typo in gregorian.html
by Yuval Ronen 28 Aug '05

28 Aug '05

"proleptic" was misspelled as "propleptic". (I'm practicing for "The shortest Boost bug/doc report" competition ;-) )

2 1

RFE 1274707 (Re: [Boost.Thread]: consider removing catch(...)fromthread_proxy)
by Matt Gruenke 28 Aug '05

28 Aug '05

Coincidentally, I just filed an RFE on this very topic (something I'd been meaning to do for a while, but forgot about until I upgraded to 1.33.0). It was suggested to me that I mention it here. Actually, I'd have posted here, in the first place, but it seems I misunderstood the prerequisites for joining this list (I thought it was for code contributors, only). From the archive, I can see this thread has covered most, if not all, of my points. Still, my RFE is probably more cohesive than any single message, on this topic, I've come across in the archives: http://sourceforge.net/tracker/index.php?func=detail&aid=1274707&group_id=7… BTW, I really don't understand this continual talk of a user-supplied/overridable handler function. It still compromises debugging, and without managing to provide anything the user can't already do in the user-supplied threadfunc. (I'm only mentioning this because it's a proposal not addressed in my RFE.) Thanks for considering my views. Matt Gruenke Software Engineer IntelliVid Corp.

1 0