July 2006 - Boost - lists.preview.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 9:11 pm Asunto: Re: [boost] [mpl] Metafunction terminology - revival? > Joaquin wrote: > > [snip] > > > 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. > > What I think it literally means is that a lambda expression is > either a metafunction class or a placeholder expression, much > like a woman is either nice or mean. This does NOT imply that all > nice people are women ;-) So, I think even the literal reading of > the refered sentence(s) leaves room for non-lambda-expressive > metafunction classes... "A woman is either nice or mean" is not a definition of the term "woman", yet the referred page stands for a definition of "lambda expression", so an "if and only if" implication is assumed. OK, Abrahams and Gurtovoy's book's chapter 3 has been webpublished at artima.com and there you can read the following: ( http://www.artima.com/cppsource/metafunctions2.html ) "We'll refer to metafunction classes like add_pointer_f and placeholder expressions like boost::add_pointer<_1> as lambda expressions." (add_pointer_f is a metafunction class defined a couple of paragraphs before.) Does this convince you? Anyway, we're not discussing Aristotle or Descartes, on the contrary we enjoy the presence of MPL authors amongst us and can always ask them directly. [This does not detract from the fact that your choice of terminology is probably superior, I'm only nitpicking you for the joy of discussion. I hope you're taking it similarly :) ] > [...] > > <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, > > No, that is not true, actually, since that essence of > applicability is best captured by the notion of "function." A > lambda expression is a special type of function (or, rather, > lambda expressions are isomorphic to a set of functions...) I'd say lambda calculus captures aplicability better than the cartesian definition of function as a special subset of a product set AxB, but well, it's hard to argue this objectively. [...] > /David Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

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

[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

[Boost-bugs] [ boost-Feature Requests-1527717 ] [program_options] Allow unrecognized options in configfile
by SourceForge.net 24 Jul '06

24 Jul '06

Feature Requests item #1527717, was opened at 2006-07-24 14:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1527717&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Enrico Scholz (ensc) Assigned to: Nobody/Anonymous (nobody) Summary: [program_options] Allow unrecognized options in configfile Initial Comment: It would be nice when the config-file parser would have a similar mechanism to allow and collect unregistered options like the command-line parser. E.g. with the command-line parser I can use the allow_unregistered() method, but config-file parser throws always a boost::program_options::unknown_option exception. I want this feature e.g. to express things like | module = A | module = B | [A] | foo = X | [B] | bar = Y where the options in the [A] and [B] sections are unknown at the first pass. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1527717&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Quan was [PQS] Roadmap
by Andy Little 24 Jul '06

24 Jul '06

Hi, Since I ultimately intend to resubmit Quan to boost and in light of the recent PQS review, I hope that this message isnt O.T. Note also the Quan mailing list. ( I guess it would be wise to take any followups off the boost developers list) *** Quan Draft Roadmap *** Please note that the views expressed here are my personal views (and possibly ramblings) on the direction that Quan should take. They arent set in stone, so please feel free to argue any points and suggest other directions that the library should take. Also please feel free to add anything else. I have set up a Quan mailing list at quan-matters(a)lists.sourceforge.net. I hope that can be the main vehicle for discussion related to Quan. You can subscribe at: https://lists.sourceforge.net/lists/listinfo/quan-matters Alternatively you can mail me at andy attt servocomm dottt freeserve dottt co dottt uk (Please put something obviously not spamlike as the subject line!) Unfortunately the Quan roadmap isnt as detailed or finished as I would like , but I thought it better to get it out in its current state that not at all. **Personal Philosophy for Quan** Quan is designed simply to make the programmers life easier. The quan::fixed_quantity, available in the Alpha quan release available at: http://sourceforge.net/project/showfiles.php?group_id=170593 is intended to be an example of that philosopy. IMO it wraps up some complicated functionality in a simple entity. The latest state of fixed_quantity is also available via CVS at: http://quan.cvs.sourceforge.net/quan/ (my latest code and docs is currently in the concept_08_July_2006-branch.) The Quan library firstly needs good documentation. Unfortunately good documentation is extremely hard and time consuming to write, but it has to be done for a public library. I hope that the Quan library will be useful for advanced uses, but at the same time I want a library that is designed for use by mere mortals like me too. It may be difficult to reconcile simplicity with advanced Maths, but nevertheless that should be one of Quan's goals. The library also needs to be correct, so alongside documentation there need to be a comprehensive set of Unit tests for any functionality. The library is intended one day to become part of the Boost distro http://www.boost.org, therefore the code, documentation and tests should be written with boost compatibility in mind. ****The Quan project status**** The Quan project uses the boost license: http://www.boost.org/more/license_info.html Quan is dependent on the latest version of the Boost distro http://www.boost.org, which can be downloaded here: http://sourceforge.net/project/showfiles.php?group_id=7586 Quan is currently using the CVS version control system. A useful page about using CVS is available here: http://cvsbook.red-bean.com/cvsbook.html If you are interested in working on the Quan project then a reasonable knowledge of CVS will be necessary. The best way to learn the system is to set up a local database and practise on that. (It might also be a good idea to download the Quan code and try it out, to see if you like it!) If boost moves to SVN then Quan will follow after watching their progress, but meanwhile Quan should stay in step with Boost IMO. ** Full functionality ** Quan will need a lot of associated functionality to be useful in real world projects. This to me means it needs firstly vectors and point vectors, and secondly some way to transform them in 2D and 3D. the discussion during the review of PQS on the boost developers list should be a source of inspiration. Maybe 3rd party libraaies can be used, but I havent found them yet and I reckon they will need to be written for Quan. There is an obvious dependence of such functionality on the Concepts of what a Quantity is, so work on the Quan Concepts documentation needs to be considered high priority. ****Quan parts needing immediate attention **** *** quan::fixed_quantity aka pqs::t1_quantity *** Its probably time to stop changing the interface of fixed_quantity for trivial reasons, so fixed_quantity should basically stay as it is unless major issues are found. I believe that the fixed_quantity interface (ie quan::length::mm) is quite stable in overview and has been for some time in its previous incarnation pqs. I have been doing some work on Concepts, docs and improving the low level scaling /unit conversion code, which are currently in CVS on concept_08_July_2006-branch (merged to main trunk today 17/July/2006) . ***The Quan units database*** I have a local database and associated application used for generating the Quan headers and units html. Ideally the database would be on the Sourceforge database system and CGI scripts used to generate headers remotely and possibly add (after human vetting) quantities to the database. My local database application was only designed to generate headers on my own system. Ideally it would be rewritten using maybe DTL http://dtemplatelib.sourceforge.net/ or SOCI http://soci.sourceforge.net/ library. DTL says it provides cross-platform access including Access2000 (my local database) and MySQL (sourceforge database)), which would suit me but, whatever way its achieved, the database should be upgraded and moved into MySQL on Sourceforge. Needs investigating. If anyone is interested I will put the source for my local acccess in the Quan CVS. It is however raw source for Windows without any docs. Once up on Sourceforge the database needs to be filled with quantities and units (and constants). Then it can go about its business of generating headers and documentation. There is also work on a Units database and XML schema by NIST http://unitsml.nist.gov/ The idea of being able to communicate physical quantities across applications is intended to be embodied in UnitsML. This should be taken into consideration in design of the database. The philosophy of UnitsML looks very close to Quan , so compatibility with UnitsML should be mandatory. I think it is also worth getting in touch with the authors of UnitsML and UnitsDB soon too to let them know about the Quan project as a potential application. *** Unit tests ** The unit tests are improving, but still need work. Firstly to be more comprehensive. Some are still just empty functions waiting to be filled in. Another issue is portability. For example in using various Quan default real types, where double is often hard coded, and second in mirroring the exact expression used in the implementation calculation, in the comparison test calculation. The detailed semantics of the fixed_quantity need sorting out so that it should be as predictable as possible. Floating point control and predictability is an important goal and the current release is slightly loose in this respect. It would be nice to take advantage of the Sourceforge compile farm for unit tests. *** Addition of the multiunit_quantity and the uni_quantity to the library*** (Alternative Name suggestions please :-) ) Work on the other 2 quantity types needs to be started. **For the multiunit_quantity** The one that can change its units at runtime. Uses of the multiunit_quantity are intended to be for User I/O Dialog Boxes (or Widgets) and the like. The multiunit_quantity should play well with the fixed-quantity of course. I have a prototype at http://www.servocomm.freeserve.co.uk/Cpp/pqs-2-00-02/pqs-2-00-02.zip which I was reasonably happy with and if I write it that will be the approach I will take. Again in http://www.servocomm.freeserve.co.uk/Cpp/pqs-2-00-02/pqs-2-00-02.zip there are some examples of this type of use. Working on multiunit_quantity may be tricky until the fixed_quantity implementaion and low level code is more stable however as (at least how I did it) it made much use of the fixed-quantity unit conversion code. **For the uni_quantity** The one that can change its dimension and units at runtime Potential uses for this type are in testing inside matrices, where the type can be switched in for Dimensional Analysis checking and anywhere that a quantity must be created at runtime, maybe for reading from XML or a database for example. I did a quick prototype for a uni_quantity, . The main problem is the size in the obvious implementation. IIRC it used around 60 bytes of memory per object. Maybe that is acceptable, maybe not. An alternative approach might be providing a handle to a hash map of dimensions and units. Anyway this needs to be investigated. ***Quan space*** After the discussions of PQS on Boost the vect <quan/three_d/vect.hpp> needs to be rewritten to cater for 2D 3D etc e.g vect<N,T>. The rationale is to write code that can be used in N dimensional space. I am very keen to get 2D and 3D entities in Quan. Including vectors, homogeneous transform matrices and quaternions. The classic use case for me is representing the airflow around a wind turbine. There are have been various suggestions that third party libraries can be used, but I dont see the libraries and I think Quan will have to provide its own at least to show it can be done. *** Complex quantities*** Again in http://www.servocomm.freeserve.co.uk/Cpp/pqs-2-00-02/pqs-2-00-02.zip there is code for a complex quantity. This needs to be ported to Quan. The issues of infinities caused problems in the previous version IIRC, so this needs to be addressed. (Partly my poor maths to blame there) and (as with everything else) a tight spec written, maybe even trying to sort out some of the problems that exist in std::complex, though I dont quite understand what those are. Maybe should be coupled to Quaternions in 3D too... ***Performance testing*** I have done some some very limited performance tests consisting basically of running the <quan_matters/examples/particle.cpp> in VC8 both using quan::fixed_quantities and doubles and comparing the assembler output. It appears that the quan::fixed-quantity version has a couple of extra instructions (mainly when dealing with constants), though the code overall is otherwise nearly identical. Performance tests need to be done on other compilers too of course. The whole area of performance versus inbuilt types needs to be started and documented using as many compilers as possible. *** Checking of calculations for integer overflow, inf etc. *** Because Quan fixed_quantity encapsulates an inbuilt type, it would be a good idea to enable the library also to perform optional runtime checks that calculations arent overflowing or dividing by zero etc. This would make Quan into a more comprehensive suite of error checking capabilities. *** Visualisation *** Visualisation is the IMO the best way to show off Quan library. Maybe a port of yade http://yade.berlios.de/. Anyway Quan needs some sort of 3D/GUI application to show it off. Other useful items are GUI Unit widgets for users to be able to set their own units and so on. Care needs to be taken over licencing issues. *** Stability, Modularity *** At some point When the version changes to Non_zero_x_x, whatever mistakes have been made in the interface spec should be considered embedded, so that the code base for any users is stable. Before that consider the code Alpha only. This will probably mean releasing Quan in modules at least once anything gets into a finished state. IOW fixed_quantity module etc. **What platforms should Quan run on** Wherever possible, the library should be designed to allow for (say) the possibility that an int is 16 bits and so on. I don't think it costs much to do so. **Can Quan be used on large systems?*** The kind of problems Quan is designed to solve get worse in large systems. Again only theoretically currently, but the idea is that it will work well because of the error checking and code documentation features. However quite what happens in large matrices, higher level maths and so on, and so on I don't know and support for these features needs to be written. I think this is an unanswered research question frankly and should be approached with an open mind. It may transpire that such use is impractical. If that turns into a proof that inbuilt types work better then so be it. ***High Performance systems ** Often there is a high performance requirement. For example Geoffrey Irvings work http://graphics.stanford.edu/~irving/ and uJanek Kozickis work http://yade.berlios.de/. Unfortunately Quan is in a no win situation here. It is never going to beat inbuilt types, but there is an underlying requirement that Quan needs to be as good as it possibly can. Even in high performance systems the error checking ability and (hopefully) increased productivity from that may outweigh the cost (if any) in performance. Work also needs to be done on working out how Quan can be switched in for testing and switched out for release too. Work also needs to be done on Quans performance versus inbuilt types with test, results and documentation. *** Documentation Format *** Currently the docs use QuickBook. Other html documentation can be linked in, but Quickbook can produce pdf format and things get sticky if relative links are used. Ideally docs will be in QuickBook but other html formats can be used I guess. It may be desirable to write any Units and contant html into the Quickbook document in Quickbook format (or as XML). (Currently I am using Quickbook 1.1 which is monolithic, but in the boost_1.34.0 distro this should change). ** Website ** Currently the website consists just of the fixed_quantity docs. It should probably provide more general information about the project. If there is any part of the project that you are interested in helping with then please get in touch. If you have any points you would like to make, please feel fee to get in touch with me personally or post to the quan-matters mailing list., regards Andy Little

2 2

[test] --catch_system_errors=no is not working
by Felipe Magno de Almeida 24 Jul '06

24 Jul '06

Hi, I cant make --catch_system_errors=no to work at all! Not even disabling asynch-exceptions I could make it to call a debugger. My debugger configuration is fine, I tested it with naked programs and it works ok! -- Felipe Magno de Almeida

3 3

Changes to the inspect tool
by Gennaro Prota 24 Jul '06

24 Jul '06

Hopefully these are improvements over the status quo. I've added check for unnamed namespaces used in included files. The corresponding switch is '-unnamed' and the suppression tag 'boostinspect:nounnamed'. Moreover I've tightened the license check so that it now detects if the reference text correctly starts with "Distributed under the" instead of "Use, abuse and misuse is regulated by..." etc. etc. The changes are in the CVS head only. I'll leave to Rene to decide if they are worth merging into the RC_1_34_0 branch. Maybe he wants to revert the second change as it generates *a lot* of errors. On the other hand it shouldn't be difficult to setup a script, do the change automatically, and say goodbye forever to this die-hard problem. -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]

2 1

Re: [boost] ANN: POCO - C++ Portable Components
by Sohail Somani 23 Jul '06

23 Jul '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Steven Burns > Sent: Friday, July 21, 2006 9:30 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] ANN: POCO - C++ Portable Components > > Even though I have used boost libraries for a while, this was > the first time > I read about ACE and POCO. > > > > I've used Java's and C#'s libraries for years wishing > something similar > existed for C++ and POCO seems to be a step in this direction. > > > > Regarding ACE, I haven't read that much. The site kept me > jumping from page > to page and it looked kind of "academic" if you ask me. Yeah we've been looking at POCO since it was mentioned here, and it really does look very good compared to ACE. I think if you wanted more of a framework, you might go with ACE.

4 4

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

23 Jul '06

Boost Regression test failures Report time: 2006-07-23T09:16:10Z 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… 388 failures in 30 libraries algorithm/string (1) concept_check (1) conversion (1) filesystem (5) graph (5) integer (3) io (1) iostreams (33) iterator (1) lambda (2) mpl (17) numeric/conversion (4) numeric/interval (2) numeric/ublas (7) optional (2) parameter (33) pool (3) program_options (19) python (97) random (1) rational (5) serialization (42) signals (16) spirit (11) test (8) tr1 (55) typeof (9) utility (2) utility/enable_if (1) wave (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| fstream_test: sun-5.8 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 graphviz_test: msvc-8.0 msvc-8.0 vc-7_1-stlport |integer| integer_traits_test: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp |io| ios_state_unit_test: gcc-4.1.0_linux_x86_64 |iostreams| auto_close_test: sun-5.8 buffer_size_test: sun-5.8 bzip2_test: msvc-7.1 msvc-8.0 sun-5.8 code_converter_test: sun-5.8 component_access_test: sun-5.8 compose_test: borland-5_6_4 sun-5.8 counter_test: sun-5.8 example_test: vc-6_5-stlport filtering_stream_test: sun-5.8 vc-7_1-stlport finite_state_filter_test: cw-9.4 sun-5.8 flush_test: sun-5.8 gzip_test: msvc-7.1 msvc-8.0 sun-5.8 line_filter_test: sun-5.8 newline_test: sun-5.8 pipeline_test: msvc-8.0 sun-5.8 regex_filter_test: sun-5.8 restrict_test: sun-5.8 seekable_file_test: sun-5.8 seekable_filter_test: sun-5.8 stdio_filter_test: sun-5.8 symmetric_filter_test: sun-5.8 tee_test: sun-5.8 wide_stream_test: sun-5.8 zlib_test: msvc-7.1 msvc-8.0 |iterator| is_lvalue_iterator: sun-5.8 |lambda| extending_rt_traits: sun-5.8 operator_tests_simple: sun-5.8 |mpl| apply: sun-5.8 count: sun-5.8 count_if: sun-5.8 equal: sun-5.8 erase: sun-5.8 find: sun-5.8 insert: sun-5.8 insert_range: sun-5.8 lambda_args: sun-5.8 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 partition: sun-5.8 stable_partition: sun-5.8 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| det: sun-5.8 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 |optional| optional_test: sun-5.8 optional_test_ref: sun-5.8 |parameter| basics: borland-5_6_4 borland-5_8_2 sun-5.8 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 sun-5.8 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 |pool| test_pool_alloc: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp |program_options| cmdline_test: sun-5.8 cmdline_test_dll: cw-9.4 sun-5.8 options_description_test: sun-5.8 options_description_test_dll: cw-9.4 sun-5.8 parsers_test: sun-5.8 parsers_test_dll: cw-9.4 sun-5.8 positional_options_test: sun-5.8 positional_options_test_dll: cw-9.4 sun-5.8 unicode_test_dll: borland-5_8_2 cw-9.4 variable_map_test: sun-5.8 variable_map_test_dll: borland-5_8_2 cw-9.4 sun-5.8 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-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-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-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-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 qcc-3.3.5_cpp qcc-3.3.5_gpp 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-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_codecvt_null: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp test_demo_fast_archive: sun-5.8 test_demo_fast_archive_dll: sun-5.8 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_shared_ptr_132_binary_archive: sun-5.8 test_shared_ptr_132_binary_archive_dll: sun-5.8 test_shared_ptr_132_text_archive: sun-5.8 test_shared_ptr_132_text_archive_dll: sun-5.8 test_shared_ptr_132_text_warchive: sun-5.8 test_shared_ptr_132_text_warchive_dll: sun-5.8 test_shared_ptr_132_xml_archive: sun-5.8 test_shared_ptr_132_xml_archive_dll: sun-5.8 test_shared_ptr_132_xml_warchive: sun-5.8 test_shared_ptr_132_xml_warchive_dll: sun-5.8 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_utf8_codecvt: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp 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| bug_fixes: sun-5.8 bug_fixes_debug: sun-5.8 char_strings_test: sun-5.8 char_strings_test_debug: sun-5.8 epsilon_tests: sun-5.8 epsilon_tests_debug: sun-5.8 file_iterator_tests: sun-5.8 file_iterator_tests_debug: sun-5.8 if_p_as_parser_tests: sun-5.8 mix_and_match_trees: sun-5.8 while_p_as_parser_tests: sun-5.8 |test| basic_cstring_test: sun-5.8 boost_check_equal_str: sun-5.8 foreach_test: sun-5.8 ifstream_line_iterator_test: sun-5.8 output_test_stream_test: sun-5.8 parameterized_test_test: vc-6_5 vc-6_5-stlport token_iterator_test: sun-5.8 |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| addressof_test: sun-5.8 operators_test: gcc-3.4.5_linux_x86_64 |utility/enable_if| lazy: sun-5.8 |wave| test_re2c_lexer: sun-5.8

1 0

using lu_substitute
by arun.s 23 Jul '06

23 Jul '06

Hello, Iam trying to use lu_factorize and lu_solve for solving a linear system Ax= B where matrix A has entries of type double and vector B entries of type point ( a simple class wrapping double [3] ) but I get compiler errors in in_place_solve ( all of the overrides have this problem) BOOST_UBLAS_CHECK (e1 () (n, n) != value_type (0), singular ()); apparently this expects that "double" and "point" are comparable using != operator. The problems disappear if I change the line to BOOST_UBLAS_CHECK (e1 () (n, n) != E1::value_type (0), singular ()); but I leave it for the experts to give me the correct solution. PS : I tried to switch to MTL after this, but it too, had the same problem. Thanks, Arun

1 0

Naming integer, real and either template types
by Paul A Bristow 23 Jul '06

23 Jul '06

I am writing template math functions. Some can take integral types (only) Some can take real (both built-in floating-point - float, double.. AND User Defined real types) And some can take either integral OR real. Real : Floating-point types Integer : Integral types Arithmetic : Either Integral OR Floating-point types Arithmetic is a bit long - other ideas? So to write a function something like template <class RealType> RealType students_t(ArithmeticType degrees_of_freedom, RealType t) { ... } Using just T is not an option because there are three (at least) possibles. What names should I use for the types? RealType, real_type, RealT, or RT, or ??? IntType, int_type, IntT, IT, or ??? ArithmeticType, arithmetic_type, ArithType, arith_type, AT ??? Suggestions for names please. Rationales? Prior art? Precedents? Standards? Thanks Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow(a)hetp.u-net.com

3 3

Re: [boost] Please don't define a fake "operator<"justfor orderedcontainers
by Martin Bonner 22 Jul '06

22 Jul '06

----Original Message---- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: 11 July 2006 12:21 To: boost(a)lists.boost.org Subject: Re: [boost] Please don't define a fake "operator<"justfor orderedcontainers > Martin Bonner wrote: >> ----Original Message---- >> From: boost-bounces(a)lists.boost.org >> [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov >> >>> Daryle Walker wrote: >>> >>>> [1] If you make a fake order for "std::complex<>", would you >>>> compare real components then imaginary components, or would you use >>>> magnitude then angle? >>> >>> Real, then imaginary. Compare with: >> >> Interesting. I would have chosen magnitude and then angle. Why >> components. > > There are two reasons for that. First, composite types use > lexicographical ordering by default, and std::complex is > (de facto) a (real, imag) pair. > Second, the magnitude/angle ordering has the property that if you > have three numbers a, b, c, where a and b are very close to one > another but not to c, it is possible to have a < c and c < b. That is true for your comparison too. Consider a=-1, b=+1, c=10000i. >>> "If you make a FAKE order for std::string, would you compare left to >>> right or right to left?" >> >> I don't think that is a legitimate comparison. In my world view, >> strings have a natural order but complex numbers don't. > > Possibly. So you define "fake" as "unnatural", and define "natural" as > "feels natural to me". > This approach can work but it's a bit subjective, isn't it? Yes. > Consider the progression: > > complex<double> > struct { double x, double y; } > pair<double, double> > tuple<double, double> > vector<double> > vector<char> > string > > If we take the "feel" of operator< out of the equation, where should > we draw the line, and based on what? complex<double> should not have an operator <() because it models a mathematical concept (complex number) for which "less than" does not make sense. struct, pair, and tuple should not have an operator < because they are essentially unordered collections of data (I know that the elements of pair are called first and second, but it seems to me that they are essentially arbitrary labels). vector is an interesting case. Some vectors are used to store lists of things (in which case ordering makes sense), but others are used to model things like mathematical vectors (in which case we are back to the complex case, and < does not make sense). string definitely should have operator <() because it models the real world concept (string of letters and other characters) for which "less than" definitely makes sense. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

6 13

[integer] endian-0.6 posted w/ names changed
by Beman Dawes 22 Jul '06

22 Jul '06

endian-0.6.zip has been posted in the integer directory of the file vault at http://boost-consulting.com/vault/ The only important change is that I finally came around on the names, and changed from byte-count oriented names to bit-count oriented names. What finally swayed me was some code I wrote that mixed endian typedefs with cstdint typedefs. It was jarring to see both naming conventions intermixed in the same source files. Yet this will be the most common use pattern. So the change has been made. --Beman

1 0