- Boost - lists.boost.org

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 val salamakha > > Look at Chapter 5 "The ACE Service Configurator Framework" in > "C++ Network Programming" v2 of D. Schmidt . The chapter is > about the subject of your discussion and explains how it works. I have yet to understand why I need to buy a textbook to use ACE. Tthe website is not that good. Not nearly as good as boost.

3 2

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