July 2006 - Boost - lists.preview.boost.org

[mpl] Metafunction terminology - revival?
by David Bergman 28 Jul '06

28 Jul '06

Ok, I don't know what happened to the old discussion about naming of stuff that can be safely applied by mpl::apply. We have the following constructs: 1. "metafunctions," which are templates classes with a type identifier called 'type', 2. "metafunction classes," which are classes with a nested template class called 'apply', which is a "metafunction" in its own right, and 3. "lambda expression." Two of them - #2 and #3 - share a quite important trait: they can be passed as the first argument to mpl::apply. I suggest that we call anything applicable via mpl::apply a "metafunctor." And have "metafunctoid" denote that category extended with #1 - ordinary metafunctions - above. It is a bit boring not to be able to use a common name for these constructs, especially when trying to tech others about metaprogramming techniques in C++. And I do not see such common names in the MPL documentation (or book.) /David

5 8

Re: [boost] Exception Visitor
by Sohail Somani 28 Jul '06

28 Jul '06

I just don't see the point, except as an academic exercise > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeremy Day > Sent: Tuesday, July 18, 2006 10:32 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Exception Visitor > > I don't think that I can get rid of the catch block entirely, > but I can make > it so that you always use catch(...). The catcher function > redirects the > exception handling to the class that you provide. > > Jeremy > > On 7/18/06, Sohail Somani <s.somani(a)fincad.com> wrote: > > > > Or how to implement try..catch? > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

9 28

[Boost-bugs] [ boost-Support Requests-1530168 ] Bjam build should support attachment of individual build ids
by SourceForge.net 28 Jul '06

28 Jul '06

Support Requests item #1530168, was opened at 2006-07-28 06:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1530168&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: Daniel Krügler (daniel_kruegler) Assigned to: Nobody/Anonymous (nobody) Summary: Bjam build should support attachment of individual build ids Initial Comment: The Boost library has very high reputation due to its code quality and is used in many companies and organizations as part of their own production code. Bug fixes are usually rarely necessary, but due (naturally understandable) longer release cycles, they tend to accumulate slightly, which raises the propability that individual organizations decide that they would like to use a non-official release version of boost: - They use selected parts from the current development code. - They use proposed fixes which were the result of newsgroup discussions. Due to these practices there exist need to extend the current naming scheme of boost libraries to allow the attachment of individual build id's to the current lib names, e.g. instead of the current example from http://boost.org/more/getting_started.html#Build_Install: libboost_date_time-gcc-mt-d-1_31.a I propose to extend the bjam action table with the option: -sBUILD_ID=string If this option is not used, the current naming scheme applies as usual, but if the proposed option is used, e.g. with -sBUILD_ID=M20060727-vgf3 the above output file is named to libboost_date_time-gcc-mt-d-1_31-M20060727-vgf3.a The very advantage of this proposal are: - Popular build id naming schemes tend to point themselves out of the regular version pattern and allow better discrimination from official boost release version. Build id do have a well-known tradition in many popular software products. - The proposal is non-intrusive and allows tagging boost output according to company-specific naming schemes. Users don't need to manually "hack" the current bjam input file to enforce such naming scheme. Users not interested in this scheme will not be influenced by this extension. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1530168&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

Re: [boost] error in boost/config/platform/hpux.hpp (thread support)
by Oliver.Kowalke＠qimonda.com 28 Jul '06

28 Jul '06

Julien Delacroix wrote: > Maybe it will be necessary to check aCC version and set > BOOST_DISABLE_THREADS for old aCC version that do not have thread > suport... Boost did not compile under HP/UX 11.11 (PA-RISC) with aCC because only the old aCC version 3.x is shipped on PA-RISC systems. aCC 3.x is far away from the C++ standard - use instead gcc. regards, Oliver

1 0

pimpl pointer revisited
by Aljaz Noe 27 Jul '06

27 Jul '06

