- Boost - lists.boost.org

[review] request date change for Local review
by Jeffrey Lee Hellrung, Jr. 18 Oct '11

18 Oct '11

I'm manager for the review of Lorenzo Caminiti's Local library. After a brief discussion with Lorenzo and Greg Crosswhite (review manager assistant), we've decided it would be prudent to push the Local review back to November 10th - 20th (originally scheduled for October 24th - November 2nd), given its overlap with the Atomic review and it being likely that several possible review contributors could be tied up getting 1.48.0 shipped out during the original review time frame. Is it not too late to reschedule? It looks like Local is the last library scheduled for review, and I don't see any conflicts in the calendar. If this is problematic for anyone for any reason, please let me know. Thanks, - Jeff

1 0

[Review:Algorithms] - Review by Neil Groves
by Neil Groves 18 Oct '11

18 Oct '11

*Evaluation of the design.* The design is pleasingly consistent with other algorithms with the exception of clamp_range. The clamp_range function copies, which is inconsitent with the other Boost string algorithms that have the _copy suffix. The clamp_range feature would be better designed as a clamped range adaptor. *Evaluation of the implementation* Generally, the algorithms would benefit from concept checking. In particular the iterator traversals, and range concept requirements should be checked. The implementation of the functions in all.hpp and clamp.hpp are correctly implemented. The clamp function does not provide the usual guarantees about NaN values that most of the floating-point operations do. That is any one argument being NaN does not guarantee a NaN result. This is probably intended, if so a note should be made in the documentation.The argument types may benefit from using call_traits to optimally chose between constant reference and value types. It might be worth considering an assertion that p(lo,hi) is true in the clamp function. The mixing of differing integer types makes the search algorithms defective. The int type is signed, and typically <= the size of std::size_t yet these are mixed. The skip table uses ints, but std::size_t values are inserted. Certainly there should not be any c style casts. It would seem logical to use the boost::iterator_difference<Iterator>::type instead. Currently these algorithms are defective albeit under unusual conditions. There are numerous invocations of non-member functions that should use qualified calls to avoid accidental argument-dependent lookup. range_const_iterator<Rng> has been deprecated in favour of range_iterator<const Rng> The Range versions of the functions should provide a non-const reference version since there are no requirements for the interoperability of range_iterator<const Range> and range_iterator<Range> although they normally exist.. The tests have some defects with respect to dereferencing end iterators. As others have mentioned there should be range versions of all of the functions. *Evaluation of the documentation* The documentation should make very clear that the result for empty ranges into all_of, any_of, none_of as this is currently ambiguous. The documentation should provide more clear performance guarantees about the number of predicate evaluations where this is possible eg. any_of can and does early exit. The documentation should also provide the exception guarantees. *Evaluation of usefulness* If corrected and properly documented these functions will be very useful. The functions any_of etc. are extremely useful for runtime assertions of pre- and post-conditions. *Did I try to use the library?* I used the library with GCC 4.6.1. I had no problems, although I did defect the defects noted above. *How much effort did I put into my evaluation?* I reviewed the code for a couple of hours which was sufficient for the small amount of code under review. *Am I knowledgeable about the problem domain?* Yes, I maintain Boost.Range hence my comments with respect to ranges are reasonably well informed. I have long been a fan of Design by Contract and hence I have experience using my own versions of the functions all_of etc. I vote for inclusion into Boost if and only if: 1. the defects in the search functions and test are resolved 2. clamp_range is removed or replaced. Regards, Neil Groves

9 15

[multi_array] swap
by Maxim Yanchenko 18 Oct '11

18 Oct '11

