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

[serialization] Archive implementation
by Matthias Troyer 25 Sep '05

25 Sep '05

Hi Robert, After tracking down a linker error I realized that #include <boost/archive/impl/archive_pointer_oserializer.ipp> #include <boost/archive/impl/archive_pointer_iserializer.ipp> need to be included for all new archives that a user might develop, in order to allow serialization of pointers. Are there other such *.ipp files that an archive developer needs to watch out for? Matthias

1 0

integer_mask for long long
by Aschwin Gopalan 25 Sep '05

25 Sep '05

Hi boosters, I am trying to do a small template based fixed-point arithmetic library and I am using integer_mask.hpp to extract some bit-masks I need. Everything works as expected as long as my fixed-point numbers are not larger than 32bit. I am on Intel hardware using gcc and there is long long, wich is 64bit. I would like to be able to use it together with my fixed point template, but integer_mask.hpp works only up to long. Is there a compelling reason for this? Greetings, Aki

2 2

Re: [boost] xml parser
by mario contestabile 25 Sep '05

25 Sep '05

Anyone have/know of boost samples of simple xml parsing (name-values)? thanx

2 1

Boost regression notification (2005-09-24 [RC_1_33_0])
by Douglas Gregor 24 Sep '05

24 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-24T14:56:09Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 74 failures in 6 libraries: foreach (1) graph (5) random (1) range (3) serialization (56) thread (8) |foreach| rvalue_const: vc-7_1 |graph| betweenness_centrality_test: gcc-3.4.4-linux dag_longest_paths: gcc-3.4.4-linux dijkstra_cc: gcc-3.4.4-linux dijkstra_heap_performance: gcc-3.4.4-linux relaxed_heap_test: gcc-3.4.4-linux |random| random_test: gcc-3.3.6-linux |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_contained_class_xml_archive: gcc-3.2.3-linux test_exported_binary_archive: vc-6_5 test_exported_binary_archive_dll: vc-6_5 test_exported_text_archive: vc-6_5 test_exported_text_archive_dll: vc-6_5 test_exported_text_warchive: vc-6_5 test_exported_text_warchive_dll: vc-6_5 test_exported_xml_archive: vc-6_5 test_exported_xml_archive_dll: vc-6_5 test_exported_xml_warchive: vc-6_5 test_exported_xml_warchive_dll: vc-6_5 test_no_rtti_binary_archive: vc-6_5 test_no_rtti_binary_archive_dll: vc-6_5 test_no_rtti_text_archive: vc-6_5 test_no_rtti_text_archive_dll: vc-6_5 test_no_rtti_text_warchive: vc-6_5 test_no_rtti_text_warchive_dll: vc-6_5 test_no_rtti_xml_archive: vc-6_5 test_no_rtti_xml_archive_dll: vc-6_5 test_no_rtti_xml_warchive: vc-6_5 test_no_rtti_xml_warchive_dll: vc-6_5 test_shared_ptr_132_binary_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_binary_archive_dll: vc-6_5 test_shared_ptr_132_text_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_archive_dll: vc-6_5 test_shared_ptr_132_text_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_warchive_dll: vc-6_5 test_shared_ptr_132_xml_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_archive_dll: vc-6_5 test_shared_ptr_132_xml_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_warchive_dll: vc-6_5 test_shared_ptr_binary_archive: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive_dll: borland-5_6_4 vc-6_5 |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

1 0

Boost regression notification (2005-09-24 [HEAD])
by Douglas Gregor 24 Sep '05