Hi! Recently there was a proposal to add a class template that simplifies the implementation of a PIMPL idiom to Boost. Unfortunately I missed the review deadline so I could not submit a proper review. But I do have some experience with PIMPL class template that I would like to share with you. I wrote similar class template a couple of years ago (see attached file). The basic idea is the same as in a proposed PIMPL class. I call it ImplWrapper, because it is used to wrap class implementation details. Besides automating the standard PIMPL functionality, it also addresses the following issues: 1. The Impl object can be allocated in a buffer that is provided by ImplWrapper class. The reason for this is to avoid unnecessary allocation of small objects on the heap and to increase performance. In fact, I believe that with proper compiler optimizations, there should be no difference between using ImplWrapper class and storing data members in class directly (additional pointer indirection normally associated with a PIMPL idiom is eliminated). The drawback is that the size of the Impl object must be known (guessed) in advance. Sometimes this is not possible, so there is also alternative implementation that allocates Impl object on the heap. 2. Arbitrary parameters can be passed to Impl constructor by wrapping them in a temporary struct. This struct Par, is forward declared within ImplWrapper class and can be specialized for each type of Impl class. There is no need for policies or other design complications. 3. Simplicity. The overall design seems simple, yet functional. But I do admit that this opinion may by biased. ;-) Since the above issues were not resolved within the proposed PIMPL class (I only quickly glanced over the implementation and a PIMPL thread in this list at the end of May, so I might have skipped something), I decided to post my implementation here. I believe that PIMPL idiom is so often used in C++, that it should have some support in Boost (maybe even in future versions of standard C++ library). Hopefully this post will contribute to that goal. Any comments are greatly appreciated. Regards, Aljaz

2 2

Re: [boost] Exception Visitor
by Sohail Somani 27 Jul '06

27 Jul '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Alexander Nasonov > > 2. catch(...) catches too many things on some compilers. I > know only one (very popular) compiler that also catches > system exceptions (aka SEH). Though, I don't remember how it > rethrows those exceptions. If you are talking about msvc, I think C++ exceptions are implemented on top of SEH. Sohail

1 0

[Boost-bugs] [ boost-Bugs-1529988 ] compile warning in token-functions.hpp
by SourceForge.net 27 Jul '06

27 Jul '06

Bugs item #1529988, was opened at 2006-07-27 14:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1529988&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: James W. Walker (jwwalker) Assigned to: Nobody/Anonymous (nobody) Summary: compile warning in token-functions.hpp Initial Comment: When compiling with -Wall in gcc 4, token-functions.hpp gives a warning about escaped_list_error. The warning is "declaration of 'what' shadows a member of 'this'". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1529988&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

Concept traits
by Chad Parry 27 Jul '06

27 Jul '06

What is the fate of the operator_concept_traits library that Terje Slettebø introduced on the Boost mailing list in 2004? A "has_plus_op" metafunction would be immensely useful, if only as a foundation for other generic code. Is the source code in a vault somewhere? -- chad

1 0

[Random] Non-Deterministic Generator Not Included in Library
by Jill Stellman 27 Jul '06

27 Jul '06

I am using the non-deterministic random number generator from the Boost.Random library. I included nondet_random.hpp in my source code, but it does not contain the implementation. I attempted to use Bjam to build the Boost.Random library, but it did not build. I used the following command: bjam -sTOOLS=gcc --prefix=/usr --with-boost_random --without-python install which resulted in (only) the following output Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (and if you don't know what ICU is then you probably don't need it). ...found 6900 targets... and (obviously?) did not build the library for boost_random. I am using boost 1.33.1-4, bjam 3.1.11-1, g++ 4.1.2, Debian 64bit unstable. I eventually just built a library manually by making random_device.o from random_device.cpp and using ar, which seems to work. Unfortunately, this process will not work for me as a permanent solution. On searching the mailing list archives, I found the following thread: http://thread.gmane.org/gmane.comp.lib.boost.devel/106229/focus=106228 which unfortunately has no further responses. Does anyone know if anything has been done to address this issue or if there is some reason why the non-deterministic random number generator should not be used? Thanks, Jill

1 0

Computational Geometry Library
by Arash Partow 27 Jul '06

27 Jul '06

