- Boost - lists.boost.org

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

[interprocess] New snapshot and some explanations
by Ion Gaztañaga 09 Aug '06

09 Aug '06

Hi to all, I've uploaded to the boost repository and Boost.Vault/Concurrent Programming: (http://boost-consulting.com/vault/index.php?directory=Concurrent%20Programm…) the first Boost.Interprocess version with documentation. The previous code had no documentation so this is the biggest change. You can find online documentation here: http://ice.prohosting.com/newfunk/boost/libs/interprocess The new documentation tries to explain better the basic operating system wrappers, like synchronization primitives, shared memory objects, essential file mapping, etc... The second part of the documentation is taken and adapted from Shmem. The library still needs some breaking changes, specially, error reporting with proposed boost system exception library. Since Boost.Interprocess offers a wide range of operating system primitives, I want to use the same error report machinery as Boost.Filesystem and Boost.Asio. For the moment, Boost.Interprocess throws interprocess_exception on error. Interesting additions are new named synchronization utilities and the use of move semantics to implement lock transfers, following this proposal: http://home.twcny.rr.com/hinnant/cpp_extensions/threads_move.html Boost.Inteprocess implements upgradable_mutex (a read-write mutex on steroids) with the addition of timed functions and several scoped lock types. You can read about them in the proposal and in Boost.Interprocess documentation: * Upgradable mutex http://ice.prohosting.com/newfunk/boost/libs/interprocess/doc/html/interpro… * Lock Transfers http://ice.prohosting.com/newfunk/boost/libs/interprocess/doc/html/interpro… The move semantics emulation is custom code, but obviously, I'm very interested in a Boost.Move library and I will update the code to use it if that's included in Boost. If the C++ committee chooses a different mutex proposal as the way to go, or modifies this proposal, I will adapt Boost.Interprocess to the new interface. *** Future work *** * Atomic initializations I'm still working on this. My first try has failed, because file locking is not thread-safe in POSIX (the file descriptor is a process-wide resource, and file locking functions don't mutually exclude threads from the same process). Adding an static thread-mutex in the code would not allow using Boost.Interproces in dll-s. Flyweight can't be used, because it relies on the old Boost.Interprocess global mutex to achieve this, so this is a recursive problem ;-). We'll see. * scoped_ptr vs. unique_ptr and move semantics Good old Shmem has it's own scoped_ptr (that has a custom deleter to be able to erase dynamically allocated shared memory objects) and Boost.Interprocess still has it, but I would like to drop it and use a unique_ptr that could be placed in shared memory. This can also substitute scoped_ptr for RAII tasks and we could use it to construct containers of unique_ptr's and avoid tedious hand-deletions. Move semantics could also be applied to other types, like shared memory strings and vectors. A vector of strings in shared memory with move semantics and in-place expansion should be killer. * Allocation algorithm I would want to add the option to allocate memory with alignment restrictions, so that we can request N bytes of memory with at least A byte alignment. This is a usual user request and I think that can be used for some new tricks. ...And of course, I must change the documentation according to the review. Thanks to all for all bug reports! Regards, Ion

4 10

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

08 Aug '06

Boost Regression test failures Report time: 2006-08-08T07:27:38Z 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… 238 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 (2) serialization (24) signals (16) spirit (1) test (2) 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-3_4_4_tru64 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_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_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

Re: [boost] library for type erasure
by Steven Watanabe 08 Aug '06

08 Aug '06

AMDG Alexander, This method seems to cover everything I can think of that is actually possible: struct plus : function<plus, anyT (anyT const&, anyT const&)> { template<class R, class T0, class T1> R entry(const T0& t0, const T1& t1) { return(t0 + t1); } } template<> struct overload<plus, int> { typedef typename transform< integral_types, binary_function<promotion_traits<int, _1>, int, _1> >::type type; } //other integral types are similar template<> struct overload<plus, string> { typedef vector< string(const string&, const string&), string(const string&, const char*), string(const char*, const string&) > type; }; This allows new types to be added without changing plus at all. It should be fast since in most cases there will not be a lot of possible overloads after the initial lookup. There would of course be a catch-all when none of the overloads matches. By default it should probably be something like: void no_match(const any<L>& any0, const any<L>& any1) { throw(undefined_function(typeid(plus), any0.type(), any1.type())); } I haven't thought of any real disadvantages to this approach. But, as I haven't tried to implement it yet, I may have missed something. In Christ, Steven Watanabe

2 1

A possible addition to the boost license FAQ
by Gennaro Prota 08 Aug '06

08 Aug '06

Hi, a question I get frequently asked is "Can I dual-license a project or a library under the GPL and the Boost Software License?". I suppose I know the answer, but I thought some of you, perhaps Dave or Beman, might have reliable wording from Devin Smith or other lawyers who participated to the license development. -- [ Gennaro Prota, C++ developer for hire ]

8 12

Re: [boost] feature request for optional
by Sascha Krissler 08 Aug '06

08 Aug '06

Fernando wrote: > > [...] > > But when i store values where the type has an > > inline NaT value (for example NULL pointers) i cannot and need not > > use optional. > > Can you explain why you cannot use optional<>? > I definitely see that you don't need it, but for the sake of genericity I > just wouldn't mind the fact that some types do have an identifiable null > value and use optional<> all along. Well i could use it but i do not want to. The space complexity is linear as i have to store it for every entry and a perfect hash could grow alot even for a small number of entries. Further arguments: The interface change would be backward compatible as you add a template parameter which has a default value (indicating the old behaviour). With the change i would have both the more optimal solution and the genericity. My problem is that the implementation of optional is not as trivial as it seems and i cannot wrap the class so i would have to copy and modify the source. And i guess using optional in containers and having both types of values (pointers are a good example for the inline NaT case) is not such a far fetched scenario. In the special case of pointers it would make sense not to have a static member indicating the null value but a Discriminate template parameter having the special value 'class NullPtrTag { };'. Another solution would be to make a detail::generic_optional with all the operator foo and let optional inherit from it. That would be infinitesimal backward-incompatible ;)

3 6