Hi, The swap support for multi_array was under discussion from the very beginning. A multi_array is quite a heavy object so having light-weight and no-throw swap would be really great. In 2009 a patch was proposed (https://svn.boost.org/trac/boost/ticket/1045) and Ronald Garcia generally liked it, but planned to do some extra work before adding swap to multi_array (see the comments for the ticket above). What is the current status? Thanks, Maxim

2 1

[msm]Event convert at exit point
by Takatoshi Kondo 17 Oct '11

17 Oct '11

Hello, I have a question about Boost.Msm event conversion at exit pseudo state. (Version 1.47.0) http://www.boost.org/doc/libs/1_47_0/libs/msm/doc/HTML/ch03s02.html#d0e942 Exit pseudo states struct event6 { event6(){} template <class Event> event6(Event const&){} }; //convertible from any event Above document said that we can convert the event using the template constructor. This exmaple doesn't access the constructor's parameter. I want to propagate some value of the event. Event2 is a source event. And Event3 is a target event like this.(see attached file) struct Event2 { Event2(int val_):val(val_) {} int val; }; struct Event3 { Event3(int val_):val(val_) {} template <class T> Event3(T const& e):val(e.val) {} // error Event3(Event2 const& e):val(e.val) {} // OK int val; }; // Transition table struct transition_table:mpl::vector< // Start Event Next Action Guard msmf::Row < SubState1, Event2, Exit, msmf::none, msmf::none > > {}; struct Exit :msm::front::exit_pseudo_state<Event3> {}; But compile error occurred. The compiler said Event1 doesn't have a member 'val'. I'm not sure why Event3's constructor instantiate from Event1. This is the question. If I define the constructor that has a parameter Event2 instead of template parameter, compile error doesn't occur. exit_pt_convert.cpp(attached file) is a source code that reproduces this error. Thanks, Takatoshi

3 4

Extra files in release branch
by Marshall Clow 17 Oct '11

17 Oct '11

As of revision #74996, the following files and directories exist only in the release branch - not in the trunk. Is this on purpose? boost/smart_ptr/enable_shared_from_this2.hpp boost/test/detail/unit_test_parameters.hpp boost/test/exception_safety.hpp boost/test/impl/unit_test_suite.ipp boost/test/interaction_based.hpp boost/test/logged_expectations.hpp boost/test/mock_object.hpp boost/test/test_observer.hpp boost/test/unit_test_suite_impl.hpp boost/test/utils/callback.hpp libs/phoenix/doc/html/phoenix-doc_HTML.manifest libs/test/example/cla/Jamfile libs/test/example/unit_test_example_011.cpp libs/test/example/unit_test_example_012.cpp libs/test/src/unit_test_suite.cpp libs/test/test/CMakeLists.txt libs/geometry/test/ranges (empty directory) libs/phoenix/doc/html/phoenix (not empty directory) libs/spirit/doc/html/spirit (not empty directory) libs/spirit/repository/doc/html/spirit_repository (not empty directory) libs/test/doc/html/utf/usage-recomendations (not empty directory) -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

4 5

Adding a --log_level="message" runtime option to a Boost.test test-suite
by Paul A. Bristow 16 Oct '11

16 Oct '11

Can anyone tell me how to add a --log_level="message" runtime option to a Boost.Test test-suite. Running using VS project I have a Custom Build Step command line "$(TargetDir)$(TargetName).exe" --log_level="message" I'd like to replicate this in a jamfile : ... test-suite "multiprecision EFX numerical test" : [ run numerical_test.cpp ] ; but adding --log_level="message" (and perhaps other Boost.test options as well). (I want this for all compilers of course, so placing in compile options doesn't seem right.) Suggestions most welcome. Thanks Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

2 6

Unittest capability for meta-programs feedback request
by Ben Robinson 16 Oct '11

16 Oct '11

This submission would make it possible to write a complete set of unit tests for meta-programs, to test both the positive, compiling statements, and the negative, non-compiling statements. These tests will all compile, and the negative tests can throw an exception instead of failing to compile. The submission source is available at https://github.com/icaretaker/Metatest. The provided examples are based on the factorial metafunction from Chapter 8 of "C++ Template Metaprogramming" by David Abrahams and Aleksey Gurtovoy - http://www.boostpro.com/mplbook/. Chapter 8 explains the rational behind the BOOST_MPL_ASSERT_* macros. This submission complements these macros by allowing the writing of regression unit tests, to ensure the user will encounter the mpl formatted compiler error, if the library types are incorrectly instantiated. Currently, many meta-programs are written using one of the BOOST_MPL_ASSERT_* macros. Unit tests for these metaprograms must of course compile, therefore unittests for these programs can verify that valid types produce the correct run-time behavior. This submission provides the following four complementary macros: BOOST_METATEST(pred) BOOST_METATEST_NOT(pred) BOOST_METATEST_RELATION(x, rel, y) BOOST_METATEST_MSG(cond, msg, types) Meta-program authors can use these macros to assert predicates/relations/conditions exactly as done with BOOST_MPL_ASSERT_*. In shipped library code, these four macros exactly forward to their BOOST_MPL_ASSERT_* counterparts, since the BOOST_MPL_ASSERT_* macros do an excellent job of providing maximally informative compiler error messages. In unit test code (where BOOST_METATEST_RUNTIME will need to be defined), these macros will instead instantiate an object, which will throw a runtime exception if the predicate/relation/condition fails. Now meta-program authors can write unittests like the following: BOOST_AUTO_TEST_CASE(factorials_should_not_be_negative) { BOOST_CHECK_THROW( factorial<mpl::int_<-1> > instance;, metatest_exception ); } As you can see, this unit test validates that the factorial meta-function will in fact fail to compile. All exceptions are subclassed from boost::metatest_exception. If the user would instead like to supply their own exception types for individual assertions, one of the following four macros can be used alternatively: BOOST_METATEST_EXP(pred, exp) BOOST_METATEST_NOT_EXP(pred, exp) BOOST_METATEST_RELATION_EXP(x, rel, y, exp) BOOST_METATEST_MSG_EXP(cond, msg, types, exp) Another feature of this library, is that it is independent of any unit testing framework, provided the framework can catch exceptions by type. The examples provided show how this is done with Boost Test. The submission files also show how to use try/catch directly should your unit test framework not have such a capability. I look forward to your feedback. Thank you, Ben Robinson, Ph.D.

