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

[inspection] Unnamed namespaces in include files [was: Boost inspection notifications (RC_1_34_0)]
by Gennaro Prota 26 Jul '06

26 Jul '06

On Tue, 25 Jul 2006 16:02:46 -0500, "Hartmut Kaiser" <hartmut.kaiser(a)gmail.com> wrote: > >Rene Rivera wrote: > >> |wave| >> boost/wave/cpplexer/validate_universal_char.hpp: >> *U* unnamed namespace at line 39 >> boost/wave/util/cpp_iterator.hpp: >> *U* unnamed namespace at line 1253 >> *U* unnamed namespace at line 1654 >> *U* unnamed namespace at line 414 >> *U* unnamed namespace at line 799 > >This puzzles me a bit because I thought, that unnamed namespaces in headers >are problematic only if these are in the global namespace. The unnamed >namespaces above are inside the boost::wave namespace, I can't see any harm >in that. But what is the benefit? I think that's the key question. If they don't have any they are just misleading. I'd say there are very few exceptions to this (in truth the only one which comes to mind is the nifty counter idiom). -- [ Gennaro Prota, C++ developer for hire ]

2 3

[bgl] Bug in depth_first_search (and therefore topological_sort...)
by Loïc Joly 25 Jul '06

25 Jul '06

Hello, There is a bug in the boost graph library in depth_first_search. When we look at the implementation, we can see in file boost/graph/depth_first_search.hpp): detail::dfs_dispatch<C>::apply (g, choose_param(get_param(params, graph_visitor), make_dfs_visitor(null_visitor())), choose_param(get_param(params, root_vertex_t()), *vertices(g).first), params, get_param(params, vertex_color) ); This code makes the assumption the the graph is non-empty, since it calls *vertices(g).first. For empty graphs, this call fails. Best regards, -- Loïc

5 9

Re: [boost] [Test] BOOST_*COLLECTIONS
by Sohail Somani 25 Jul '06

25 Jul '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Philippe Vaucher > Sent: Tuesday, July 25, 2006 10:23 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] [Test] BOOST_*COLLECTIONS > > > I was even returning ostream by value... /me leaves C++ > alone for a while > > If you read me correctly you'd have read "You'd return an > ostream& too." ;) IF I had. :)

1 0

Re: [boost] [Test] BOOST_*COLLECTIONS
by Sohail Somani 25 Jul '06

25 Jul '06

I was even returning ostream by value... /me leaves C++ alone for a while > -----Original Message----- > From: Sohail Somani > Sent: Tuesday, July 25, 2006 10:17 AM > To: 'boost(a)lists.boost.org' > Subject: RE: [boost] [Test] BOOST_*COLLECTIONS > > AHHHHH. Brain fart. Thanks. > > > -----Original Message----- > > From: boost-bounces(a)lists.boost.org > > [mailto:boost-bounces@lists.boost.org] On Behalf Of Philippe Vaucher > > Sent: Tuesday, July 25, 2006 10:07 AM > > To: boost(a)lists.boost.org > > Subject: Re: [boost] [Test] BOOST_*COLLECTIONS > > > > > > > > template<typename T,size_t N> > > > std::ostream operator<<(const std::ostream & os, const > > boost::array<T,N> & > > > arr) > > > > > > > The ostream can't be const, as you write to it. > > You'd return an ostream& too. > > > > Philippe > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > >

2 1

Re: [boost] [Test] BOOST_*COLLECTIONS
by Sohail Somani 25 Jul '06

25 Jul '06

AHHHHH. Brain fart. Thanks. > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Philippe Vaucher > Sent: Tuesday, July 25, 2006 10:07 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] [Test] BOOST_*COLLECTIONS > > > > > template<typename T,size_t N> > > std::ostream operator<<(const std::ostream & os, const > boost::array<T,N> & > > arr) > > > > The ostream can't be const, as you write to it. > You'd return an ostream& too. > > Philippe > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

[Test] BOOST_*COLLECTIONS
by Sohail Somani 25 Jul '06

25 Jul '06

