- Boost - lists.boost.org

Re: [boost] Ace??? (was: ANN: POCO - C++ Portable Components)
by Sohail Somani 24 Jul '06

24 Jul '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Bennett, Patrick > Sent: Monday, July 24, 2006 2:29 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Ace??? (was: ANN: POCO - C++ Portable Components) > > > -----Original Message----- > > [mailto:boost-bounces@lists.boost.org] On Behalf Of Steven Burns > > Sent: Monday, July 24, 2006 5:18 PM > > To: boost(a)lists.boost.org > > Subject: Re: [boost] Ace??? (was: ANN: POCO - C++ Portable > Components) > > > > POCO's documentation is fine, sometimes a method could > > deserve more explanation but it's still fine given the fact > > most of the classes are very intuitive. > > Boost documentation is usually excellent, which is mandatory > > because some classes are not intuitive at first sight. > > ACE's website is simply unfriendly and looks careless. > > Poco's documentation is 'ok', but the fact that the comments for all > methods are *below* the method declarations is a style disaster. [snip] Boost docs > * But seriously, I think more libraries documented like boost would be great :)

1 0

Re: [boost] Boost's future, one big download?
by Sohail Somani 24 Jul '06

24 Jul '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Steven Burns > Sent: Monday, July 24, 2006 2:23 PM > To: boost(a)lists.boost.org > Subject: [boost] Boost's future, one big download? > > When I read posts like "proposal: boost library for african insect > classification" (joke) and things like that, I wonder what's > going to happen > to boost in the future. > Some boost libraries are already too specific and this seems > to be on the > rise. > Is boost going to be always a single download? > Is boost's goal to become a "code wikipedia"? I don't see any harm so long as the components are appropriately independent. The toughest would be if component X stopped working in the latest release, but you need Y from the latest release as a dependency for X or something silly like that. Hopefully the OSS nature of boost would help work around that. I personally haven't had an issue like that though I use a few boost libraries here and there.

1 0

Re: [boost] Ace??? (was: ANN: POCO - C++ Portable Components)
by Bennett, Patrick 24 Jul '06

24 Jul '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Steven Burns > Sent: Monday, July 24, 2006 5:18 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Ace??? (was: ANN: POCO - C++ Portable Components) > > POCO's documentation is fine, sometimes a method could > deserve more explanation but it's still fine given the fact > most of the classes are very intuitive. > Boost documentation is usually excellent, which is mandatory > because some classes are not intuitive at first sight. > ACE's website is simply unfriendly and looks careless. Poco's documentation is 'ok', but the fact that the comments for all methods are *below* the method declarations is a style disaster. Virtually no documentation or tagging tool will work with it. Its online documentation doesn't hotlink from parameter types, doesn't graphically show the relationships, doesn't show what implements and uses each method, etc. etc. Basically, things Doxygen does - which will never work with Poco's code. :( As for ACE, I fail to see what the web site for a library has to do with the quality of library itself. By that token, I guess no one should use GCC or many of the gnu tools for that matter. It also has several books available for it. This is a good thing, not a bad thing. Doxygen documentation for it is also generated nightly and is available at http://www.dre.vanderbilt.edu/Doxygen/ So what again does this all have to do with Boost? (not that I'm helping by replying to this thread) Patrick Bennett

1 0

Should we change the reply-to setting?
by Daryle Walker 24 Jul '06

24 Jul '06

Currently, the mailing list changes all the "reply-to" headers to the list's e-mail address. This forces all replies to go to the list and loses any custom e-mail address the sender may have added. I've read "'Reply-To' Munging Considered Harmful" <http://www.unicom.com/pw/reply-to-harmful.html> and now wonder if we should change our policy. (Unfortunately for me, I think I use that field from sorting my e-mail. So the list's e-mail should still be around in posts so I can sort them.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

10 20

Re: [boost] [mpl] Metafunction terminology - revival?
by JOAQUIN LOPEZ MU?Z 24 Jul '06

24 Jul '06