Hi all, I was wondering if there was anyone working on / managing the BOOST geometry libraries? I can't seem to see if anyone has already put their hand up or not. I've noticed that it was a contender for the 2006 SoC, and that there are a couple of code samples in the BOOST vault. In any case I'm planning on making a preliminary library submission sometime soon, I've been contact with one of the other code submitters, I just want to make sure there isn't an effort already underway, I've searched the mailing list, and have found anything of interest. If anyone has any information about this topic, please feel free to comment as it would help a great deal. As for a preliminary library design I propose the following: * primitive geometric structures 2D/3D only (point,line,segment,triangle...) * operations between primitives (intersection, distance, inclusion...) * higher level algorithms in a structured fashion similar to BGL: * hulls, rotating caliper * triangulation (point sets, polygons) * boolean operations over polygons Note: algorithms will be named based on method then algorithm type for example convex hull variations would be: 1. graham_scan_convex_hull(it_begin,it_end,out_it) 2. jarvis_march_convex_hull(it_begin,it_end,out_it) 3. gift_wrapping_convex_hull(it_begin,it_end,out_it) 4. quick_convex_hull(it_begin,it_end,out_it) * precision related issues to be dealt with mainly by user specified floating point type, and partially at the algorithm level * keep code bloat and over-engineering to a minimum. ie: in cgal to determine whether or not 2 segments intersect you need roughly 35 lines of source code. Should be something like the following: boost::geometry { segment<T,D> seg1 = make_segment(....); segment<T,D> seg2 = make_segment(....); . . if (intersect(seg1,seg2)) ...; else ...; } Arash Partow ________________________________________________________ Be one who knows what they don't know, Instead of being one who knows not what they don't know, Thinking they know everything about all things. http://www.partow.net

4 3

[system] system-0.2 request for comments
by Beman Dawes 27 Jul '06

27 Jul '06

system-0.2.zip has been posted in the file vault. See the "system" directory at http://boost-consulting.com/vault/ This is a major upgrade, reflecting comments and suggestions from many Boosters, but in particular Chris Kohlhoff and Peter Dimov. Important changes include: * Class error_code now supports additional categories of errors, such as those that may bubble up from asio. I'll be watching for for a response from Chris to make sure this meets asio's needs. * Refactoring into two headers, boost/system/error_code.hpp and boost/system/system_error.hpp, in line with the fine header granularity normal in Boost libraries. Docs refactored accordingly. * Addition of a header boost/identifier.hpp. For years I've used a similar class to provide the type safety and freedom from unwanted conversions that is missing when a simple int is used for an identifier. This is logically separate from the system stuff, but for convenience is included in the system package since error_code.hpp uses it. * More complete docs. * Jamfiles provided. * More extensive testing, with all tests passing for late-model GCC, CodeWarrior, Intel, and Microsoft compilers on Windows, and GCC on the Mac. Not tested yet on Linux. Comments welcome! --Beman

8 22

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

27 Jul '06

Boost Regression test failures Report time: 2006-07-27T08:00:00Z 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… 277 failures in 25 libraries algorithm/string (1) concept_check (1) filesystem (4) graph (5) io (1) iostreams (10) mpl (5) multi_index (1) numeric/conversion (4) numeric/interval (1) numeric/ublas (7) parameter (20) program_options (9) python (90) random (1) rational (4) regex (4) serialization (27) signals (16) spirit (1) test (2) tr1 (51) typeof (9) utility (1) xpressive (2) |algorithm/string| regex: borland-5_6_4 |concept_check| class_concept_check_test: vc-7_1-stlport |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 graphviz_test: 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-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-8.0 zlib_test: msvc-7.1 msvc-8.0 |mpl| multiset: gcc-4.0.3_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 vector_c: sun-5.8 |multi_index| test_projection: gcc-4.0.3_linux |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| duplicates: borland-5_6_4 borland-5_8_2 maybe: vc-6_5 vc-6_5-stlport vc-7_0 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_8_2 vc-6_5-stlport singular: 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_4_4_tru64 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 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_4_4_tru64 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 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_4_4_tru64 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 sun-5.8 pointer_type_id_test: gcc-3_4_4_tru64 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 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_4_4_tru64 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 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 vc-6_5 vc-6_5-stlport vc-7_0 |regex| regex_regress: vc-6_5 vc-6_5-stlport regex_regress_dll: vc-6_5 vc-6_5-stlport |serialization| test_class_info_load_text_warchive: vc-6_5 test_demo_xml: msvc-8.0 test_list_binary_archive_dll: 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 gcc-3.3.6_linux 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 |test| parameterized_test_test: vc-6_5 vc-6_5-stlport |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_x86_64 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_x86_64 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 |xpressive| test2: msvc-8.0 test9: gcc-3.3.6_linux