Hi, With the following test case: #include <boost/array.hpp> template<typename T,size_t N> std::ostream operator<<(const std::ostream & os, const boost::array<T,N> & arr) { os << "[ "; for(size_t i = 0 ; i < N-1; ++i) { os << arr[i] << ", "; } os << arr[N-1] << " ]"; return os; } BOOST_AUTO_UNIT_TEST ( test_boost_test_array ) { boost::array<double,3> arr1[] = { {{1,0,0}}, {{1,2,2}} }; boost::array<double,3> arr2[] = { {{1,0,0}}, {{1,2,2}} }; BOOST_REQUIRE_EQUAL_COLLECTIONS(arr1,arr1+2, arr2,arr2+2); } I'm getting odd compile errors at this line: res.message() << "\nMismatch in a position " << pos << ": " << *left_begin << " != " << *right_begin; gcc.compile.c++ bjam-build/gcc/release/unit_tests/data_utils.o external/boost/include/boost/test/utils/wrap_stringstream.hpp: In function âboost::basic_wrap_stringstream<CharT>& boost::operator<<(boost::basic_wrap_stringstream<CharT>&, const T&) [with CharT = char, T = boost::array<double, 3u>]â: external/boost/include/boost/test/test_tools.hpp:495: instantiated from âboost::test_tools::predicate_result boost::test_tools::tt_detail::equal_coll_impl(Left, Left, Right, Right) [with Left = boost::array<double, 3u>*, Right = boost::array<double, 3u>*]â unit_tests/data_utils.cpp:62: instantiated from here external/boost/include/boost/test/utils/wrap_stringstream.hpp:66: error: no match for âoperator<<â in â(+ targ)->boost::basic_wrap_stringstream<CharT>::stream [with CharT = char]() << tâ What am I missing here? Sorry for the long email! TIA, Sohail

2 1

forgot a few "::type" in my previous post
by David Bergman 25 Jul '06

25 Jul '06

For the "mpl::push_back" and "mpl::remove" applications. Sorry about that! /David

1 0

Two informal proposals: generate_hierarchy and embed_type
by David Bergman 25 Jul '06

25 Jul '06

