July 2006 - Boost - lists.boost.org

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

[asio] Modified SSL client to reproduce error
by Scott 24 Jul '06

24 Jul '06

> Can you please try the diffs included below and let me know how > it goes. Thanks! > > Cheers, > Chris Thanks for the update Chris. Is there a way I can just download the changes? I don't have a tool that can take your diffs and recreate the file. And I'm not sure I actually have the same version of the file you are diffing against. I wouldn't mind downloading the latest and greatest ASIO for Boost, if you could point me to that. :) Thanks, Scott

2 1

[system] - std::terminate() called after throw system_error
by Oliver.Kowalke＠qimonda.com 24 Jul '06

24 Jul '06

Hi, I tried boost::system-0.2.1 out. If I execute: int main( int argc, char *argv[]) { ... sys::error_code ec( EINTR, sys::errno_ec); sys::system_error se( ec); printf("%s\n", se.what() ); throw se; // terminate() called ... } std::terminate() and std::set_unexpected are called. What is going wrong? regards, Oliver

1 0

Changing the arrangement of files within our SCM
by Daryle Walker 24 Jul '06

24 Jul '06

Maybe this could be done when/if we move to Subversion, because of SVN's superior directory management. A lot of our testing and other management of Boost code is done on a per library basis. However, the product delivered to users is in a consolidated file hierarchy. The current CVS archive of the code is kept in that same hierarchy. I propose changing the version of Boost kept in our SCM system to be library based. The hierarchy could be like: General any array ... config conversion crc date_time ... variant wave Where each directory would have its own "boost" and "libs" subdirectories. (And maybe a "src" directory if we use this opportunity to move mandatory source code to a higher level.) The "General" directory is for all the administration and other files that are not part of any library. We could move each tool (e.g. BCP, Quickbook, inspect, build, etc.) to this level too. We would have to rename the directory for the Wave tool to "wave-tool" to minimize confusion. For users, we create a final archive by copying the _contents_ of each top-level directory, recursively merging the contents of repeated child directories. From their perspective, nothing has changed. Building changes radically for developers _of_ Boost code, though. They have to add the include directories for each library separately into their compiler/IDE search list. It sounds like harder work, but it's actually a good thing because it forces us to consider dependencies between libraries. It allows us to analyze each library separately. Each library can also be downloaded separately (with CVS/SVN), like we used to do a long time ago with ZIP files. I think this arrangement would synergize with the Release Overview proposal at <http://mysite.verizon.net/beman/release_overview.html>. Both proposals are supposed to help with the scaling-up of Boost. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

5 9

License reference text
by Gennaro Prota 24 Jul '06

24 Jul '06

Hi, just a quick note to remind you that the preferred text to refer to our license is not "Use, modification, and distribution are..." but // Distributed under the Boost Software License, Version 1.0. // (See accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) The "distributed under" incipit avoids any mention of what actions are subject to license and what not, which is a specification belonging to the license itself. Bibliography ;-) - <http://lists.boost.org/Archives/boost/2004/02/61200.php> -- [ Gennaro Prota, C++ developer for hire ]

4 10