2 1

error in boost/config/platform/hpux.hpp (thread support)
by Julien Delacroix 27 Jul '06

27 Jul '06

Here is the code that handle thread support in boost/config/platform/hpux.hpp : #if defined(__GNUC__) # if (__GNUC__ < 3) || ((__GNUC__ == 3) && (__GNUC_MINOR__ < 3)) // GNU C on HP-UX does not support threads (checked up to gcc 3.3) # define BOOST_DISABLE_THREADS # elif !defined(BOOST_DISABLE_THREADS) // threads supported from gcc-3.3 onwards: # define BOOST_HAS_THREADS # define BOOST_HAS_PTHREADS # endif #endif This code does not set BOOST_HAS_THREADS and BOOST_HAS_PTHREADS when compiling with aCC on HP-UX. This cause the boost::shared_ptr to be unsafe in a multithreaded environment . We fixed this problem by adding the following lines in user.hpp : // Enable threading support with aCC !! #ifdef _AMD_THREADS_ # ifdef _AMD_UNIX_HPUX_ # define BOOST_HAS_THREADS # define BOOST_HAS_PTHREADS # endif #endif But I suggest that in future release you use the following code in boost/config/platform/hpux.hpp #if defined(__GNUC__) # if (__GNUC__ < 3) || ((__GNUC__ == 3) && (__GNUC_MINOR__ < 3)) // GNU C on HP-UX does not support threads (checked up to gcc 3.3) # define BOOST_DISABLE_THREADS # endif #endif #if !defined(BOOST_DISABLE_THREADS) // threads supported # define BOOST_HAS_THREADS # define BOOST_HAS_PTHREADS # endif Maybe it will be necessary to check aCC version and set BOOST_DISABLE_THREADS for old aCC version that do not have thread suport... Regards Julien

2 1

[mpl] BOOST_MPL_AUX_LAMBDA_SUPPORT and non-type template parms
by JOAQUIN LOPEZ MU?Z 27 Jul '06

27 Jul '06

Suppose we've got the following: template<typename T, int N> struct foo { typedef ... type; }; and we want to add MPL lambda support for broken compilers. Should we have #1 or #2? //1 template<typename T, int N> struct foo { BOOST_MPL_AUX_LAMBDA_SUPPORT(1,foo,(T)) typedef ... type; }; //2 template<typename T, int N> struct foo { BOOST_MPL_AUX_LAMBDA_SUPPORT(2,foo,(T,N)) typedef ... type; }; The docs on BOOST_MPL_AUX_LAMBDA_SUPPORT seem not to take into account class templates where some params are non-type. Maybe the macro does not work for them? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[python]enum_ docstring?
by Colin Grealy 27 Jul '06

27 Jul '06

Is there any particular reason that enum_ doesn't accept a docstring? Was it a conciouse design decision, a technical issue or merely an oversight? ------------------------------------------------------------------ Without question, the greatest invention in the history of mankind is beer. Oh, I grant you that the wheel is a fine invention, but the wheel does not go nearly as well with pizza. - Dave Barry Colin Grealy cgrealy at mailREMOVETHIScan dot com +64 21 527590

1 0

boost compiles differently, if ACE header is included first
by Harling, Torsten 26 Jul '06

26 Jul '06