24 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-24T05:00:09Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. utility/enable_if typeof Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 185 failures in 16 libraries: concept_check (14) filesystem (8) foreach (7) graph (4) math (3) mpl (2) numeric/ublas (1) parameter (17) python (1) regex (1) serialization (40) spirit (2) thread (24) typeof (41) utility/enable_if (16) wave (4) |concept_check| stl_concept_covering: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 msvc vc-7_1 vc-7_1 |filesystem| convenience_test: msvc default_name_check_test: msvc fstream_test: msvc large_file_support_test: msvc operations_test: msvc operations_test_dll: msvc path_test: msvc path_test_dll: msvc |foreach| user_defined: cw-8_3 cw-9_4 cw-9_5-darwin msvc vc-6_5 vc-6_5-stlport vc-7_0 |graph| graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |math| octonion_test: gcc-4_0-darwin quaternion_test: gcc-4_0-darwin special_functions_test: gcc-4_0-darwin |mpl| size_t: gcc-4_0-darwin gcc-4_0-darwin |numeric/ublas| concepts: vc-7_1 |parameter| basics: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc macros: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux sfinae: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc unnamed: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux vc-7_1 |python| data_members: msvc |regex| static_mutex_test: msvc |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos 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 test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos 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 test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos 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 |spirit| traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_barrier: msvc test_barrier_lib: intel-9.0-linux msvc test_condition: msvc test_condition_lib: intel-9.0-linux msvc test_mutex: msvc test_mutex_lib: intel-9.0-linux msvc test_once: msvc test_once_lib: intel-9.0-linux msvc test_read_write_mutex: msvc test_read_write_mutex_lib: intel-9.0-linux msvc test_thread: msvc test_thread_lib: intel-9.0-linux msvc test_tss: msvc test_tss_lib: intel-9.0-linux msvc test_xtime: msvc test_xtime_lib: intel-9.0-linux msvc |typeof| data_member_emulation: cw-9_4 data_member_native: intel-win32-9_0 intel-win32-9_0 function_emulation: cw-9_4 function_native: intel-win32-9_0 intel-win32-9_0 msvc function_ptr_emulation: cw-9_4 function_ptr_native: intel-win32-9_0 intel-win32-9_0 function_ref_emulation: cw-9_4 function_ref_native: intel-win32-9_0 intel-win32-9_0 lvalue_emulation: cw-9_4 lvalue_native: intel-win32-9_0 intel-win32-9_0 msvc member_function_emulation: cw-9_4 member_function_native: intel-win32-9_0 intel-win32-9_0 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_int_emulation: cw-9_4 template_int_native: intel-win32-9_0 intel-win32-9_0 template_tpl_emulation: cw-9_4 template_tpl_native: intel-win32-9_0 intel-win32-9_0 msvc template_type_emulation: cw-9_4 template_type_native: intel-win32-9_0 intel-win32-9_0 type_emulation: cw-8_3 cw-9_4 cw-9_4 type_native: intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 intel-win32-9_0 |utility/enable_if| constructors: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux dummy_arg_disambiguation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux lazy: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux lazy_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux member_templates: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux namespace_disambiguation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux no_disambiguation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux partial_specializations: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-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

[xpressive] formal review
by John Maddock 24 Sep '05

24 Sep '05

Finally, too late for even the extended deadline, here's my xpressive review: *What is your evaluation of the design? It's very good. I have to admit that I find the static regexes very hard to read, but a lot of that will be a cultural problem: I'm so used to seeing normal regex syntax that I can't quite get my head around the static versions, the quantifiers as prefixes particularly throw me. However, the syntax is concise and consistent with spirit, so I can hardly complain that much. Possibly xpressive isn't the last word on this, or the best way to go, personally I prefer more verbose forms like repeat(x) rather than *x but again, that's an initial reaction which may change with more familiarity. * What is your evaluation of the implementation? Looks good to me, and I know from past experience that Eric knows what he's doing. The only complaint I have is one that's common to all expression template code: it's impossible to understand by debugging, which means casual maintenance by folks other than the author would be hard, you really need to read the whole source before you can get a grip on what it's doing (OK you ought to do that anyway, but it is still hard to understand code that isn't executed in the traditional sense). As I said though this is an issue with all metaprogramming, and expression templates in particular, I guess what we really need is a compile-process debugger :-) * What is your evaluation of the documentation? It's excellent. * What is your evaluation of the potential usefulness of the library? Clearly there are lots of uses. There is also overlap with Regex and Spirit, but I don't believe that should prevent acceptance, Boost is meant to drive forward innovation after all. * Did you try to use the library? With what compiler? Did you have any problems? Not for as long as I would have liked :-( I've only tried with VC7.1, the sample code compiled cleanly, but compile times were quite long for even simple static regexes, I didn't try anything complex. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A couple hours reading the docs, and playing with some of the samples. One thing I did notice is that several of the test programs don't appear to do anything except "return 0", I'm not sure if these are deprecated, or just not finished (see test_regex_token_iterator.cpp for example). The test cases in the testX.cpp files may be a little short on the ground as well: Boost.Regex has about a thousand cases, PCRE a similar number, where as there are 171 here. The smaller number of cases ought to be enough, but in practice I've found you can never have too many! It's a pity that the Boost.Regex and / or PCRE cases can't be automatically harvested, but I suspect this is next to impossible for static regexes? * Are you knowledgeable about the problem domain? I hope so :-) * Do you think the library should be accepted as a Boost library? Absolutely. John.

2 1

[preprocessor] Proposal to add a unique names generating macro
by Andrey Semashev 24 Sep '05

24 Sep '05

I have mentioned this in a nearby thread about scope_guard, but I believe it missed the addresee. I purpose to add a macro to Boost.PP that will expand to some unique in translation unit scope name. I needed such functionality to generate unique variable names for anonymous scope guards, but I believe there are places in Boost that reimplement similar functionality (BOOST_STATIC_ASSERT does the same, from the top of my head). My implementation example is availeble in: http://boost-consulting.com/vault/index.php?action=downloadfile&filename=sc… See the file boost/guard/unique_name.hpp, BOOST_SG_UNIQUE_NAME macro. PS: I don't actually insist on Boost.PP to be the place for such macro, but I think it should be in some common place and be available to end users.

1 0

Re: [boost] BOOST_ASSERT and __assume
by brangdon＠cix.compulink.co.uk 24 Sep '05

24 Sep '05

