- Boost - lists.boost.org

Re: [boost] Boost.Bimap - Informal Review Request
by JOAQUIN LOPEZ MU?Z 09 Aug '06

09 Aug '06

----- Mensaje original ----- De: JOAQUIN LOPEZ MU?Z <joaquin(a)tid.es> Fecha: Miércoles, Agosto 9, 2006 7:29 pm Asunto: Re: [boost] Boost.Bimap - Informal Review Request > > > ----- Mensaje original ----- > De: Matias Capeletto <matias.capeletto(a)gmail.com> > Fecha: Miércoles, Agosto 9, 2006 6:40 pm > Asunto: Re: [boost] Boost.Bimap - Informal Review Request > > > On 8/9/06, JOAQUIN LOPEZ MU?Z <joaquin(a)tid.es> wrote: > > > > I've got a feature request about list_of and vector_of. When > > > writing for instance: > > > > > > bimap<set_of<X>,list_of<Y> > > > > > > > we know (unlike in Boost.MultiIndex) that the Y part does not > > > belong to any index key and thus can be freely mutated. Could it > > > be possible that, in those cases, the associated relation > > > class held a mutable Y allowing for direct manipulation of > > > that member? > > > > Nice! That will be very useful. A map where you can iterate over > > the data types? > [...] > > Not sure if I've explaiend myself clearly. What I mean is, > suppose I've got > > typedef bimap<set_of<int>,list_of<std::string> > bm_type; > > then it'd be good to be able to write: > > bm_type bm; > ... > bm.left.begin()->second="hola"; > > which is currently not possible since bm_type::value_type::left... I meant "right", sorry :) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] Boost.Bimap - Informal Review Request
by JOAQUIN LOPEZ MU?Z 09 Aug '06

09 Aug '06

----- Mensaje original ----- De: Matias Capeletto <matias.capeletto(a)gmail.com> Fecha: Miércoles, Agosto 9, 2006 6:40 pm Asunto: Re: [boost] Boost.Bimap - Informal Review Request > On 8/9/06, JOAQUIN LOPEZ MU?Z <joaquin(a)tid.es> wrote: > > I've got a feature request about list_of and vector_of. When > > writing for instance: > > > > bimap<set_of<X>,list_of<Y> > > > > > we know (unlike in Boost.MultiIndex) that the Y part does not > > belong to any index key and thus can be freely mutated. Could it > > be possible that, in those cases, the associated relation > > class held a mutable Y allowing for direct manipulation of > > that member? > > Nice! That will be very useful. A map where you can iterate over > the data types? [...] Not sure if I've explaiend myself clearly. What I mean is, suppose I've got typedef bimap<set_of<int>,list_of<std::string> > bm_type; then it'd be good to be able to write: bm_type bm; ... bm.left.begin()->second="hola"; which is currently not possible since bm_type::value_type::left is const. But in this particular case there's no danger in making bm_type::value_type::left a mutable member (thus allowing for the above) since list_of<> is not key-based. Sorry if my proposal was already clear and this re-explanation is superfluous, but I'm not getting yout "you can iterate over the data types" part. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[smart_ptr] Proposal to add opreator->() in class weak_ptr.
by Сергей Ильин 09 Aug '06

09 Aug '06

Let’s add this code into the weak_ptr: shared_ptr<element_type> operator-> () const // throws bad_weak_ptr when expired { shared_ptr<element_type> temp = lock(); if( !temp ) boost::throw_exception( boost::bad_weak_ptr() ); return temp; } New way of use weak_ptr: shared_ptr< MyClass > sp( new MyClass ); weak_ptr< MyClass > wp(sp); try { wp->Use1(); wp->Use2(); } catch( const exception& e ) { cout << e.what() << endl; } It seems to me, that my way is more convenient than old school: if(shared_ptr<MyClass> temp = wp.lock()) { temp->Use1(); temp->Use2(); } else cout << "Cannot use, already destroyed" << endl ; -- Sergey Ilyin (mailto:spb.serg@mail.ru)

3 2

Spurious warning in lexical_cast.hpp
by Joe Gottman 09 Aug '06

09 Aug '06