Hello, I have a little problem regarding boost and ACE cooperation. ACE is an C++ class library, providing many functions for platform independency. I have also reported this to the debian team, and will also try to contact the ACE developers: Package: libboost-dev Version: 1.32.0-6 Package: libace-dev Version: 5.4.2.1.0-4 Consider the following program boostfirst.cpp: ------------------------------------------------------------ #include <boost/shared_ptr.hpp> #include <ace/OS.h> #include <iostream> using namespace std; int main (int argc, char **argv) { cout << "sizeof (boost::detail::sp_counted_base) == " << sizeof (boost::detail::sp_counted_base) << endl; } ------------------------------------------------------------ Compile and run with: $ g++ boostfirst.cpp -o boostfirst -lstd $ ./boostfirst sizeof (boost::detail::sp_counted_base) == 12 Now try including the ace header first (only the order of the include files is changed): ------------------------------------------------------------ #include <ace/OS.h> #include <boost/shared_ptr.hpp> #include <iostream> using namespace std; int main (int argc, char **argv) { cout << "sizeof (boost::detail::sp_counted_base) == " << sizeof (boost::detail::sp_counted_base) << endl; } ------------------------------------------------------------ The output of the second program is: sizeof (boost::detail::sp_counted_base) == 36 A great difference. The reason for this is, that the #include <ace/OS.h> somehow defines _REENTRANT, which triggers the boost library to include a mutex in sp_counted_base. I think, the order of the includes should not matter. Therefore, either '#include <ace/OS.h>' should not define _REENTRANT, or the boost headers should ignore it. I found out, that adding the -pthread option to the g++ command also avoids this bug. Im using Debian sarge 3.1, g++ 3.3.5-3, libc6 2.3.2.ds1-22sarge3 and libace-dev 5.4.2.1.0-4. Regards, Torsten

6 5

Re: [boost] boost::bind dilemma
by Steven Watanabe 26 Jul '06

26 Jul '06

AMDG >> OK, this compiles and works, but the fourth parameter to the outer bind, _1, >> must be copied each time an Insert takes place, from my understanding of how >> bind works. > Actually, boost::bind::operator() takes it's arguments by reference In Christ, Steven Watanabe

3 3

[Test] execution_exception not derived from std::exception
by Sean Huang 26 Jul '06

26 Jul '06

boost::test::execution_exception is not derived from std::exception and this makes my boost::test::*exceptions unaware code not able to log any meaningful error messages. Is there any reason why it is not derived from std::exception? Thanks, Sean

3 7

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

26 Jul '06

Boost Regression test failures Report time: 2006-07-26T08:38:52Z 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… 284 failures in 23 libraries algorithm/string (1) concept_check (1) filesystem (4) graph (5) io (1) iostreams (10) mpl (6) numeric/conversion (4) numeric/interval (1) numeric/ublas (7) parameter (20) program_options (9) python (100) random (1) rational (4) regex (4) serialization (24) signals (16) spirit (1) test (2) tr1 (53) typeof (9) utility (1) |algorithm/string| regex: borland-5_6_4 |concept_check| class_concept_check_test: vc-7_1-stlport |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 graphviz_test: 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-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-8.0 zlib_test: msvc-7.1 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| duplicates: borland-5_6_4 borland-5_8_2 maybe: vc-6_5 vc-6_5-stlport vc-7_0 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_8_2 vc-6_5-stlport singular: 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 vc-6_5 vc-6_5-stlport vc-7_0 |regex| regex_regress: vc-6_5 vc-6_5-stlport regex_regress_dll: vc-6_5 vc-6_5-stlport |serialization| test_class_info_load_text_warchive: vc-6_5 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 |test| parameterized_test_test: vc-6_5 vc-6_5-stlport |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 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 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

Status of accepted libraries
by Jody Hagins 26 Jul '06

26 Jul '06

I asked this a while back, but can not find a response... Is there a place on the website that we can check on the status of accepted libraries? Specifically, it would be nice to know in which release each library is planned to be introduced... Thanks!

2 1

[multi_index] Getting an iterator from a pointer
by Bruno Martínez 26 Jul '06

26 Jul '06

Hi. There was a discussion long time ago[*] about how to convert a pointer to an object contained in a multi index set to the corresponding iterator. Has there been progress in this area? [*] http://thread.gmane.org/gmane.comp.lib.boost.devel/136418/focus=136972 Regards, Bruno

2 2