In-Reply-To: <dh1gjf$bt0$1(a)sea.gmane.org> kalita(a)poczta.onet.pl (Marcin Kalicinski) wrote (abridged): > On the other hand some people (including me) consider __assume to be > nice, helping optimization and suppressing annoying warnings. Including me, too. I don't think anyone has spoken against __assume in principle. The issue has been how best to incorporate it. > Put __assume in BOOST_ASSUME and leave BOOST_ASSERT unmodified. This to me is the safest option. > Pros: > - does not disturb existing code in any way > > Cons: > - no existing code uses it, i.e. all existing libraries would have to > be modified to take advantage of it; this will probably never happen so > most of the code will not benefit __assume is a performance optimisation. As such I think it is fine for it to be adopted primarily in places where someone has seen the need (and in new code). It doesn't need to be adopted in /all/ libraries. If no-one thinks __assume is valuable enough to be worth changing old code to use it, perhaps it is not worth adding to boost at all. Is it entirely a Microsoft thing, or would some other compilers benefit too? > - obscure: most of the people would be confused about it when seeing it > for the first time Surely no more so than any other boost library? I'd have thought it would be even more confusing if BOOST_ASSERT changed its meaning. At least the people who don't know what ASSUME means know they don't know, and can look it up. A change to ASSERT will slip under many people's guard. BOOST_ASSERT and BOOST_ASSUME have different semantics. I think it's good to let authors express which semantics they intended. > 2. BOOST_ASSERT + define to enable assume (default: on) > Cons: > > - breaks user code which uses BOOST_ASSERT in "uncommon" way. And boost code as well. Probably there is no such code in boost, but I don't think anyone has gone through it all to check. Perhaps no user code would be broken either. To me this really feels like a gambler's option. Silently breaking users code is unacceptable, but maybe we are feeling lucky tonight. Or maybe we just don't care, and can rule such code unsupported. > BOOST_ASSERT + define to enable assume (default: off) > - does enable assume on all the boost code, some user programs get > smaller and faster with a simple -D"BOOST_ASSERT_USE_ASSUME" on command > line. In order to switch it on safely they need to know that every use of BOOST_ASSERT in every module they link, and every header they #include, is safe with the new semantics. I don't see how they can know this without laboriously checking every place where BOOST_ASSERT is used and thinking hard about the semantics of each one. This has to be repeated for every new release of the libraries. It's a ton of work, repeated once for each user. To me it makes far more sense for the work to be done once by the author of the code that uses the assert, and for the result of that analysis to be recorded in the code for all time by renaming from BOOST_ASSERT to BOOST_ASSUME. This will also help anyone reading the code. Another drawback of the global flag is that if just one place turns out to require the old semantics, no other places can use the new semantics. The whole app suffers. (It'd be tempted to define BOOST_ASSERT_USE_ASSUME for some modules and not others, but that leads to violation of the One Definition Rule.) In practice I think this option is the same as the previous one. Both are saying the "uncommon" uses are not supported any more. Certainly they can't be used within any library code, because the author doesn't know what options the user will compile it with. I don't think we want to double the testing burden by testing both with and without -D"BOOST_ASSERT_USE_ASSUME". The effect of -D"BOOST_ASSERT_USE_ASSUME" is to inject undefined behaviour into the code. To me that is huge. It's not a minor change of semantics. -- Dave Harris, Nottingham, UK.

1 0

[scope_guard] Naming roundup
by Andrey Semashev 24 Sep '05

24 Sep '05

So, there was a really interesting and hot discussion about namings. Many opinions were expressed and I'd like to make some roundup. These are the variants looked most suitable to me as the names of status modification functions: - arm/disarm. Although, noone have said anything about them, they are still in the current implementation and look quite applicable. - activate/deactivate (enable/disable). Other synonims for arm/disarm, a bit longer though. - on/off. The most laconic form. Though, these are not verbs as usually used for functions. One might think they are some getter functions. - guard/dismiss. On the on hand, the commonly used "dismiss" should look familiar. On the other, its meaning is too strong in regard of the function semantic. The "guard" may be used as well but the word is already frequently used. Besides, the guard's status enum values' names propably won't corellate with these words (I just don't see the active status name with root "guard" - guard::guarding? :( ). The other versions looked less reflective to me so I didn't include them in the list. I would be glad if you just vote for one of these positions to take the final decision. The make_guarded_call function name seems does not attract that much attention, so I shall leave it be. Besides, it it possible that I even remove it from the library, because it can be easily replaced by explicit "do" functor call and make_guard followed by it. Unfortunately, nearly no attention have been paid to the implementation itself, so there's nothing much to roundup here. PS: Still the question about checking in the library is arisen. The naming changes are 5 minutes worth, so the final version will be available very soon with almost no code changes. Will someone want to make a code revision or may I just gain access and checkin?

5 13

[serialization] boost::tuple
by troy d. straszheim 24 Sep '05

24 Sep '05

Serialization of tuple. This will come in handy when revamping serialization tests... http://svn.resophonic.com/pub/boost/boost/serialization/tuple.hpp http://svn.resophonic.com/pub/boost/libs/serialization/test/test_tuple.cpp -t

7 8