16 40

[test] Still having issues
by John Maddock 16 Oct '11

16 Oct '11

I'm still having a lot of issues with the latest Boost.Test not building: On Win32 with Intel's 11.1 and 12.1 compilers I see: ..\..\..\boost/test/impl/execution_monitor.ipp(104): error: invalid redeclaration of type name "_invalid_parameter_handler" (declared at line 228 of "C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\stdlib.h") typedef void* _invalid_parameter_handler; And on Ubuntu Linux with gcc I see: gcc.compile.c++ /home/john/bin/boost/bin.v2/libs/test/build/gcc-4.4.3/debug/link-static/unit_test_main.o In file included from ../../../libs/test/src/unit_test_main.cpp:16: ../../../boost/test/impl/unit_test_main.ipp: In function 'int boost::unit_test::unit_test_main(boost::unit_test::test_suite* (*)(int, char**), int, char**)': ../../../boost/test/impl/unit_test_main.ipp:97: error: 'getchar' is not a member of 'std' "/usr/local/gcc/4.4.3/bin/g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -DBOOST_ALL_NO_LIB=1 -I"../../.." -c -o "/home/john/bin/boost/bin.v2/libs/test/build/gcc-4.4.3/debug/link-static/unit_test_main.o" "../../../libs/test/src/unit_test_main.cpp" Probably a missing <cstdio> include? John.

3 13

[1.48] Reminder: merge fixes by Monday!
by Eric Niebler 14 Oct '11

14 Oct '11

Just a reminder that as of Monday, the release branch will be closed except for permission by a release manager. If you have fixes to merge to the release branch, please try to get them in over the weekend. Here's the schedule: October 10: The release branch was closed for major code changes. It is still open for serious problem fixes and docs changes. October 17: branches/release closed for all library changes except when specific permission given by release manager(s). October 24: Beta target date. Further betas and/or release candidates as feedback dictates. November 7: Release target date View Boost calendar: http://tinyurl.com/4xacpyj Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

Is Boost interested in the Boost-based Base64 library
by Denis Shevchenko 14 Oct '11

14 Oct '11

Hi all! Not so long ago I was looking for a solution to Base64 encoding/decoding. In this page - http://www.boost.org/doc/libs/1_46_1/libs/serialization/doc/dataflow.html - I found example of such solution, with 'base64_from_binary' and 'transform_width' iteartors. But it is just a "blank", not ready-to-use solution. I created solution. But I definitely know many developers looking for a simple, ready-to-use, header-only and 'real C++' solution for Base64. So I want to offer you such solution. Some examples: int main() { std::string my_text = "My text for encoding!"; std::string encoded_text = boost::base64().encode( my_text ); std::string my_text_again = boost::base64().decode< std::string >( encoded ); } For binary data: int main() { typedef std::vector< unsigned char > binary_string; binary_string my_bin = list_of( 0xFF )( 0xAA )( 0x01 ); std::string encoded_bin = boost::base64().encode( my_bin ); binary_string my_bin_again = boost::base64().decode< binary_string >( encoded ); } For streams: int main() { boost::filesystem::ifstream my_jpeg( "/some/path/to/my/image" ); // fstream checking omitted... std::string encoded_jpeg = boost::base64().encode( my_jpeg ); boost::filesystem::ofstream my_jpeg_again( "/some/path/to/decoded/image" ); // fstream checking omitted... boost::base64().decode( encoded_jpeg, my_jpeg_again ); } This is first variant. IMHO such solution will be useful for Boost users. What you think about it? - Denis

7 27