----- Mensaje original ----- De: David Bergman <David.Bergman(a)bergmangupta.com> Fecha: Lunes, Julio 24, 2006 8:08 pm Asunto: Re: [boost] [mpl] Metafunction terminology - revival? > Ok, two interpretations: > > 1. (Mine) What the MPL documentation calls a "lambda expression" > (as of the refered page > [http://boost.org/libs/mpl/doc/refmanual/lambda-expression.html] is > either "placeholder expression" or meta function classes *generated* > by the application of mpl::lambda, i.e., *just* the meta function > classes generated in that specific way. > > 2. (Yours) All metafunction classes are "lambda expressions." I've reread the referred page, and all I can take it to define is: a lambda expression is a metafunction class or a placeholder expression. Whether this is what the authors actually *meant* is debatable, of course. > I am admittedly biased, but I think my interpretation is the most > sound one ;-) The reason for that is that I would hesitate to call > an explicitly defined metafunction class, such as > > struct MyMeta { template<class T> apply { typedef int type; } }; > > a lambda expression. Personally, I favor your interpretation of what lambda expressions and metafunction classes should be defined to be, I was only sticking to the reference. <pedantic digression> Just to play devil's advocate, what gives a lambda expression its essence, at least in mathematical lambda calculus, is not the presence of place holders, but the ability to apply to actual arguments, and this ability can be coded with mechanisms other than placeholders. For instance, in combinatorial calculus (http://en.wikipedia.org/wiki/Combinatory_logic) all lambda expressions can be given equivalent formulations using only the combinators S and K, thus effectively avoiding the use of placeholders altogether. It could be an interesting investigation project to determine whether combinatorial methods can be modelled into the metaprogramming framework of C++ just the way lambda expressions have been. </pedantic digression> [...] > /David Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[function] const correctness violation
by Steven Watanabe 24 Jul '06

24 Jul '06

AMDG Boost.Function does not preserve const correctness for reference wrappers e.g. class function_object_type { public: void operator()() const {} }; void f() { const function_object_type const_function_object; boost::function<void()> function(boost::ref(const_function_object)); assert(function.target<function_object>() == &const_function_object); //const lost } I can see two possible solutions for this: add a flag: enum cv_qualifiers { const_ = 1, volatile_ = 1 << 1}; or don't unwrap references for target: function.target<boost::reference_wrapper<function_object> >() The first method seems preferable because it doesn't require the interface to change. In Christ, Steven Watanabe

1 0

Boost regression notification (2006-07-24 [RC_1_34_0])
by Douglas Gregor 24 Jul '06

24 Jul '06

Boost Regression test failures Report time: 2006-07-24T11:20:44Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 308 failures in 25 libraries algorithm/string (1) concept_check (1) conversion (1) filesystem (4) graph (7) io (1) iostreams (16) mpl (6) numeric/conversion (4) numeric/interval (1) numeric/ublas (7) parameter (31) program_options (9) python (100) random (1) rational (5) serialization (25) signals (16) spirit (1) statechart (1) test (3) thread (2) tr1 (55) typeof (9) utility (1) |algorithm/string| regex: borland-5_6_4 |concept_check| class_concept_check_test: vc-7_1-stlport |conversion| lexical_cast_test: sun-5.8 |filesystem| mbcopy: sun-5.8 operations_test: vc-7_1-stlport operations_test_dll: vc-7_1-stlport wide_test: sun-5.8 |graph| adjacency_matrix_test: vc-7_0 csr_graph_test: sun-5.8 dijkstra_cc: msvc-7.1 graphviz_test: msvc-8.0 msvc-8.0 msvc-8.0 vc-7_1-stlport |io| ios_state_unit_test: gcc-4.1.0_linux_x86_64 |iostreams| bzip2_test: msvc-7.1 msvc-7.1 msvc-8.0 msvc-8.0 compose_test: borland-5_6_4 example_test: vc-6_5-stlport filtering_stream_test: vc-7_1-stlport finite_state_filter_test: cw-9.4 gzip_test: msvc-7.1 msvc-7.1 msvc-8.0 msvc-8.0 zlib_test: msvc-7.1 msvc-7.1 msvc-8.0 msvc-8.0 |mpl| multiset: gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 vector_c: sun-5.8 |numeric/conversion| converter_test: borland-5_8_2 traits_test: borland-5_8_2 udt_example_0: borland-5_8_2 udt_support_test: borland-5_8_2 |numeric/interval| test_float: vc-7_1-stlport |numeric/ublas| concepts: vc-7_1-stlport vc-7_1-stlport test1: vc-7_1-stlport test2: vc-7_1-stlport test4: vc-7_1-stlport test5: vc-7_1-stlport vc-7_1-stlport |parameter| basics: borland-5_6_4 borland-5_8_2 duplicates: borland-5_6_4 borland-5_8_2 earwicker: borland-5_6_4 borland-5_8_2 macros: borland-5_6_4 borland-5_8_2 maybe: vc-6_5 vc-6_5-stlport vc-7_0 mpl: borland-5_6_4 borland-5_8_2 preprocessor: borland-5_6_4 borland-5_8_2 sun-5.8 vc-6_5 vc-6_5-stlport python-parameter-test: vc-6_5 vc-6_5-stlport vc-7_0 sfinae: borland-5_6_4 borland-5_8_2 vc-6_5-stlport singular: borland-5_6_4 borland-5_8_2 unnamed: borland-5_6_4 borland-5_8_2 unnamed_fail: vc-6_5 vc-6_5-stlport vc-7_0 |program_options| cmdline_test_dll: cw-9.4 options_description_test_dll: cw-9.4 parsers_test_dll: cw-9.4 positional_options_test_dll: cw-9.4 unicode_test_dll: borland-5_8_2 cw-9.4 variable_map_test_dll: borland-5_8_2 cw-9.4 winmain_dll: cw-9.4 |python| andreas_beyer: sun-5.8 args: sun-5.8 auto_ptr: sun-5.8 back_reference: sun-5.8 bases: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-3_4_4_tru64 gcc-4.1.1_sunos_i86pc sun-5.8 ben_scott1: sun-5.8 bienstman1: sun-5.8 bienstman2: sun-5.8 bienstman3: sun-5.8 borrowed: sun-5.8 callbacks: sun-5.8 const_argument: sun-5.8 crossmod_exception: sun-5.8 data_members: sun-5.8 defaults: sun-5.8 dict: sun-5.8 docstring: sun-5.8 enum: sun-5.8 exception_translator: sun-5.8 exec: cw-9.4 darwin-4.0.1 gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-3_4_4_tru64 gcc-4.1.1_sunos_i86pc msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp sun-5.8 extract: sun-5.8 implicit: sun-5.8 indirect_traits_test: sun-5.8 injected: sun-5.8 iterator: sun-5.8 keywords: sun-5.8 list: sun-5.8 long: sun-5.8 minimal: sun-5.8 multi_arg_constructor: sun-5.8 nested: sun-5.8 numpy: sun-5.8 object: sun-5.8 object_manager: sun-5.8 opaque: sun-5.8 operators: sun-5.8 pearu1: sun-5.8 pickle1: sun-5.8 pickle2: sun-5.8 pickle3: sun-5.8 pickle4: sun-5.8 pointee: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-3_4_4_tru64 gcc-4.1.1_sunos_i86pc sun-5.8 pointer_type_id_test: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-3_4_4_tru64 gcc-4.1.1_sunos_i86pc sun-5.8 pointer_vector: sun-5.8 polymorphism: sun-5.8 polymorphism2: sun-5.8 polymorphism2_auto_ptr: sun-5.8 properties: sun-5.8 raw_ctor: sun-5.8 return_arg: sun-5.8 select_arg_to_python_test: sun-5.8 select_from_python_test: darwin-4.0.1 sun-5.8 select_holder: sun-5.8 shared_ptr: sun-5.8 slice: sun-5.8 staticmethod: sun-5.8 stl_iterator: sun-5.8 str: sun-5.8 string_literal: sun-5.8 test_pointer_adoption: sun-5.8 try: sun-5.8 tuple: sun-5.8 upcast: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-3_4_4_tru64 gcc-4.1.1_sunos_i86pc sun-5.8 vector_indexing_suite: sun-5.8 virtual_functions: sun-5.8 voidptr: sun-5.8 wrapper_held_type: sun-5.8 |random| random_test: intel-linux-9.0 |rational| rational_test: borland-5_6_4 sun-5.8 vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_class_info_load_text_warchive: vc-6_5 test_derived_class_ptr_xml_warchive: msvc-8.0 test_non_default_ctor2_text_archive: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_archive_dll: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_warchive: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_warchive_dll: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_reset_object_address: vc-7_0 test_reset_object_address_dll: vc-7_0 test_simple_class_binary_archive_dll: vc-6_5 test_simple_class_text_archive_dll: vc-6_5 test_simple_class_text_warchive_dll: vc-6_5 test_simple_class_xml_archive_dll: vc-6_5 test_simple_class_xml_warchive_dll: vc-6_5 test_variant_xml_archive: borland-5_8_2 test_variant_xml_archive_dll: borland-5_8_2 test_variant_xml_warchive: borland-5_8_2 test_variant_xml_warchive_dll: borland-5_8_2 |signals| dead_slot_test: gcc-3.3.6 gcc-3.3.6_linux qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp trackable_test: gcc-3.3.6 gcc-3.3.6_linux qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp |spirit| mix_and_match_trees: sun-5.8 |statechart| FifoSchedulerTestNormal: msvc-8.0 |test| boost_check_equal_str: sun-5.8 parameterized_test_test: vc-6_5 vc-6_5-stlport |thread| test_mutex: msvc-7.1 test_mutex_lib: msvc-7.1 |tr1| run_random: sun-5.8 std_run_complex_overloads: sun-5.8 std_run_random: sun-5.8 std_test_bind: sun-5.8 std_test_complex: sun-5.8 std_test_function: sun-5.8 std_test_hash: sun-5.8 std_test_mem_fn: sun-5.8 std_test_random: sun-5.8 std_test_reference_wrapper: sun-5.8 std_test_reference_wrapper_tricky: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4_0_3_tru64 intel-linux-9.0 mingw-3_4_2 msvc-7.1 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp vc-7_1-stlport std_test_result_of: sun-5.8 std_test_shared_ptr: sun-5.8 std_test_tuple: sun-5.8 std_test_tuple_tricky: sun-5.8 std_test_type_traits: sun-5.8 test_boost: vc-7_1-stlport test_hash: vc-7_1-stlport test_random: sun-5.8 vc-7_1-stlport test_reference_wrapper_tricky: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4_0_3_tru64 intel-linux-9.0 mingw-3_4_2 msvc-7.1 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp test_regex: vc-7_1-stlport test_type_traits: sun-5.8 tr1_tky_function_type_test: sun-5.8 |typeof| function_binding_emulation: sun-5.8 function_binding_native: vc-6_5 vc-6_5-stlport vc-7_0 nested_typedef_emulation: cw-9.4 odr_no_uns: vc-6_5 vc-6_5-stlport vc-7_0 template_tpl_emulation: sun-5.8 |utility| operators_test: gcc-3.4.5_linux_x86_64

1 0

Interested? Simplify usage of std::rel_ops
by Christopher Eltschka 24 Jul '06

24 Jul '06

Hi, I have a very simple header to simplify use of std::rel_ops with user defined classes, and I thought it might be interesting for inclusion in boost. It seems to work perfectly on gcc 4.0.2 20050901 (prerelease) (SUSE Linux), and I believe it's standard conforming. I haven't checked it with any other compiler, though. The usage is simple: You just write (with my current header, which of course would have to be adapted for boost): ---------------------------------------------------------------------- #include "relops.h" class MyClass: rel::ops // doesn't matter if you use public or private inheritance { // ... }; bool operator<(MyClass const&, MyClass const&) { /* ... */ } bool operator==(MyClass const&, MyClass const&) { /* ... */ } // now you can use all comparison operators: int main() { MyClass a, b; bool b = (a > b) // uses std::rel_ops::operator> } ---------------------------------------------------------------------- operator< and operator== of course can be defined anywhere the std::rel_ops operators will find them (e.g. they could be defined as class members instead). The header is obviously too simple to warrant its own boost library, but I could imagine it to be included e.g. in Boost.Utility. Alternatively it could be extended to support other typical operator implementations not covered by the standard, e.g. defining operator@ in terms of operator@=. Here's the actual code of the header: ---------------------------------------------------------------------- #ifndef RELOPS_H_INC #define RELOPS_H_INC #include <utility> namespace rel { using std::rel_ops::operator!=; using std::rel_ops::operator>; using std::rel_ops::operator>=; using std::rel_ops::operator<=; class ops {}; } #endif ---------------------------------------------------------------------- The trick is that by deriving from class rel::ops, you get the namespace rel looked into during Koenig lookup for function calls, esp. operators, involving your class type. Now, in namespace rel, the operators from std::rel_ops are found due to the explicit using declarations (obviously it would have been easier just to add class ops into std::rel_ops, but that's unfortunately prohibited by the standard). Deriving from class ops doesn't bring anything into your class than the additional Koenig lookup target, and with empty base class optimization it shouldn't affect your class otherwise as well. So what do you think?

6 14

[thread] new & improved tss_hooks.cpp
by Peter Dimov 24 Jul '06

24 Jul '06

I've attached a proposed simplification of libs/thread/src/tss_hooks.cpp that eliminates the one-time allocation that's been bugging people because their tools report it as a leak. If there are no objections, I'll commit this change to the CVS HEAD.

2 7

program_options windows assertion
by Ryan, Paul L. 24 Jul '06

24 Jul '06

I'm working on a program with which we are using the boost::program_options module and ran into an odd assertion in the xstring library used by said module. The program was compiled using VC++ 8 and the Platform SDK Windows Server 2003 SP1. The assertion occured when the total string length (spaces + options + arg defaults + description) was over about 80 characters and was not formatted with a \n or the like. The assertion was xstring:173 ("_Myptr + _Off <=(((_Mystring *)this->_Mycont)->_Myptr()+((_Mystring *)->_Mycont)->_Mysize)&&+_Off >= ((_Mystring *)this->_Mycont)->_Myptr()", 0). and a call stack on one of the programs this occurred on can be seen below. This has occurred for a number of applications we have that all have the same condition. Thank you in advance for your assitance > IMNManager.exe!std::_String_const_iterator<char,std::char_traits<char>,std:: allocator<char> >::operator+=(int _Off=-1) Line 171 + 0x78 bytes C++ IMNManager.exe!std::_String_const_iterator<char,std::char_traits<char>,std:: allocator<char> >::operator-=(int _Off=1) Line 188 C++ IMNManager.exe!std::_String_const_iterator<char,std::char_traits<char>,std:: allocator<char> >::operator-(int _Off=1) Line 193 + 0xc bytes C++ IMNManager.exe!boost::program_options::`anonymous namespace'::format_paragraph(std::basic_ostream<char,std::char_traits<char> > & os={...}, std::basic_string<char,std::char_traits<char>,std::allocator<char> > par="Used to specify the debugged namespaces", unsigned int first_column_width=41, unsigned int line_length=79) Line 381 + 0x28 bytes C++ IMNManager.exe!boost::program_options::`anonymous namespace'::format_description(std::basic_ostream<char,std::char_traits<char > > & os={...}, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & desc="Used to specify the debugged namespaces", unsigned int first_column_width=41, unsigned int line_length=79) Line 453 + 0x34 bytes C++ IMNManager.exe!boost::program_options::`anonymous namespace'::format_one(std::basic_ostream<char,std::char_traits<char> > & os={...}, const boost::program_options::option_description & opt={...}, unsigned int first_column_width=41, unsigned int line_length=80) Line 489 + 0x1a bytes C++ IMNManager.exe!boost::program_options::options_description::print(std::basic _ostream<char,std::char_traits<char> > & os={...}) Line 522 + 0x1e bytes C++ IMNManager.exe!boost::program_options::operator<<(std::basic_ostream<char,st d::char_traits<char> > & os={...}, const boost::program_options::options_description & desc={...}) Line 289 C++ Paul Ryan SAIC

1 0