When I compile lexical_cast.hpp using MSVC 03 I get a spurious warning: warning C4701: local variable 'result' may be used without having been initialized. It comes from the following function: template<typename Target, typename Source> Target lexical_cast(const Source &arg) { typedef typename detail::array_to_pointer_decay<Source>::type NewSource; detail::lexical_stream<Target, NewSource> interpreter; Target result; if(!(interpreter << arg && interpreter >> result)) throw_exception(bad_lexical_cast(typeid(NewSource), typeid(Target))); return result; } Of course this code is perfectly safe, as either result will be initialized or an exception will be thrown. However, it would be nice if you can change this code to the following: template<typename Target, typename Source> Target lexical_cast(const Source &arg) { typedef typename detail::array_to_pointer_decay<Source>::type NewSource; detail::lexical_stream<Target, NewSource> interpreter; Target result; if(!(interpreter << arg && interpreter >> result)) { throw_exception(bad_lexical_cast(typeid(NewSource), typeid(Target))); static Target notused ; return notused; //We never get here, but some compilers require it to prevent an uninitialized variable warning } else { return result; } } That will remove the warning. There is similar code in boost::array. Joe Gottman

5 20

Boost regression notification (2006-08-09 [RC_1_34_0])
by Douglas Gregor 09 Aug '06

09 Aug '06

Boost Regression test failures Report time: 2006-08-09T11:36:21Z 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… 239 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 (58) random (1) rational (4) regex (1) serialization (25) signals (16) spirit (1) test (3) tr1 (51) 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 ben_scott1: sun-5.8 bienstman1: sun-5.8 bienstman2: sun-5.8 bienstman3: sun-5.8 callbacks: sun-5.8 data_members: sun-5.8 defaults: sun-5.8 docstring: sun-5.8 enum: sun-5.8 exec: cw-9.4 darwin-4.0.1 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 multi_arg_constructor: sun-5.8 nested: sun-5.8 numpy: 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 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_from_python_test: darwin-4.0.1 shared_ptr: sun-5.8 slice: sun-5.8 staticmethod: sun-5.8 stl_iterator: sun-5.8 string_literal: sun-5.8 test_pointer_adoption: sun-5.8 try: 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_threaded: gcc-4_0_3_tru64 |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_polymorphic_xml_archive_dll: msvc-8.0 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 token_iterator_test: msvc-8.0 |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

1 0

Boost's future, one big download?
by Steven Burns 09 Aug '06

09 Aug '06

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"? Thanks, Steven

5 4

[Serialization] Non-standard extensions used.
by Stephen Hewitt 09 Aug '06

09 Aug '06

I originally posted this message in Boost-users but I think Boost-developers is probably more suitable. It regards a non-standard extension which I think is being used in Boost.Serialization. I have mailed the author (and Boost-users) but he feels the construct is legal. The following is a dead simple example of using Boost.Serialization with an XML output archive which follows the patterns laid down in examples: [CODE] #include <iostream> #include <boost/archive/xml_oarchive.hpp> #include <boost/serialization/nvp.hpp> // Warning level 4. #pragma warning(push, 4) struct MyData { MyData(int val) : m_Value(val) {} template<typename Archive> void serialize(Archive & ar, const unsigned int) { ar & BOOST_SERIALIZATION_NVP(m_Value); // <-- Warning here. } int m_Value; }; void main() { using namespace std; MyData d(3); boost::archive::xml_oarchive oa(cout); oa << BOOST_SERIALIZATION_NVP(d); <-- Warning here. } // Warning level back to normal. #pragma warning(pop) [/CODE] When compiling this code I get the following error: "warning C4239: nonstandard extension used : 'argument' : conversion from 'struct boost::serialization::nvp<struct MyData>' to 'struct boost::serialization::nvp<struct MyData> &' A reference that is not to 'const' cannot be bound to a non-lvalue" I tried MSVC 6 and "Visual C++ 2005" (which can be downloaded from here http://msdn.microsoft.com/vstudio/express/visualC/default.aspx) and got the same error. Interestingly I could not get it to happen with "Microsoft Visual C++ Toolkit 2003" (perhaps I made a mistake?). The warning seems valid to me. The "BOOST_SERIALIZATION_NVP" looks like this: [CODE] #define BOOST_SERIALIZATION_NVP(name) \ boost::serialization::make_nvp(BOOST_PP_STRINGIZE(name), name) [/CODE] The "make_nvp" function looks like as follows: [CODE] nvp<T> make_nvp(const char * name, T & t){ return nvp<T>(name, t); } [/CODE] "Operator<<", which is used in "main" is reproduced (in part) below: [CODE] template<class Archive> class interface_oarchive { // ... Code removed ... // template<class T> Archive & operator<<(T & t){ this->This()->save_override(t, 0); return * this->This(); } // ... Code removed ... // }; [/CODE] So, to cut to the chase, "BOOST_SERIALIZATION_NVP" expands to a call to make_nvp" which returns a temporary which is bound to a non-const reference in "interface_oarchive::operator<<": this is not legal in standard C++ (unless I'm mistaken). It seems that if you follow to documentation and examples the resulting code isn't standard C++!?! I find the C++ standard a bit like reading a legal document (and I'm no lawyer) but the following sections from ISO 14882 seem to agree that binding a non-const reference to a temporary is illegal: 3.10/5 & 8.5.3/5. I find further evidence for my assertion in the following links: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1690.html http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm Perhaps this issue (assuming I'm correct) seems minor but for me one of the good things about Boost is that it strives avoid non-standards extensions where possible. Also the longer it remains "broken" (again, assuming I'm correct) the more chance a fix will break existing code. I feel the simplest fix would be to make operator<< take a constant reference. The author suggested that the problem could also be solved by making the return value of "make_nvp" constant. Regards, Steve

3 2

Exception Visitor
by Jeremy Day 09 Aug '06

09 Aug '06

All, A message a few days ago, along with my current reading of the book 'C++ Template Metaprogramming', piqued my interest in the idea of an "exception visitor". I put together a little something, and I'm wondering if people might be interested in my (rather poor, at the moment) code. Problem: When using exceptions it is very easy to end up with code that looks something like this: try { //Some code that might throw exceptions. } catch(std::logic_error&) { //Handle the exception. } catch(std::exception&) { //Handle exception. } catch(...) { //Handle everything else } With my code you can transform the above into something along these lines: struct my_exception_handler { typedef boost::mpl::vector<std::logic_error, std::exception> exceptions; void operator()(std::exception& oError) { std::cout << "my_exception_handler::operator()(std::exception&)" << std::endl; } void operator()(std::logic_error& oError) { std::cout << "my_exception_handler::operator()(std::logic_error&)" << std::endl; } void operator()(void) { std::cout << "my_exception_handler::operator()(void)" << std::endl; } }; //Application code. try { //Some code that might throw exceptions, such as: throw std::logic_error("A sample logic error."); } catch(...) { //Magic happens here. catcher(my_exception_handler()); //This prints out "my_exception_handler::operator()(std::logic_error&)" } If anyone is interested I will post what I have for critique (I'm a relative newbie with MPL, so I will likely need a lot of help). I look forward to any and all comments. Jeremy

7 11

[variant] apply_visitor to rvalue variant
by Marc Mutz 09 Aug '06

09 Aug '06

Hi, can anyone here shed some light on this? Thanks, Marc -- Marc Mutz -- marc(a)klaralvdalens-datakonsult.se, mutz(a)kde.org Klarälvdalens Datakonsult AB, Platform-independent software solutions

1 0

Re: [boost] Boost.Bimap - Informal Review Request
by Wang Weiwei 09 Aug '06

09 Aug '06

Hello Matias Capeletto, The library is exactly what I was finding several days ago. The first impression it gives me is that it's quite well documented. Thanks. Max >Hello, > >Boost.Bimap, my SoC project is ready to confront the list. >The project is being mentored by Joaqu�n L�pez Mu�oz. I want >to publicly thank him. > >With Boost.Bimap you can create associative containers where >both types can be used as key. You can think a bimap<X,Y> as >a merge of a std::map<X,Y> and a std::map<Y,X>. The learning >curve of bimap is almost zero if you know how to use standard >containers. > >The original project that encompasses the creation of a one to >one bidirectional map has been extended into a framework that >extends the standard mapping scheme. A bimap is a very flexible >and powerful container, but the interface of the library allows >a user to use it out of the box. > >The project information, docs and sources can be found here: >http://cablemodem.fibertel.com.ar/mcape/oss/projects/mc_projects/boost_proj… > >I will be very pleased if you can make some spare time to review >the interface, design, implementation and documentation of this >library and comment on it. >Because it is better to go clean from the beginning, these are >some of the questions that will surely rise a discussion. > >* Do you like the usage interface? > >* In relation with Boost.MultiIndex, Do you think that it is > worth to have a bidirectional map library in Boost, that trades > generality for a better specialized user interface? > (Because this library was encouraged by the boost mentors the > answer will surely be yes, but it is a nice discussion to have) > >* Do you like the extended mapping framework? > Do you think it is intuitive for someone with a stl background? > >* What do you think of the design of operator[]? > Is there a better way to be coherent with the stl that does not imply > throwing exceptions? > >* What is your evaluation of the implementation? > I am very interested in your reaction to the zero-overhead achieved > by the almost-standard mutant_relation class, and the standard > compliant label that this library acquires by including the > standard_relation class. > A big part of the library implementation is ContainerAdaptor. > Do you deem Boost.ContainerAdaptor worth eventually proposing to > Boost? > >Looking forward to getting your feedback, > >Matias Capeletto >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0