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

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