Hi, As I mentioned yesterday, I happened to stay up for a few hours and create two related proposals, after being inspired by Beman's 'identifier' suggestion (as part of his quite useful 'system-0.2' proposal.) I saw - as some people here, including Beman - a potentially wider scope for such embeddings that quite integer-centric "database key" types. The question was whether it was worth the effort. First, one needs a flexible policy system to define what structures to preserve from the underlying type. Such policies need to be injected into the ancestry tree of the embedding type. Thus, we need a hierarchy generator. We have all looked at Andrei's Loki library and its hierarchy generator - I assume. For my purposes, it was actually a bit too specific and data-holding-centric. And, I wanted it to jive with Boost.MPL. [PROPOSAL #1 - generate_hierarchy] So, I created "generate_hierarchy.hpp", which is my proposal for a hierarchy generator. It has two modes of generation: spine-like or chain, as explained in my blog (no, I am *not* promoting my crappy blog, but prefer not to repeat that discussion here...): http://davber.blogspot.com/2006/07/hierarchy-generation-in-c.html. [PROPOSAL #2 - embed_type] After having that hierarchy generator, I then took the rest of the night to create a type embedder, "embed_type.hpp". There is still some work to handle small and big types differently (reference vs. copying) and the naming of policies and such is a bit weird. In short, one can achieve an isomorphic (w.r.t. order, equivalence, arithmetics and conversion) embedding by struct MyInt : embed_type<int, MyInt> { MyInt(int num) : embed_type<int, MyInt>(num) {}; }; int foo = MyInt(42); // will compile! and if you do not want conversion to int, you can do struct MyInt : embed_type<int, MyInt, mpl::remove<embed_policy_all, policy<embed_conversion> > > { MyInt(int num) : embed_type<int, MyInt, ... [ugh, I do not like GCC 3.3 sometimes]>(num) {}; }; int foo = MyInt(42); // will not compile :-( (or should it be :-) since it was expected?) DISCLAIMER: these are quite early drafts of proposals created during one sleepness night, so spare with me. I basically want to know if there is any interest in these libraries and, if so, if they should be proposed as additions to existing Boost libraries or part of new library/ies. The two proposals (two files) with small samples (two files) are attached as a ZIP file (till I gain access to the file vault of Boost.) I will go to bed now, /David

2 2

Low-level precision timer proposal
by Silex 25 Jul '06

25 Jul '06

Hello, Currently there's boost::timer which is a timer based on std::clock(). While this might be sufficient for many people, some want low-level resolution timers. I made a QueryPerformanceCounter() / gettimeofday() wrapper that allows portable millisecond resolution. You'll find attached a basic sample of my trivial work. I tried to make it so inclusion in boost is straight-forward. To see it in action : -Copy the precise_timer* hpp files into the boost directory. -Compile main.cpp & execute it. Would boost be interested by including this class in boost::timer ? I'm all ear for your suggestions / bugs / whatever fits it :) This is the 1st time I propose something to boost so there's probably things to be said on the implementation details (files structure, #ifdef strategy etc) so don't hesitate to tell what should be changed. I also can make that if on windows QueryPerformanceCounter() fails because there's no low-level resolution timer available it uses timeGetTime() instead. But that'd require linking to winmm.lib which could be a problem ( and I never saw a win32 machine where QueryPerformanceCounter() didn't work ). I just thought that I could also rename it to lowres_timer instead of precise_timer, it's more accurate, what do you think ? Regards, Philippe Vaucher

17 84

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

25 Jul '06

Boost Regression test failures Report time: 2006-07-25T10:00:28Z 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… 285 failures in 24 libraries algorithm/string (1) concept_check (1) config (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 |config| limits_test: msvc-8.0 |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

Re: [boost] boost::bind dilemma
by Sohail Somani 25 Jul '06

25 Jul '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Goldshteyn > Sent: Tuesday, July 25, 2006 8:33 AM > To: boost(a)lists.boost.org > Subject: [boost] boost::bind dilemma > > I have an interesting dilemma in my usage of boost::bind. Consider: > [snip lots of bind statements] At this point you might be better off writing your own loop. I personally draw the line at multi-line bind statements with stl algorithms - not as a moral issue or anything :)

1 0

boost::bind dilemma
by Michael Goldshteyn 25 Jul '06

25 Jul '06

I have an interesting dilemma in my usage of boost::bind. Consider: --- // Definitions class Key; class BigValue { public: const Key &GetKey() const; }; class MyMap { public: void Insert(const Key &k, const BigValue &v); }; // Usage void foo() { std::vector<BigValue> lotsOfValues; // Populate lots of values... ... // Transfer those values to the map, using the keys which are within the values MyMap myMap; // The transfer and also, the dilemma // Solution 1 std::for_each( lotsOfValues.begin(), lotsOfValues.end(), boost::bind( MyMap::Insert, // The function used to insert boost::ref(myMap), // The map into which we are inserting the keys/values boost::bind(BigValue::GetKey,_1), // The function to be called to extract the key from the value _1 ) ); } --- 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. Since this is a "BigValue" and the Insert() function in MyMap takes a const reference as it's second parameter, I would like for it not to be copied. So, the solution becomes: // Solution 2 --- std::for_each( lotsOfValues.begin(), lotsOfValues.end(), boost::bind( MyMap::Insert, // The function used to insert boost::ref(myMap), // The map into which we are inserting the keys/values boost::bind(BigValue::GetKey,_1), // The function to be called to extract the key from the value boost::bind<const BigValue &>(boost::cref<BigValue>,_1) // Get at the value, without creating a temporary BigValue ) ); --- Well this sure looks overly complex. Shortcuts, such as the following, will not compile: // Invalid solution 3 --- std::for_each( lotsOfValues.begin(), lotsOfValues.end(), boost::bind( MyMap::Insert, // The function used to insert boost::ref(myMap), // The map into which we are inserting the keys/values boost::bind(BigValue::GetKey,_1), // The function to be called to extract the key from the value boost::cref(_1) // Attempt to use the cref directly, and let bind deduce the type (fails to compile) ) ); --- // Invalid solution 4 --- std::for_each( lotsOfValues.begin(), lotsOfValues.end(), boost::bind( MyMap::Insert, // The function used to insert boost::ref(myMap), // The map into which we are inserting the keys/values boost::bind(BigValue::GetKey,_1), // The function to be called to extract the key from the value boost::bind(boost::cref<BigValue>,_1) // Attempt to use the cref, deferred, and let bind figure out the resultant return type (fails to compile) ) ); --- Is there a simpler solution than Solution 2, above? Thanks, Michael Goldshteyn

1 0

Misbehaviour of boost.regex
by Torsten Landschoff 25 Jul '06

25 Jul '06

Hi *, I think I stumbled across a bug in boost.regex, but perhaps it is just me misunderstanding the docs. Basically it seems like regex_match breaks its postcondition when working with std::string input and smatch result. Attached is a new test case for the test suite (my first trial, I bet it does not fit into boost unchanged) which shows the bug (if it is one). Interestingly, using regex_match together with a const char pointer and cmatch results works like expected. I attached the new source file, which belongs into boost/libs/regex/test/regress together with changes to the Jamfiles as a diff. Any comments welcome. Greetings Torsten

3 3

[move semantics] Do we have any plan for move semantics emulation?
by Ion Gaztañaga 25 Jul '06

25 Jul '06

Hi to all, The rvalue reference is likely to be accepted for the next standard and the standard library is also likely to be modified to implement move semantics. Googling around, the only thing I've found related to Boost and move semantics is Jonathan Turkanis' Boost Move Ptr (http://www.kangaroologic.com/move_ptr/) This move ptr and Howard's unique_ptr emulation code (http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr_03.html) are similar and offer a good new smart pointer. However, I was wondering if we could try to sketch an emulation of "std::move()" for objects that are not unique_ptr/move_ptr. Something that would allow at least to define (portably, perhaps with a macro that in the future, with compilers that implement move semantics, can be expanded to the proper && signature) move constructors and assignments: boost::movable_t movable_source(...); boost::movable_t movable_target(boost::move(movable_source)); We won't have perfect forwarding but we could start playing with move semantics to see how it feels. We would need an explicit move from temporaries, if rvalue catching can't be emulated: boost::movable_t produce_movable(); boost::movable_t movable_target(boost::move(produce_movable())); The idea would be to define some macros that would allow some kind of emulation and that would become proper rvalue references in future compilers: my_class(BOOST_NAMED_RVALUE_REF(my_class) move_src) : m_member(BOOST_NAMED_RVALUE_REF_GET(move_src).member) {} BOOST_RVALUE_REF might be a class holding a pointer to the move sourceand BOOST_RVALUE_REF_GET an operator returning a reference to the pointed object: #define BOOST_NAMED_RVALUE_REF(class_name) rvalue_emulation<class_name> #define BOOST_NAMED_RVALUE_REF_GET(object_name) (*object_name) in the future those would be expanded to: #define BOOST_NAMED_RVALUE_REF(class_name) class_name && #define BOOST_NAMED_RVALUE_REF_GET(object_name) object_name As far as know, only Codewarrior (don't know if an experimental version or officially released one) has move semantics implemented under an explicit pragma. I've read about efforts to implement this on gcc but I haven't heard anything recently. Does any booster ideas for emulating move semantics or is there any ongoing effort? I'm ready to help a bit about this, but I would want to know if I might be duplicating efforts. Regards, Ion

3 4

[Boost-bugs] [ boost-Bugs-1528399 ] [program_options] Endless loop with long default arguments
by SourceForge.net 25 Jul '06

25 Jul '06

Bugs item #1528399, was opened at 2006-07-25 16:02 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=1528399&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] Endless loop with long default arguments Initial Comment: when using a po::value with a representation of the default value having a certain length, 'std::cout << opts' will stuck in an endless loop. E.g. ----- #include <boost/program_options.hpp> #include <string> #include <iostream> namespace po = boost::program_options; int main(int argc, char *argv[]) { po::options_description opts; opts.add_options() ("cfgfile,c", po::value<std::string>()->default_value("/usr/local/etc/myprogramXXXXXXXXX/configuration.conf"), "the configfile"); std::cout << opts; } ----- | $ rpm -q boost | boost-1.33.1-5 | | $ g++ foo.c -lboost_program_options | $ strace ./a.out | ... | write(1, " -c [ --cfgfile ] arg (=/usr/lo"..., 80 -c [ --cfgfile ] arg (=/usr/local/etc/myprogramXXXXXXXXX/configuration.conf) | ) = 80 | write(1, " "..., 80 | ) = 80 | write(1, " "..., 80 | ) = 80 | ... Removing one 'X' will result in an ugly | -c [ --cfgfile ] arg (=/usr/local/etc/myprogramXXXXXXXX/configuration.conf) t | h | e | c | o | n | f | i | g | f | i | l | e output. It would be nice, when: - the default value could be moved into the description column - the description would begin on a new line and an earlier column (e.g. 30-40) when option name/default-value are too long (> 30-40 chars) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1528399&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] is_nan
by Martin Bonner 25 Jul '06

25 Jul '06

----Original Message---- From: Johan Råde > template<class T> bool is_nan(T a) > { > return a != a; > } > > > 1. Do these implementations work an all platforms? I believe is_nan is vunerable to over-eager optimizers for built-in types. > 2. The category not-a-number can be divided into the sub-categories > quite not-a-number and signalling not-a-number. ^^^^^ Should be "quiet". This error has continued throughout the email chain, so it is obviously not just a simple typo (or it is getting copy-and-pasted). -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

3 2

multi-array problem
by Neal Becker 25 Jul '06

25 Jul '06

I ran into a problem using multi-array. Not really a "bug", but a bit of unexpected behavior. Most containers have constructors like: template<typename old_t> Container (old_t const&); Allows constructing the new container from any sequence - the new container will have a copy of the contents of the old (usually). If you try this with multi-array you will not get a compilation error, but also will not get anything like what you expected.

1 0

Create a boost/algorithm/math sub-library?
by Daryle Walker 25 Jul '06

25 Jul '06

We have a general algorithms directory, currently with a subdirectory with string routines. I want to add a parallel subdirectory with math routines. The routines I want to add are for the Greatest Common Factor and the Least Common Multiple. Now, I already have a header for that in Boost at $ROOT/boost/math/common_factor_rt.hpp, but the main function and function object class templates in that header encapsulate the real implementation. It's those implementation functions that I want to public place in the algorithm collection. They would be: 1. GCD for unsigned numbers and other non-signed entities, like polynomials, using division & modulus reduction. 2. GCD for signed entities; similar to [1] but there are sign comparisons and possible negations, which types in [1] don't have to support. 3. GCD for binary unsigned integers using bit-level operations; it has the same complexity as [1] and [2], O(digit_count^2), but is generally faster because bit twiddling is faster than division. The wrapping code currently in the math libraries, and elsewhere, would be changed to call these routines. Would this require a full-blown review, a mini-review, or no review? Note that we currently do _not_ implement [3] anywhere in Boost (AFAIK). For the future, I envision algorithm/math to only hold function (templates) that compute specific ways to evaluate a relation of interest. Full blown wrapping functions and function objects, as well as types, would stay within the regular math libraries (and call the algorithms as needed). -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

3 3

Incorrect library naming in bbv2
by John Maddock 25 Jul '06

25 Jul '06

The current name mangling scheme in bbv2 still doesn't match bbv1 and the auto-linking code. In particular if I build a library as a dll with msvc it doesn't get a "-mt" part in the library name, even though all builds against the dll runtime *are* multithreaded in msvc. Thanks, John.

2 1

[Boost-bugs] [ boost-Bugs-1528178 ] ublas: bug in mapped_vector_of_mapped_vector
by SourceForge.net 25 Jul '06

25 Jul '06

Bugs item #1528178, was opened at 2006-07-25 05:54 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=1528178&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: 9 Submitted By: Matthias Troyer (troyer) Assigned to: Nobody/Anonymous (nobody) Summary: ublas: bug in mapped_vector_of_mapped_vector Initial Comment: There is a serious bug in the mapped_vector_of_mapped_vector spare matrix type. Rows containing only zero elements are not treated correctly in prod(). The following code should give a vector that contains only 1 in the last element. Instead prod() gives a vector containing 1 in each element. In debug mode this bug is found by the checks: Check failed in file boost/boost/numeric/ublas/detail/ vector_assign.hpp at line 371: detail::expression_type_check (v, cv) Aborted The bug appears in Boost 1.33 as well as in the CVS version #include <boost/numeric/ublas/matrix_sparse.hpp> #include <boost/numeric/ublas/vector.hpp> int main() { boost::numeric::ublas::mapped_vector_of_mapped_vector<double> m (64,64); boost::numeric::ublas::vector<double> v(64); boost::numeric::ublas::vector<double> w(64); v[63] = 1.; m(63,63) = 1.; w = boost::numeric::ublas::prod(m,v); } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1528178&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] [system] - std::terminate() called after throw system_error
by Oliver.Kowalke＠qimonda.com 25 Jul '06

25 Jul '06

Hello, please ignore my previous post - I forgott the try-catch block (what a shame). Oliver

1 0

Re: [boost] [system] system-0.2 request for comments
by Beman Dawes 25 Jul '06

25 Jul '06

On 7/22/06, Kim Barrett <kab(a)irobot.com> wrote: > At 12:10 PM -0400 7/22/06, Beman Dawes wrote: > >* 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. > > This appears to be very similar in intent to the facility provided by > boost/strong_typedef.hpp, though there are significant differences in > detail. The intents of identifier.hpp and strong_typedef differ. A strong typedef retains all operations on the underlying type in the new type. An identifier only provides a very limited set of operations on the new type. That is so an operation like multiplication of an identifier, which is almost certainly an error, is not permitted and will be detected by the complier. It wouldn't surprise me if Boost has identifier.hpp functionality somewhere, but I'm not aware of anything. --Beman

2 1

Re: [boost] [system] system-0.2 request for comments
by Oliver.Kowalke＠qimonda.com 25 Jul '06

25 Jul '06

Hi, > ~/devTools/boost_cvs/libs/system/build$ bjam ...found 225 targets... > ...updating 14 targets... > gcc-C++-action > ../../../bin/boost/libs/system/build/libboost_system.a/gcc/deb > ug/error_code.o > ../src/error_code.cpp: In function > 'std::string<unnamed>::errno_md(const > boost::system::error_code&)': > ../src/error_code.cpp:190: error: invalid conversion from > 'char*' to 'int' > ///that's the while condition here... > > char buf[64]; > char * bp = buf; > std::size_t sz = sizeof(buf); > int result; > while ( (result = strerror_r( ec.value(), bp, sz )) == ERANGE ) > { > if ( sz > sizeof(buf) ) std::free( bp ); > sz *= 2; /* Reentrant version of `strerror'. There are 2 flavors of `strerror_r', GNU which returns the string and may or may not use the supplied temporary buffer and POSIX one which fills the string into the buffer. To use the POSIX version, -D_XOPEN_SOURCE=600 or -D_POSIX_C_SOURCE=200112L without -D_GNU_SOURCE is needed, otherwise the GNU version is preferred. */ Oliver

2 1

Who wants Borland support?
by David Abrahams 25 Jul '06

25 Jul '06

In 1.33.1, Boost.Parameter supported Borland. In 1.34, we are running into compiler bugs that we don't know how to avoid. Somehow the compiler is mis-deducing the return type of operator[] on line 328 of boost/parameter/aux_/arg_list.hpp (see http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i…) If we can't find a solution to this problem very soon we'll have to mark these tests as expected failures and drop support of Borland for 1.34, and we're stumped. I'm hoping someone who cares about Borland will help us come up with an answer. Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.com

4 11

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