none.hpp
by Joe Gottman 26 Jul '06

26 Jul '06

In order to avoid having an unnamed namespace inside a header file, none.hpp has been rewritten as namespace boost { none_t const none = ((none_t)0) ; } // namespace But if two source files contain none.hpp won't this violate the one-definition rule? What's wrong with defining none_t and none as follows: namespace boost { enum none_t {none = 0}; } This allows us to have a unique value boost::none of type boost::none_t that can be included in any number of source files without violating the ODR. Joe Gottman

6 12

[inspection] License+copyrights in RC branch (was: [mpl] Metafunction terminology - revival?)
by Rene Rivera 26 Jul '06

26 Jul '06

Gennaro Prota wrote: > On Mon, 24 Jul 2006 13:06:03 -0500, Rene Rivera > >> >While your in there changing MPL docs, could you do us the favor of >> >adding some of the missing copyright+license information. MPL is *1* in >> >the number of those issues. > > Rene, next time we should remember to run the inspect tool (and fix > its discoveries :-)) before branching for release, so that we don't > have to duplicate all corrections on head and branch. Historically it hasn't made a difference when we run the inspect tool. People mostly ignored it and hence why we have an accumulation problems now. Now perhaps that it's in the form of a constant nagging email instead of a web page people will pay attention (cross-fingers). As for the amount of work I don't think libraries have diverged that much between HEAD and RC so it's likely not that much work since one only has to merge to the RC branch. > Or maybe the > inspect tool should run once a week or so, in general. Not sure about the schedule, but definitely it will running all the time from now on. I haven't enabled runs of it in HEAD yet as I expect that would generate a somewhat larger set of issues. But perhaps we could start such runs on HEAD on a weekly schedule? (Did a test run, and the *LC* email on HEAD would exceed the 75K limit. Only by a hair though.) > PS: maybe we want to highlight this in a separate thread? Yep :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

2 5

Library-Centric Software Design 2006, Second Call for Papers
by Jeremy Graham Siek 26 Jul '06

26 Jul '06

LIBRARY-CENTRIC SOFTWARE DESIGN - LCSD'06 http://lcsd.cs.tamu.edu/2006 Workshop, on October 22nd, 2006 at the OOPSLA'06 conference in Portland, Oregon, October 22-26, 2006 CALL FOR PAPERS Libraries are central to all major scientific, engineering, and business areas, yet the design, implementation, and use of libraries are underdeveloped arts. This workshop is one of the first steps in the process of placing all aspects of libraries on a sound technical and scientific basis through research into fundamental issues and documentation of best practices. A software library is an organized collection of code with associated tools supporting programming in general or in specific domains, usually united by a specified set of principles and conventions. Most libraries are aimed for use by several people and in different environments. The areas of software library research include * Design and implementation of libraries * Program and system design based on libraries * Libraries supporting specific application domains, such as biology or banking * Evolution, refactoring, and maintenance of libraries * Empirical studies of library use * Performance of libraries, including benchmarking and library-based optimizations * Design of language facilities and tools in support of library definition and use * Validation, debugging, and testing of libraries * Extensibility, parameterization, and customization * Distribution of libraries * Specification of libraries and their semantics * Usability for library users and developers * Assessing quality of libraries * Documentation and teaching of libraries * Creating and supporting communities of library users * Using several libraries in combination We invite the submission of extended abstracts on software library research, including, but not limited to, the above list of topics. The extended abstracts should address issues important to libraries as a field, i.e., describe ideas or techniques that can be reused for libraries across problem domains and/or languages; they should refrain from merely describing a particular library, no matter how novel the choice of domain. As an additional criterion, the extended abstracts are reviewed against suitability for a journal publication of the corresponding full paper. For uniformity, authors should use the latest ACM SIGS conference style file (option 1) at http://www.acm.org/sigs/pubs/proceed/template.html. Submissions should be limited to 10 pages in this style. Accepted extended abstracts will be posted on the workshop's Web site prior to the workshop, and collected in a proceedings published as a Rensselaer Polytechnic Institute tech report. Authors of selected papers will be invited to submit a full paper for a special issue of a journal, to be announced later. IMPORTANT DATES Aug 11 Submission of extended abstracts Sep 12 Notification of acceptance Oct 10 Submission of final versions of the extended abstracts Oct 15 Final version posted on Workshop web pages Oct 22 or 23 Workshop SUBMISSION PROCEDURE For details of the electronic submission procedure, see the workshop's Web site, http://lcsd.cs.tamu.edu/2006. ORGANIZERS * Josh Bloch, Google Inc. * David Musser, Rensselaer Polytechnic Institute * Jaakko Jarvi, Texas A&M University * Sibylle Schupp, Chalmers University of Technology * Jeremy Siek, Rice University PROGRAM COMMITTEE * Dave Abrahams, Boost Consulting * Olav Beckman, Imperial College London * Herv=C8 Br=88nnimann, Polytechnic University * Cristina Gacek, University of Newcastle upon Tyne * Douglas Gregor, Indiana University * Doug Lea, State University of New York at Oswego * Andrew Lumsdaine, Indiana University * Erik Meijer, Microsoft Research * Tim Peierls, Prior Artisans LLC * Doug Schmidt, Vanderbilt University * Anthony Simons, University of Sheffield * Bjarne Stroustrup, Texas A&M University and AT&T Labs * Todd Veldhuizen, University of Waterloo In addition, the organizers will serve as program committee members, with Jaakko Jarvi and Josh Bloch as program co-chairs. Primarily, the email address lcsd06(a)cs.tamu.edu should be used for questions addressed to the organizers. KEYNOTE ADDRESS There will be an invited talk by Sean Parent, Adobe Inc. WORKSHOP GOALS AND ACTIVITIES The workshop is a scientific forum for presenting original research in the design, implementation, and evaluation of software libraries. Other major activities include the identification of open questions specific to library research and the discussion of a strategic plan for establishing library research as a field. The outcome of the workshop is a combination of research contributions and specific next steps for improving the infrastructure for library research. Participants are expected to read the accepted submissions beforehand. The technical presentations, although based on the accepted papers, should not provide mere summaries of the papers. Instead, authors are encouraged to use their presentation slots (20 + 10 mins) to bring up topics for discussion. The technical presentations are mixed with scientific and organizational discussions. The discussions aim at furthering the topics of the presentations, thus their agenda will be publicly discussed among the participants and then posted on the website of the workshop. All participants are expected to come prepared with their tentative answers or thoughts. The full-day workshop starts with a keynote talk for the stimulation of discussion and concludes with a plenary discussion that decides the specific next steps for improving the infrastructure for library research. FOR MORE INFORMATION AND UPDATES please visit the workshop's Web site, http://lcsd.cs.tamu.edu/2006

1 0

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

26 Jul '06

----- Mensaje original ----- De: David Bergman <David.Bergman(a)bergmangupta.com> Fecha: Lunes, Julio 24, 2006 7:33 pm Asunto: [boost] [mpl] Metafunction terminology - revival? > Ok, I don't know what happened to the old discussion about > naming of stuff that can be safely applied by mpl::apply. > > We have the following constructs: > > 1. "metafunctions," which are templates classes with a type > identifier called 'type', > > 2. "metafunction classes," which are classes with a nested > template class called 'apply', which is a "metafunction" in > its own right, and > > 3. "lambda expression." > > Two of them - #2 and #3 - share a quite important trait: they can > be passed as the first argument to mpl::apply. > > I suggest that we call anything applicable via mpl::apply a > "metafunctor."And have "metafunctoid" denote that category > extended with #1 - ordinary > metafunctions - above. > > It is a bit boring not to be able to use a common name for these > constructs,especially when trying to tech others about > metaprogramming techniques in C++. And I do not see such common > names in the MPL documentation (or book.) > Hello David, Please correct if I'm wrong, but I'd say the official definition for a MPL lambda expression: http://boost.org/libs/mpl/doc/refmanual/lambda-expression.html actually encompasses both metafunction classes and placeholder expressions ("proper" lambda expressions, if you wish), so "lambda expression" is the common name you're after. Am I missing something? (I've got the hunch I am, actually.) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 10