August 2012 - Boost - lists.preview.boost.org

[thread] Memory usage of threads on 64bit linux
by Conrad Mercer 29 Aug '12

29 Aug '12

Hey, I have been using boost threads on 32bit linux for some time and am very happy with their performance so far. Recently the project was moved to a 64bit platform and we saw a huge increase in memory usage (from about 2.5gb to 16-17gb). I have done profiling and found that the boost threads are the source of the huge allocation. Each thread is allocating about 10x what it was doing on 32bit. I profiled using valgrind's massif and have confirmed the issue using only boost threads in a separate test application. I also tried using std::threads instead and these do not exhibit the large memory allocation issue. I am wondering if anyone else has seen this behaviour and knows what the problem is? Thanks --

4 4

[system] Viral C++11 change would break dependent libraries:-(
by Beman Dawes 28 Aug '12

28 Aug '12

Ticket #7278 asks that Boost.System add C++11 noexcept support. A reasonable request, and I implemented it this morning by adding BOOST_NOEXCEPT at the appropriate places specified in the standard. But there is a problem. noexcept is viral, so any classes that inherit from a class that uses noexcept must be changed to also use no except. An example: Boost.Filesystem has this class: class codecvt_error_cat : public boost::system::error_category { public: codecvt_error_cat(){} const char* name() const {return "codecvt";} std::string message(int ev) const; }; Compiling with GCC 4.7 -std=c++0x results in this error: ..\..\../boost/system/error_code.hpp:187:32: error: overriding 'virtual const char* boost::system::error_category::name() const noexcept (true)' To fix it, the filesystem class has to be changed: class codecvt_error_cat : public boost::system::error_category { public: codecvt_error_cat(){} const char* name() const BOOST_NOEXCEPT {return "codecvt";} std::string message(int ev) const; }; I've held off committing the Boost.System changes to trunk until we've had a chance to discuss how to approach this potential break to an unknown number of Boost and user libraries. Ideas? --Beman

5 7

[contract] Broken postconditions on throw
by Andrzej Krzemienski 28 Aug '12

28 Aug '12

Hi Lorenzo, I am now now playing with Contract library and trying to break it. I checked that the framework checks the class invariant even when member function exits via an exception. This is an expected behavior and the framework is working fine. However, I note that the precondition of a (non-member) function is not checked when the function exits via throwing an exception. See the following program: # include <contract.hpp> double get_random_weight() { return -1.0; // erroneous implementation } CONTRACT_FUNCTION ( void (set_weight)( (double&) w ) postcondition(w >= 0.0) ) { w = get_random_weight(); if (w < 0.0) throw 1; // (*) } int main() try { double w = 0.0; set_weight(w); } catch (...) { std::cerr << "CAUGHT EXCEPTION" << std::endl; } Function set_weight() is intended to assign its (output) argument with a value representing weight (in the physical sense). We guarantee that the value we set is always non-negative. The function clumsily attempts to verify the condition itself (the line with *). It signals the failure with an exception, but unfortunately fails to satisfy the postcondition. I expect that this situation should be reported as a postcondition violation. But no violation is reported, and the program successfully outputs "CAUGHT EXCEPTION". Regards, &rzej

4 11

[1.52.0] Open for merging
by Marshall Clow 28 Aug '12

28 Aug '12

The release branch (https://svn.boost.org/svn/boost/branches/release) is open for merging all stable changes from trunk, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging *does not* require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: http://svn.boost.org/trac/boost/wiki/ReleaseSchedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Release Managers, Beman Dawes Daniel James Eric Niebler Marshall Clow Rene Rivera Vladimir Prus

3 2

[contract] a possible future extension
by Andrzej Krzemienski 28 Aug '12

28 Aug '12

Hi Lorenzo, This is definitely outside the scope of the review, but I was wondering whether it would be feasible for the macros in Boost.Contract to handle base class aliases, as described in this proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2881.html The positive "side effect" of your framework is that it has the potential to add various missing language features. I am wondering if these aliases proposed in N2881 are worth the effort. Regards, &rzej

2 1

a (useful?) crtp trick
by pavel 28 Aug '12

28 Aug '12

hi all i post this in the hope someone finds this technique useful to make long story short, here is a snippet: template<typename t> //tag deducing util struct base_tag { typedef decltype(get_tag((t*)42)) type; }; template<typename type, typename tag = typename base_tag<type>::type> struct Base //crtp base class { friend tag get_tag(type*); //helper declaration, never defined }; template<typename type> //no mention of tag void f(const Base<type>&) //tag is deduced automatically {} struct Foo : Base<Foo, void> //derived type {}; int main() { Foo foo; f(foo); } the idea is that if we have an associated type (or types) along with the "real" type in the crtp pattern we can make that associated type deduced automatically and even pretend there is no such tag leaving it e.g. for advanced usage more on this here: http://programmizm.sourceforge.net/blog/2012/because-we-can -- Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out

3 7

release manager for 1.52?
by Oliver Kowalke 28 Aug '12

28 Aug '12

Who is the release manager for 1.52?

2 1

[atomic] lockfree failure on msvc 64-bit
by Christoph Macheiner 27 Aug '12

27 Aug '12

As indicated by http://www.boost.org/development/tests/trunk/developer/output/cm_x64-boost-…. In boost/atomic/detail/interlocked.hpp, BOOST_ATOMIC_LLONG_LOCK_FREE must be defined to 2 if _WIN64 is defined (cas64strong.hpp is included afterwards). Because the library has not yet been released, I didn't bother to create a ticket and because the change is so trivial I didn't create a patch as well (if either or both is required or wanted, please let me know). Question: If I recall correctly, long long can be made lockfree also in 32-bit. If I am right, is there a reason why it hasn't been done? Thanks. --Christoph.

1 0

memory corruption in async_read_until using asio::ssl
by Jim Page 27 Aug '12

27 Aug '12

Afternoon All I am seeing an occasional memory corruption bug, using valgrind, in our web server application that is using boost::asio::ssl, and it seems to be related to calls to async_read_until, where several chunks of data are required before the terminating regex is found. What appears to be happening is that engine::perform() causes a write (via ssl3_read_bytes()) on a deleted memory region, the buffer into which decrypted data is written. This region was delete'd via invocation of the detail::io_op::handler, and in turn via read_until_delim_op::operator(), due to prepare() being called on the streambuf, and a std::vector<char> is delete'd in order to create a larger one. It seems like one of the chain of handlers is using a pointer which is becomes invalid when the streambuff is expanded after failing to find the regex terminator after one or more reads, and prepare() is called before the next async_read_some() on the underlying stream. I have included the valgrind output at the end - sorry for the large size. I am pretty certain that I have ruled out the obvious (multiple simultaneous attempts to read using the same streambuf), and I am only using one thread for the io_service. This seems a pretty common potential failure mode, so perhaps I am barking up the wrong tree - I'd appreciate anyone's opinion before I start a potentially tricky debug effort requiring modification to the boost libraries on our production servers. I'm using boost 1.49. There's a lot of optimization on the application which is why some calls are optimized out of the valgrind dump. The machines are running Centos 5.8, x86_64. Compiler is gcc 4.4.6. Thanks for looking Jim Page ==29870== Thread 22: ==29870== Invalid write of size 1 ==29870== at 0x4A088F8: memcpy (mc_replace_strmem.c:587) ==29870== by 0x3400821EDE: ssl3_read_bytes (in /lib64/libssl.so.0.9.8e) ==29870== by 0x340081E750: ??? (in /lib64/libssl.so.0.9.8e) ==29870== by 0x66A75B: boost::asio::ssl::detail::engine::perform(int (boost::asio::ssl::detail::engine::*)(void*, unsigned long), void*, unsigned long, boost::system::error_code&, unsigned long*) (engine.ipp:219) ==29870== by 0x7E3326: boost::asio::ssl::detail::io_op<boost::asio::basic_stream_socket<boost::asio ::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::ssl::detail::read_op<boost::asio::mutable_buffers_1>, boost::asio::detail::rea d_until_expr_op<boost::asio::ssl::stream<boost::asio::basic_stream_socket<bo ost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, std::allocator<char>, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >, boost::_bi::bind_t<void, boost::_mfi::mf2<void, HttpConnection, boost::system::error_code const&, char const*>, boost::_bi::list3<boost::_bi::value<boost::shared_ptr<HttpConnection> >, boost::arg<1> (*)(), boost::_bi::value<char const*> > > > >::operator()(boost::system::error_code, unsigned long, int) (engine.ipp:151) ==29870== by 0x7E45C2: boost::asio::detail::wait_handler<boost::asio::ssl::detail::io_op<boost::asi o::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::ssl::detail::read_op<boost::asio::mutable_buffers_1>, boost::asio::detail::read_until_expr_op<boost::asio::ssl::stream<boost::asio ::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, std::allocator<char>, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >, boost::_bi::bind_t<void, boost::_mfi::mf2<void, HttpConnection, boost::system::error_code const&, char const*>, boost::_bi::list3<boost::_bi::value<boost::shared_ptr<HttpConnection> >, boost::arg<1> (*)(), boost::_bi::value<char const*> > > > > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) (bind_handler.hpp:46) ==29870== by 0x619783: boost::asio::detail::task_io_service::run(boost::system::error_code&) (task_io_service_operation.hpp:37) ==29870== by 0x79F4FE: BayeuxServer::run() (io_service.ipp:59) ==29870== by 0x364800DB8E: ??? (in /usr/lib64/libboost_thread.so.1.49.0) ==29870== by 0x3AE300677C: start_thread (in /lib64/libpthread-2.5.so) ==29870== by 0x3AE20D325C: clone (in /lib64/libc-2.5.so) ==29870== Address 0x1b508610 is 0 bytes inside a block of size 1,024 free'd ==29870== at 0x4A05A33: operator delete(void*) (vg_replace_malloc.c:346) ==29870== by 0x658E54: std::vector<char, std::allocator<char> >::_M_fill_insert(__gnu_cxx::__normal_iterator<char*, std::vector<char, std::allocator<char> > >, unsigned long, char const&) (new_allocator.h:95) ==29870== by 0x68B805: boost::asio::basic_streambuf<std::allocator<char> >::reserve(unsigned long) (stl_vector.h:851) ==29870== by 0x7E2EF2: boost::asio::detail::read_until_expr_op<boost::asio::ssl::stream<boost::asio ::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, std::allocator<char>, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >, boost::_bi::bind_t<void, boost::_mfi::mf2<void, HttpConnection, boost::system::error_code const&, char const*>, boost::_bi::list3<boost::_bi::value<boost::shared_ptr<HttpConnection> >, boost::arg<1> (*)(), boost::_bi::value<char const*> > > >::operator()(boost::system::error_code const&, unsigned long, int) (basic_streambuf.hpp:207) ==29870== by 0x7E32DE: boost::asio::ssl::detail::io_op<boost::asio::basic_stream_socket<boost::asio ::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::ssl::detail::read_op<boost::asio::mutable_buffers_1>, boost::asio::detail::read_until_expr_op<boost::asio::ssl::stream<boost::asio ::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, std::allocator<char>, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >, boost::_bi::bind_t<void, boost::_mfi::mf2<void, HttpConnection, boost::system::error_code const&, char const*>, boost::_bi::list3<boost::_bi::value<boost::shared_ptr<HttpConnection> >, boost::arg<1> (*)(), boost::_bi::value<char const*> > > > >::operator()(boost::system::error_code, unsigned long, int) (read_op.hpp:59) ==29870== by 0x7E493C: boost::asio::detail::reactive_socket_recv_op<boost::asio::mutable_buffers_1, boost::asio::ssl::detail::io_op<boost::asio::basic_stream_socket<boost::asio ::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::ssl::detail::read_op<boost::asio::mutable_buffers_1>, boost::asio::detail::read_until_expr_op<boost::asio::ssl::stream<boost::asio ::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, std::allocator<char>, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >, boost::_bi::bind_t<void, boost::_mfi::mf2<void, HttpConnection, boost::system::error_code const&, char const*>, boost::_bi::list3<boost::_bi::value<boost::shared_ptr<HttpConnection> >, boost::arg<1> (*)(), boost::_bi::value<char const*> > > > > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) (bind_handler.hpp:118) ==29870== by 0x613778: boost::asio::detail::epoll_reactor::descriptor_state::do_complete(boost::asi o::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) (task_io_service_operation.hpp:37) ==29870== by 0x619783: boost::asio::detail::task_io_service::run(boost::system::error_code&) (task_io_service_operation.hpp:37) ==29870== by 0x79F4FE: BayeuxServer::run() (io_service.ipp:59) ==29870== by 0x364800DB8E: ??? (in /usr/lib64/libboost_thread.so.1.49.0) ==29870== by 0x3AE300677C: start_thread (in /lib64/libpthread-2.5.so) ==29870== by 0x3AE20D325C: clone (in /lib64/libc-2.5.so)

1 0

Boost.Process 0.5 released
by Boris Schaeling 27 Aug '12

27 Aug '12

Boost.Process 0.5 has been released! Documentation and library can be found at: <http://www.highscore.de/boost/process0.5/> Why version 0.5? We have no official process management library in Boost yet. But we had countless drafts since 2006. In order not to get completely lost between all those drafts I gave them version numbers. For example, 0.1 was the very first draft in 2006. 0.31 is the draft documented at <http://www.highscore.de/cpp/process/>. And 0.4 was the draft which was rejected in a formal review in spring 2011. Version 0.5 is the latest attempt to create a process management library. What's new? Version 0.5 has a very different design than all other drafts before. The design was proposed by Jeff Flinn who introduced it briefly at BoostCon 2011 when we gave a presentation on Boost.Process. The goals of this new version are: * A lightweight implementation (no overly complicated code anymore). * A fully extensible library (no need for arbitrary "extension points"). * Support for system-level cross-platform concepts only (no Java-like constructs). Other goals like making the library easy to use were of course also targeted. But these were goals before. The goals above are important as those things have been criticized in earlier drafts and were as far as I see the main reasons why version 0.4 had been rejected. What now? Please have a look at the documentation and think about whether this library could fit into Boost. If you have more time, please download and play around with the new version. Concentrate on the bigger picture: Does the design make sense? Is it easy to understand? Can you do what you want to do? Does it look and feel like modern C++? This is not a formal review. But it would help to get some feedback to see a tendency. After six years, two Google Summer of Code projects, countless drafts and still a lot of interest from many people in a process management library in Boost, we might be able to get somewhere this time. (If you are on Windows: There is a bug in Boost.Iostreams which has been fixed in the release candidate 1 of Boost 1.51.0. See the documentation if you run into a problem when closing pipes.) Anything missing? We had a closed beta test in the previous two weeks with about ten people who had contacted me because of their interest in Boost.Process. I got already some good feedback and have to change a few details. These are only details though and shouldn't stop anyone from using this new version now. If everyone is happy with the overall design and architecture and it's only details we have to discuss, it's already a huge step forward. Last but not least: Boost.Process 0.5 wouldn't exist without the help of Intra2net AG (<http://www.intra2net.com/>). Intra2net AG sponsored a project to support the development of Boost.Process. It was this sponsorship which made it possible to create this new version. Thanks to them! Boris

9 46

[rational] Over/underflow checked update ready for comments
by Dan Searles 26 Aug '12

26 Aug '12

>> Quick overview of the update: the original usage and >> code of the template class remains mostly as before, ie >> boost::rational<int> RationalVar; should work as >> in the original version. Adding 'true' as a second >> template parameter, however, allows an exception to >> be raised if an operation with a class variable results >> in a value that can't accurately be represented >I haven't looked at anything else, but I dislike using true/false as the template argument. I'd prefer meaningful names. _____ >Rob Stewart robert.stewart(a)sig.com >Software Engineer using std::disclaimer; >Dev Tools & Components >Susquehanna International Group, LLP http://www.sig.com Replaced the bool template parameter with an enum: enum RationalChecktype {RationalNoChecking, RationalCheckforOverflow};

1 0

[contract] "Duplicated globals" problem
by Andrzej Krzemienski 26 Aug '12

26 Aug '12

Hi Lorenzo, I think that installing broken contract handlers will not work correctly when a program is linking with DLLs on Windows. I do not know how dynamic linking works on Linux. Here is a sketch of a sample program that fails to work as expected. The program consists of two projects: one builds a DLL, the other builds an executable that links with the DLL: DLL: ==================================== # include <contract.hpp> # include "testdll.h" CONTRACT_FUNCTION ( int (give1) () postcondition(auto result = return, result == 1) ) { return 2; // obviously wrong } DLL_MODE void test_contracts() { int i = give1(); } ==================================== EXE: ==================================== # include <contract.hpp> # include "../testdll/testdll.h" void PostconditionHandler( contract::from const& context ) { std::cerr << "ERROR!!!" << std::endl; } int main() { contract::set_postcondition_broken(&PostconditionHandler); test_contracts(); } ==================================== I expect that the program would use the broken postcondition handler I installed, but it still uses the default one. The cause is that Contract is using some global object to store the installed handler, but when a program is linked with a DLL both the program and the DLL store their own copy of the global. The global is duplicated. THe one in the EXE registers my callback, but the global in the DLL still keeps the default handler. The only way to solve this issue is to -- at least in the cases when users' programs link with DLLs -- ship Contract with a small DLL that stores the unique copy of the globals. This is how Boost.Log handles this problem. Quoting the documentation ( http://boost-log.sourceforge.net/libs/log/doc/html/log/installation.html) *"If your application consists of more than one module (e.g. an exe and one or several dll's) that use Boost.Log, the library must be built as a shared object. If you have a single executable, you may build the library as a static library." * Regards, &rzej* *

2 1

complex acos and atanh
by Stephen Montgomery-Smith 26 Aug '12

26 Aug '12

Hey people, I was trying out your complex arc-trig functions, to compare them with some that I have written: http://people.freebsd.org/~stephen/catrig.c. I am finding that your acos function is getting some of them wrong. For example, your program evaluates acos(1.00000002785941 + I*5.72464869028403e-200) as 0 - I*0.000236048349018331 whereas it should be 2.42520172707401e-196 - I*0.000236048349018331. Also your complex atanh function does quite badly in some edge cases. I presume it is because Hull, Fairgrieve and Tang did not write a paper on that function. If you email Fairgrieve, he may give you a copy of the paper that was never published. He sent me a copy, but doesn't want it widely distributed. I devised my own algorithm at http://people.freebsd.org/~stephen/catrig.c, which actually turns out to be very similar to the unpublished algorithm of Hull, Fairgrieve and Tang. Anyway, I would be happy to work with whomever is currently working on these algorithms. I think someone must be, because I see that someone fixed a bug in asin since 1.48.0. Best regards, Stephen

2 2

[locale] Custom Gettext paths.
by Jookia 26 Aug '12

26 Aug '12

Hello! I'm extremely happy about Boost.Locale, but I've found a few things lacking. So at first I wrote a some wrappers to get around a few flaws with my usage of Boost.Locale. One of these flaws was how it's hardcoded to use the Gettext directory hierarchy. I'd rather store my stuff in 'lang/en_US.mo' rather than 'lang/en_US/LC_MESSAGES/my_app.mo'. The patch adds a 'path format' feature, which allows you to format the directory structure when finding Gettext catalogs, to achieve the effect above. All you really have to do is run: gen.add_path_format("{1}/{2}.mo"); // Use a smaller hierarchy. to achieve the result that I prefer, or gen.add_path_format("{1}/{2}/{3}/{4}.mo"); // Use a Gettext hierarchy. to achieve the result that Boost.Locale uses right now. Ripped straight from Doxygen comments: {1} A path to search for catalogs in. {2} The locale's name. {3} The locale's category. {4} The Gettext domain. I'm new to submitting patches and things, and I'm not sure how I could make this feature better or even acceptable if it isn't already, but I'm sure it'd help others out there. There are a few drawbacks I've found with my code: - To be backwards compatible I've had to add some hackery to add the Gettext format if the path formats vector is empty. - Without consulting documentation, the format is unreadable. - I haven't tested it on the Win32 backend. I'm 90% sure the code would work, it's only 4 lines of code added and it's identical to the code added in the other backends, but it's still untested code. - It's not tested properly. By properly, I mean the tests past with adding a format, and falling back to the default format, but I haven't tried having a 'compact' format. I'm not sure if this would indicate a fault in the formatting code though, as that'd be the only difference code-wise, unless there's more code that has the Gettext hierarchy hardcoded, that didn't fail when I didn't fix the tests. The patch itself is based off of SVN r80097, and despite the diff being for r80104 I haven't tested it in that.. I did the work internally in Git but I made the patch using SVN, in case that matters. I've attached the patch, but I'm not sure how well that's going to go over considering I'm new to mailing lists, and I'm using.. Thunderbird.. Yeah. In case the attachment fails, it's available at http://sprunge.us/VSiX . I'd also like to know if it's appropriate to put '[patch]' in the title for any future patches, and if it should go after '[locale]' or at the end of the title. Thanks, Jookia.

2 13

boost::filesystem -- using non-POSIX locale crashes on Solaris
by JonathonS 26 Aug '12

26 Aug '12

Hi, I am currently using boost::filesystem::path on Solaris, and I noticed that if I set the locale to anything except "C" or "POSIX" such as "en_US.UTF-8", that it crashes i.e. a run-time error gets thrown. I found a link describing the issue here: https://svn.boost.org/trac/boost/ticket/5928 My question is though, whether it is possible to use boost::filesystem without locales? Meaning, if I know my string is a UTF-8 string, is it possible to avoid the locale processing within the boost filesystem? Thanks, J

3 2

[Review] Boost.Contract Review Starts Today(*)
by Dave Abrahams 26 Aug '12

26 Aug '12

The review period for Lorenzo Caminiti's Boost.Contract library runs from today through August 31st. I'm pleased to serve as review manager. ,----[ Important Notes ] | - Please begin your review's subject line with "[Review:Algorithms]" | - Please do not post your review or discussion as a reply to this | message. | - Please feel free to note any individual issues in the issue | tracker at https://sourceforge.net/apps/trac/contractpp/report/3 | (you'll need to log in at Sourceforge to add a ticket) and make | reference to them from your review. | - Please see below for *further* important notes `---- THE LIBRARY Boost.Contract implements Contract Programming (a.k.a., Design by Contracts) for C++. In addition, the library implements virtual specifiers, concept checking, and named parameters. Documentation: http://contractpp.sourceforge.net Source: http://sourceforge.net/projects/contractpp/files/latest/download All N1962 requirements and Eiffel features are supported by the library, among others: 1) Support for preconditions, postconditions, class invariants, block invariants, and loop variants. 2) Subcontract derived classes (with support for pure virtual functions and multiple inheritance). 3) Access expression old values and function return value in postconditions. 4) Optional compilation and checking of preconditions, postconditions, class invariants, block invariants, and loop variants. 5) Customizable actions on contract assertion failure (terminate by default but it can throw, exit, etc). This library is implemented for C++03 and it does not require C++11. Obviously, if the library is accepted, all macros will be prefixed by BOOST_... and other symbols will go under the boost::... namespace. Potential Interactions with Existing Boost Libraries ==================================================== This submission potentially interacts with the following existing Boost libraries: * parameter - http://boost.org/libs/parameter * static_assert - http://www.boost.org/libs/static_assert * MPL - http://www.boost.org/libs/mpl * Concept - http://www.boost.org/libs/concept_check Reviewers should consider these potential interactions. What to include in Review Comments ================================== - Keep your criticism constructive. Constructive criticism usually comes with specific suggestions for improvement. - If you identify problems along the way, please note if they are minor, serious, or showstoppers. - Please *do* vote on whether the library should be accepted. Everyone who takes the time to look at the library is qualified to vote, and every vote is valuable. - Other questions you might want to answer in your review: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? (*) Well, OK, the review period officially started yesterday. Sorry for the delayed announcement -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

2 2

[iterator] transform_iterator and move-only types
by Nathan Ridge 25 Aug '12

25 Aug '12

Hi, The following code fails to compile for me: #include <memory> #include <boost/iterator/transform_iterator.hpp> std::unique_ptr<int> foo(int i) { return std::unique_ptr<int>(new int(i)); } int main() { int a[5] = {1, 2, 3, 4, 5}; auto it = boost::make_transform_iterator(a, foo); } The error message I get with GCC 4.8 is pasted below. I think this should work because returning a move-only type from a function by value is a perfectly valid thing to do. Do you agree? Should I file a bug? Thanks, Nate In file included from boost/iterator/iterator_categories.hpp:20:0, from boost/iterator/iterator_adaptor.hpp:14, from boost/iterator/transform_iterator.hpp:12, from test.cpp:2: boost/type_traits/is_convertible.hpp: In instantiation of 'const bool boost::detail::is_convertible_basic_impl<std::unique_ptr<int>&, std::unique_ptr<int> >::value': boost/type_traits/is_convertible.hpp:296:5: required from 'const bool boost::detail::is_convertible_impl<std::unique_ptr<int>, std::unique_ptr<int> >::value' boost/type_traits/is_convertible.hpp:419:1: required from 'struct boost::is_convertible<std::unique_ptr<int>, std::unique_ptr<int> >' boost/mpl/aux_/nested_type_wknd.hpp:26:31: required from 'struct boost::mpl::aux::nested_type_wknd<boost::is_convertible<std::unique_ptr<int>, std::unique_ptr<int> > >' boost/mpl/aux_/preprocessed/gcc/and.hpp:23:8: required from 'struct boost::mpl::aux::and_impl<true, boost::is_convertible<std::unique_ptr<int>, std::unique_ptr<int> >, mpl_::bool_<true>, mpl_::bool_<true>, mpl_::bool_<true> >' boost/mpl/aux_/preprocessed/gcc/and.hpp:48:8: required from 'struct boost::mpl::and_<boost::is_convertible<boost::random_access_traversal_tag, boost::single_pass_traversal_tag>, boost::is_convertible<std::unique_ptr<int>, std::unique_ptr<int> >, mpl_::bool_<true>, mpl_::bool_<true>, mpl_::bool_<true> >' boost/mpl/if.hpp:67:11: [ skipping 6 instantiation contexts, use -ftemplate-backtrace-limit=0 to disable ] boost/iterator/detail/facade_iterator_category.hpp:187:8: required from 'struct boost::detail::facade_iterator_category<boost::random_access_traversal_tag, std::unique_ptr<int>, std::unique_ptr<int> >' boost/iterator/iterator_facade.hpp:104:17: required from 'struct boost::detail::iterator_facade_types<std::unique_ptr<int>, boost::random_access_traversal_tag, std::unique_ptr<int>, long int>' boost/iterator/iterator_facade.hpp:621:9: required from 'class boost::iterator_facade<boost::transform_iterator<std::unique_ptr<int> (*)(int), int*, boost::use_default, boost::use_default>, std::unique_ptr<int>, boost::random_access_traversal_tag, std::unique_ptr<int>, long int>' boost/iterator/iterator_adaptor.hpp:261:9: required from 'class boost::iterator_adaptor<boost::transform_iterator<std::unique_ptr<int> (*)(int), int*, boost::use_default, boost::use_default>, int*, std::unique_ptr<int>, boost::use_default, std::unique_ptr<int>, boost::use_default>' boost/iterator/transform_iterator.hpp:74:9: required from 'class boost::transform_iterator<std::unique_ptr<int> (*)(int), int*, boost::use_default, boost::use_default>' test.cpp:12:52: required from here boost/type_traits/is_convertible.hpp:136:23: error: use of deleted function 'std::unique_ptr<_Tp, _Dp>::unique_ptr(const std::unique_ptr<_Tp, _Dp>&) [with _Tp = int; _Dp = std::default_delete<int>]' static bool const value = sizeof( boost::detail::checker<To>::_m_check(_m_from, 0) ) ^ In file included from c++/4.8.0/memory:81:0, from test.cpp:1: c++/4.8.0/bits/unique_ptr.h:259:7: error: declared here unique_ptr(const unique_ptr&) = delete; ^ In file included from boost/iterator/iterator_categories.hpp:20:0, from boost/iterator/iterator_adaptor.hpp:14, from boost/iterator/transform_iterator.hpp:12, from test.cpp:2: boost/type_traits/is_convertible.hpp:129:41: error: initializing argument 1 of 'static boost::type_traits::yes_type boost::detail::checker<T>::_m_check(T, int) [with T = std::unique_ptr<int>; boost::type_traits::yes_type = char]' static boost::type_traits::yes_type _m_check(T, int); ^

2 2

[tools/regression + filesystem] compiler error
by Jeffrey Lee Hellrung, Jr. 25 Aug '12

25 Aug '12

I was trying to build the boost tools (v1.51.0) and ran into the error pasted below. Should this be concerning? - Jeff Performing configuration checks - has_icu builds : no ...patience... ...patience... ...found 2720 targets... ...updating 3 targets... compile-c-c++ ..\build\boost\regression\msvc-9.0\release\link-static\threading-multi\library_status.obj library_status.cpp regression\src\library_status.cpp(633) : error C2440: 'initializing' : cannot convert from 'const boost::filesystem::path::string_type' to 'std::basic_string<_Elem,_Traits,_Ax>' with [ _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char> ] No constructor could take the source type, or constructor overload resolution was ambiguous regression\src\library_status.cpp(761) : error C2664: 'std::basic_string<_Elem,_Traits,_Ax> &std::basic_string<_Elem,_Traits,_Ax>::append(const std::basic_string<_Elem,_Traits,_Ax> &)' : cannot convert parameter 1 from 'const boost::filesystem::path::string_type' to 'const std::basic_string<_Elem,_Traits,_Ax> &' with [ _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char> ] Reason: cannot convert from 'const boost::filesystem::path::string_type' to 'const std::basic_string<_Elem,_Traits,_Ax>' with [ _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char> ] No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called ..\boost/test/impl/execution_monitor.ipp(948) : warning C4535: calling _set_se_translator() requires /EHa regression\src\library_status.cpp(899) : error C2679: binary '=' : no operator found which takes a right-hand operand of type 'const boost::filesystem::path::string_type' (or there is no acceptable conversion) c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\INCLUDE\xstring(914): could be 'std::basic_string<_Elem,_Traits,_Ax> &std::basic_string<_Elem,_Traits,_Ax>::operator =(const std::basic_string<_Elem,_Traits,_Ax> &)' with [ _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char> ] c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\INCLUDE\xstring(919): or 'std::basic_string<_Elem,_Traits,_Ax> &std::basic_string<_Elem,_Traits,_Ax>::operator =(const _Elem *)' with [ _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char> ] c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\INCLUDE\xstring(924): or 'std::basic_string<_Elem,_Traits,_Ax> &std::basic_string<_Elem,_Traits,_Ax>::operator =(_Elem)' with [ _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char> ] while trying to match the argument list '(std::string, const boost::filesystem::path::string_type)' call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"..\build\boost\regression\msvc-9.0\release\link-static\threading-multi\library_status.obj.rsp" ...failed compile-c-c++ ..\build\boost\regression\msvc-9.0\release\link-static\threading-multi\library_status.obj... ...skipped <p..\build\boost\regression\msvc-9.0\release\link-static\threading-multi>library_status.exe for lack of <p..\build\boost\regression\msvc-9.0\release\link-static\threading-multi>library_status.obj... ...skipped <p..\dist\bin>library_status.exe for lack of <p..\build\boost\regression\msvc-9.0\release\link-static\threading-multi>library_status.exe... ...failed updating 1 target... ...skipped 2 targets...

1 0

[phoenix] Help needed with a custom terminal
by Andrey Semashev 25 Aug '12

25 Aug '12

Hi, I'm trying to define a custom terminal that acts as a replacement of operator<< in expressions when the right argument of the operator is of my special type. The terminal aggregates its left subexpression which results in reference to a stream, and result type of the terminal is the same reference. In short, it looks like this: namespace my { struct argument { std::string m_value; explicit argument(std::string const& value); }; template< typename LeftT > class output_terminal { public: typedef void _is_my_terminal; //! Self type typedef output_terminal this_type; //! Result type definition template< typename > struct result; template< typename ContextT > struct result< this_type(ContextT) > { typedef typename remove_cv< typename remove_reference< ContextT >::type >::type context_type; typedef typename phoenix::evaluator::impl< typename LeftT::proto_base_expr&, context_type, phoenix::unused >::result_type type; }; template< typename ContextT > struct result< const this_type(ContextT) > { typedef typename remove_cv< typename remove_reference< ContextT >::type >::type context_type; typedef typename phoenix::evaluator::impl< typename LeftT::proto_base_expr const&, context_type, phoenix::unused >::result_type type; }; private: //! Left argument actor LeftT m_left; //! Right argument std::string m_right; public: //! Initializing constructor output_terminal(LeftT const& left, std::string const& right); //! Invokation operator template< typename ContextT > typename result< const this_type(ContextT) >::type operator() (ContextT const& ctx) const { typedef typename result< const this_type(ContextT) >::type result_type; result_type strm = phoenix::eval(m_left, ctx); strm << m_right; return strm; } }; template< typename LeftExprT > inline phoenix::actor< output_terminal< phoenix::actor< LeftExprT > > > operator<< (phoenix::actor< LeftExprT > const& left, argument const& right) { phoenix::actor< output_terminal< phoenix::actor< LeftExprT > > > res = { output_terminal< phoenix::actor< LeftExprT > >(left, right.m_value) }; return res; } typedef phoenix::expression::argument< 1 >::type stream_type; const stream_type stream = {}; } // namespace my int main(int, char*[]) { function< void (std::ostream&) > func; func = my::operator<< (my::stream, my::argument("Hello, world!")); func(std::cout); return 0; } I also have specialized phoenix::result_of::is_nullary, phoenix::is_custom_terminal and phoenix::custom_terminal based on the _is_my_terminal tag. The problem is that the code doesn't compile. The compiler output is quite lengthy and it ends in this: ./boost/fusion/adapted/struct/detail/at_impl.hpp:24:16: error: invalid use of incomplete type ‘struct boost::fusion::extension::access::struct_member<boost::phoenix::vector1<const boost::phoenix::actor<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<my::output_terminal<boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::argument<1> >, 0l> > > >, 0l> >*>, 1>’ It is not clear where the problem is but I think for some reason Boost.Phoenix thinks that output_terminal is a nullary terminal, despite the fact that I specialized is_nullary to return false. Is there something wrong with my code or is it a problem with Boost.Phoenix? I have posted the complete code here: http://pastebin.com/Vniq1b5Y and here is the compiler output: http://pastebin.com/8Beg4LiY I'm using release SVN branch and GCC 4.6. Thanks in advance.

1 1

[rational] Over/underflow checked update ready for comments
by Dan Searles 25 Aug '12

25 Aug '12

For those interested in rational, there is an updated version in https://svn.boost.org/svn/boost/sandbox/rational ready for comments. Quick overview of the update: the original usage and code of the template class remains mostly as before, ie boost::rational<int> RationalVar; should work as in the original version. Adding 'true' as a second template parameter, however, allows an exception to be raised if an operation with a class variable results in a value that can't accurately be represented, ie boost::rational<int,true> RationalVarChecked. Checking is only needed on limited precision integer types, and it has been tested with signed char, short, int and long long. Thank you for your constructive comments. Dan Searles

2 1

attempting sandbox svg_plot templates
by Roger Martin 25 Aug '12

25 Aug '12

Hi, Thought svg_plot (https://svn.boost.org/svn/boost/sandbox/SOC/2007/visualization/) is an interesting approach. Trying to stand it up and test it's implementation status. Using gcc 4.7 on Windows 7, Ubuntu 12.04 and CentOS 5. all 64 bit. Run into many template and friend issues. Anybody getting this lib to work? Much coming from https://svn.boost.org/svn/boost/sandbox/SOC/2007/visualization/boost/svg_pl…. First two: .............. In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:32:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:241:11: required from here ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:97:24: error: template-id ‘operator<< <>’ for ‘std::ostream& boost::svg::operator<<(std::ostream&, const boost::svg::unc<false>&)’ does not match any template declaration ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:102:24: error: template-id ‘operator<< <>’ for ‘std::ostream& boost::svg::operator<<(std::ostream&, const std::pair<boost::svg::unc<false>, boost::svg::unc<false> >&)’ does not match any template declaration .............. for the code: .............. friend std::ostream& operator<< <> (std::ostream& os, const unc<correlated>& u); /*! Output a pair of (X and Y) values with (if defined) uncertainty and degrees of freedom. \details For example: "1.23 +/- 0.01 (13), 3.45 +/- 0.06 (78)". */ friend std::ostream& operator<< <> (std::ostream& os, const std::pair<unc, unc>& u); ............... Seems to be where std::ostream is being extended or derived from. But I'm not discerning the template error or good at interpreting them. How to learn? Been looking for examples and where the gcc version makes a difference but get too many hits with google. Headers in unit test leading up to the svg_plot headers are: ------------------------ #include <cmath> #include <map> #include <stdio.h> #include <stdlib.h> #include <vector> #include <iostream> #include <ostream> #include "CUnit/Basic.h" #include "boost/array.hpp" #include "boost/svg_plot/svg.hpp" #include "boost/svg_plot/svg_2d_plot.hpp" #include "boost/svg_plot/show_2d_settings.hpp" .............................. -------------- All the errors and warnings: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp: In instantiation of ‘class boost::svg::unc<false>’: In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:32:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:241:11: required from here ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:97:24: error: template-id ‘operator<< <>’ for ‘std::ostream& boost::svg::operator<<(std::ostream&, const boost::svg::unc<false>&)’ does not match any template declaration ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:102:24: error: template-id ‘operator<< <>’ for ‘std::ostream& boost::svg::operator<<(std::ostream&, const std::pair<boost::svg::unc<false>, boost::svg::unc<false> >&)’ does not match any template declaration ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp: In instantiation of ‘class boost::svg::unc<true>’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:293:28: required from here ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:97:24: error: template-id ‘operator<< <>’ for ‘std::ostream& boost::svg::operator<<(std::ostream&, const boost::svg::unc<true>&)’ does not match any template declaration ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:102:24: error: template-id ‘operator<< <>’ for ‘std::ostream& boost::svg::operator<<(std::ostream&, const std::pair<boost::svg::unc<true>, boost::svg::unc<true> >&)’ does not match any template declaration In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:36:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:87:57: error: ‘result_type’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:87:57: note: suggested alternative: In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/functional/hash/detail/hash_float.hpp:16:0, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/functional/hash/hash.hpp:15, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/functional/hash.hpp:6, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/unordered/unordered_map.hpp:21, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/unordered_map.hpp:16, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/ptr_container/ptr_unordered_map.hpp:19, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/ptr_container/ptr_container.hpp:25, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/svg_tag.hpp:22, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg.hpp:184, from tests/plotting_tests.cpp:20: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/integer/static_log2.hpp:45:45: note: ‘boost::detail::static_log2_impl::result_type’ In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:36:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:87:57: error: template argument 1 is invalid ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:87:40: error: template argument 2 is invalid ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:87:18: warning: ‘typedef’ was ignored in this declaration [enabled by default] ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp: In member function ‘std::pair<boost::svg::unc<correlated>, boost::svg::unc<correlated> > boost::svg::detail::pair_unc_2d_convert<correlated>::operator()(T)’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:105:26: error: ‘un’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:105:39: error: wrong number of template arguments (1, should be 2) In file included from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_algobase.h:65:0, from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_tree.h:63, from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/map:60, from tests/plotting_tests.cpp:10: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_pair.h:88:12: error: provided for ‘template<class _T1, class _T2> struct std::pair’ In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:36:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:105:40: error: expected ‘;’ before ‘c’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:105:40: error: ‘c’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:105:59: error: expected primary-expression before ‘>’ token ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/FP_compare.hpp: At global scope: In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:30:0, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:37, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/FP_compare.hpp:112:12: error: declaration of ‘class FPT’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/FP_compare.hpp:106:10: error: shadows template parm ‘class FPT’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/FP_compare.hpp:187:12: error: declaration of ‘class FPT’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/FP_compare.hpp:172:10: error: shadows template parm ‘class FPT’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/FP_compare.hpp:207:12: error: declaration of ‘class FPT’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/FP_compare.hpp:172:10: error: shadows template parm ‘class FPT’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/FP_compare.hpp:219:12: error: declaration of ‘class FPT’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/FP_compare.hpp:172:10: error: shadows template parm ‘class FPT’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp: In function ‘void boost::svg::scale_axis(const T&, double*, double*, double*, int*, double*, double*, double*, int*, bool, double, bool, double, int, int, bool, double, int, int)’: In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:37:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:350:51: error: to refer to a type member of a template parameter, use ‘typename T:: const_iterator’ [-fpermissive] ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:350:51: error: to refer to a type member of a template parameter, use ‘typename T:: const_iterator’ [-fpermissive] ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:359:5: error: need ‘typename’ before ‘T:: const_iterator’ because ‘T’ is a dependent scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:359:23: error: expected ‘;’ before ‘pos’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:360:9: error: ‘pos’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:364:25: error: ‘pos’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:395:5: error: need ‘typename’ before ‘T:: const_iterator’ because ‘T’ is a dependent scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:395:23: error: expected ‘;’ before ‘pos’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:396:11: error: ‘pos’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:401:9: error: ‘pos’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:456:7: error: ‘cout’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:456:7: note: suggested alternatives: In file included from tests/plotting_tests.cpp:14:0: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:37:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:456:186: error: ‘endl’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:456:186: note: suggested alternatives: In file included from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:40:0, from tests/plotting_tests.cpp:14: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp: In function ‘size_t boost::svg::show(const T&)’: In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:37:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:666:3: error: ‘cout’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:666:3: note: suggested alternatives: In file included from tests/plotting_tests.cpp:14:0: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:37:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:667:8: error: need ‘typename’ before ‘T:: const_iterator’ because ‘T’ is a dependent scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:667:26: error: expected ‘;’ before ‘it’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:667:50: error: ‘it’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:671:11: error: ‘endl’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:671:11: note: suggested alternatives: In file included from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:40:0, from tests/plotting_tests.cpp:14: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp: In function ‘size_t boost::svg::show(iter, iter)’: In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:37:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:684:5: error: ‘cout’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:684:5: note: suggested alternatives: In file included from tests/plotting_tests.cpp:14:0: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:37:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:687:3: error: ‘cout’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:687:3: note: suggested alternatives: In file included from tests/plotting_tests.cpp:14:0: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:62:18: note: ‘std::cout’ In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:37:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:688:11: error: ‘endl’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:688:11: note: suggested alternatives: In file included from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:40:0, from tests/plotting_tests.cpp:14: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:562:5: note: ‘std::endl’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp: In function ‘std::pair<double, double> boost::svg::range(const T&)’: In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:37:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:708:49: error: to refer to a type member of a template parameter, use ‘typename T:: const_iterator’ [-fpermissive] ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:708:49: error: to refer to a type member of a template parameter, use ‘typename T:: const_iterator’ [-fpermissive] ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp: In function ‘std::pair<double, double> boost::svg::range_all(const T&)’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:720:37: error: ‘numeric_limits’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:720:37: note: suggested alternatives: In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/limits.hpp:19:0, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/iterator/iterator_concepts.hpp:26, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/range/concepts.hpp:20, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/range/algorithm/equal.hpp:14, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/range/iterator_range_core.hpp:29, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/range/iterator_range.hpp:13, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/ptr_container/ptr_map_adapter.hpp:23, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/ptr_container/ptr_map.hpp:20, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/ptr_container/ptr_container.hpp:22, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/svg_tag.hpp:22, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg.hpp:184, from tests/plotting_tests.cpp:20: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/limits:304:12: note: ‘std::numeric_limits’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/limits:304:12: note: ‘std::numeric_limits’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/limits:304:12: note: ‘std::numeric_limits’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/limits:304:12: note: ‘std::numeric_limits’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/limits:304:12: note: ‘std::numeric_limits’ In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:37:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:720:52: error: expected primary-expression before ‘double’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:720:52: error: expected ‘)’ before ‘double’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:721:8: error: need ‘typename’ before ‘T:: const_iterator’ because ‘T’ is a dependent scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:721:26: error: expected ‘;’ before ‘it’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:721:51: error: ‘it’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:723:5: error: ‘pair’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:723:5: note: suggested alternatives: In file included from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_algobase.h:65:0, from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_tree.h:63, from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/map:60, from tests/plotting_tests.cpp:10: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_pair.h:88:12: note: ‘std::pair’ In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/mpl/iter_fold_if.hpp:23:0, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/mpl/find_if.hpp:19, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/mpl/find.hpp:17, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/mpl/aux_/contains_impl.hpp:20, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/mpl/contains.hpp:20, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/math/policies/policy.hpp:10, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/math/special_functions/math_fwd.hpp:28, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/math/special_functions/fpclassify.hpp:19, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/numeric_limits_handling.hpp:22, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/axis_plot_frame.hpp:22, from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:34, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/mpl/pair.hpp:28:8: note: ‘boost::mpl::pair’ In file included from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_algobase.h:65:0, from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_tree.h:63, from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/map:60, from tests/plotting_tests.cpp:10: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_pair.h:88:12: note: ‘std::pair’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_pair.h:88:12: note: ‘std::pair’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_pair.h:88:12: note: ‘std::pair’ /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_pair.h:88:12: note: ‘std::pair’ In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:37:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:723:10: error: expected primary-expression before ‘double’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:723:10: error: expected ‘;’ before ‘double’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/auto_axes.hpp:724:31: error: ‘mm’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: At global scope: In file included from tests/plotting_tests.cpp:21:0: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:73:12: warning: class ‘boost::svg::svg_2d_plot_series’ is implicitly friends with itself [enabled by default] ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:78:45: error: ‘series_’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:78:45: error: template argument 1 is invalid ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:78:33: error: template argument 2 is invalid ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:78:33: error: template argument 4 is invalid ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: In constructor ‘boost::svg::svg_2d_plot_series::svg_2d_plot_series(T, T, std::string)’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:153:41: error: ‘temp’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:153:49: error: an assignment cannot appear in a constant-expression ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:153:49: error: template argument 1 is invalid ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:153:29: error: template argument 2 is invalid ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:163:9: error: ‘series_’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: In member function ‘int boost::svg::svg_2d_plot_series::values_count()’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:319:12: error: ‘series_’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: At global scope: In file included from tests/plotting_tests.cpp:21:0: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:2266:95: error: ‘pair_double_2d_convert’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:2266:95: note: suggested alternative: In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:36:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:52:7: note: ‘boost::svg::detail::pair_double_2d_convert’ In file included from tests/plotting_tests.cpp:21:0: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:2270:105: error: ‘pair_double_2d_convert’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:2270:105: note: suggested alternative: In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:36:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/detail/functors.hpp:52:7: note: ‘boost::svg::detail::pair_double_2d_convert’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: In member function ‘void boost::svg::svg_2d_plot::draw_straight_lines(const boost::svg::svg_2d_plot_series&)’: In file included from tests/plotting_tests.cpp:21:0: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1621:19: error: ‘const class boost::svg::svg_2d_plot_series’ has no member named ‘series_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1623:48: error: ‘::const_iterator’ has not been declared ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1623:90: error: template argument 1 is invalid ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1623:37: error: template argument 2 is invalid ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1623:37: error: template argument 4 is invalid ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1629:34: error: ‘j’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1655:29: error: ‘const class boost::svg::svg_2d_plot_series’ has no member named ‘series_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: In member function ‘void boost::svg::svg_2d_plot::draw_bezier_lines(const boost::svg::svg_2d_plot_series&)’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1700:19: error: ‘const class boost::svg::svg_2d_plot_series’ has no member named ‘series_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1702:80: error: ‘const class boost::svg::svg_2d_plot_series’ has no member named ‘series_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1723:32: error: ‘const class boost::svg::svg_2d_plot_series’ has no member named ‘series_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: In member function ‘void boost::svg::svg_2d_plot::draw_plot_points()’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1788:87: error: ‘class boost::svg::svg_2d_plot_series’ has no member named ‘series_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1789:31: error: ‘class boost::svg::svg_2d_plot_series’ has no member named ‘series_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: In member function ‘void boost::svg::svg_2d_plot::draw_bars()’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1929:87: error: ‘class boost::svg::svg_2d_plot_series’ has no member named ‘series_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:1930:31: error: ‘class boost::svg::svg_2d_plot_series’ has no member named ‘series_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: In member function ‘void boost::svg::svg_2d_plot::draw_histogram()’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:2020:86: error: ‘class boost::svg::svg_2d_plot_series’ has no member named ‘series_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:2028:87: error: ‘class boost::svg::svg_2d_plot_series’ has no member named ‘series_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: In member function ‘boost::svg::svg_2d_plot& boost::svg::svg_2d_plot::y_autoscale(const T&, const T&)’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:2709:9: error: expected ‘)’ before ‘y_include_zero_’ ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: In member function ‘boost::svg::svg_2d_plot_series& boost::svg::svg_2d_plot::plot(const T&, const string&, U)’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:3183:22: error: ‘series_’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: In member function ‘boost::svg::svg_2d_plot_series& boost::svg::svg_2d_plot::plot(const T&, const T&, const string&)’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:3199:25: error: expected primary-expression before ‘(’ token ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:3200:67: error: missing template arguments before ‘(’ token ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:3201:65: error: missing template arguments before ‘(’ token ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:3204:22: error: ‘series_’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp: In member function ‘boost::svg::svg_2d_plot_series& boost::svg::svg_2d_plot::plot(const T&, const T&, const string&, U)’: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:3215:38: error: ‘container’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:3219:22: error: ‘series_’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/show_2d_settings.hpp: In function ‘void boost::svg::outFmtFlags(std::ios_base::fmtflags, std::ostream&, const char*)’: In file included from tests/plotting_tests.cpp:22:0: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/show_2d_settings.hpp:71:15: error: invalid conversion from ‘int’ to ‘std::ios_base::fmtflags {aka std::_Ios_Fmtflags}’ [-fpermissive] ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/show_2d_settings.hpp:94:17: error: invalid conversion from ‘int’ to ‘std::ios_base::fmtflags {aka std::_Ios_Fmtflags}’ [-fpermissive] In file included from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ios:43:0, from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:40, from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:40, from tests/plotting_tests.cpp:14: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/ios_base.h:564:5: error: initializing argument 1 of ‘std::ios_base::fmtflags std::ios_base::flags(std::ios_base::fmtflags)’ [-fpermissive] ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/show_2d_settings.hpp: In function ‘void boost::svg::show_2d_plot_settings(boost::svg::svg_2d_plot&)’: In file included from tests/plotting_tests.cpp:22:0: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/show_2d_settings.hpp:195:51: error: invalid conversion from ‘int’ to ‘std::ios_base::fmtflags {aka std::_Ios_Fmtflags}’ [-fpermissive] ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/show_2d_settings.hpp:61:6: error: initializing argument 1 of ‘void boost::svg::outFmtFlags(std::ios_base::fmtflags, std::ostream&, const char*)’ [-fpermissive] ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/show_2d_settings.hpp:307:20: error: invalid conversion from ‘int’ to ‘std::ios_base::fmtflags {aka std::_Ios_Fmtflags}’ [-fpermissive] In file included from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ios:43:0, from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:40, from /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:40, from tests/plotting_tests.cpp:14: /home/roger/Software/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/ios_base.h:564:5: error: initializing argument 1 of ‘std::ios_base::fmtflags std::ios_base::flags(std::ios_base::fmtflags)’ [-fpermissive] tests/plotting_tests.cpp: In function ‘void test1()’: tests/plotting_tests.cpp:168:16: error: ‘data1’ was not declared in this scope tests/plotting_tests.cpp:169:16: error: ‘data2’ was not declared in this scope ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp: In instantiation of ‘std::ostream& boost::svg::operator<<(std::ostream&, const boost::svg::unc<correlated>&) [with bool correlated = false; std::ostream = std::basic_ostream<char>]’: In file included from ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/svg_2d_plot.hpp:32:0, from tests/plotting_tests.cpp:21: ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:267:73: required from here ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:123:10: error: ‘double boost::svg::unc<false>::value_’ is private ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:237:3: error: within this context ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:124:9: error: ‘float boost::svg::unc<false>::uncertainty_’ is private ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:238:3: error: within this context ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:124:9: error: ‘float boost::svg::unc<false>::uncertainty_’ is private ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:241:5: error: within this context ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:127:18: error: ‘short unsigned int boost::svg::unc<false>::deg_free_’ is private ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:254:3: error: within this context ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:127:18: error: ‘short unsigned int boost::svg::unc<false>::deg_free_’ is private ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:256:5: error: within this context ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:135:18: error: ‘short unsigned int boost::svg::unc<false>::types_’ is private ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:259:3: error: within this context ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:135:18: error: ‘short unsigned int boost::svg::unc<false>::types_’ is private ../../testing-grounds/divcon-support_libs/local/r.linux-x86_64.gcc-shared/include/boost/svg_plot/uncertain.hpp:261:5: error: within this context gmake[1]: *** [build/Release/GNU-4.7-Linux-x86/tests/tests/plotting_tests.o] Error 1 gmake[1]: Leaving directory `/home/roger/NetBeansProjects/JPRoothaan' gmake: *** [.build-tests-impl] Error 2

4 4

Re: [boost] What to do with platform defining 'null' as preprocessor symbol?
by Stewart, Robert 24 Aug '12

24 Aug '12

Jan Hudec wrote: > > At work we develop, among others, for Bada. The system > library provided is unfortunately somewhat flaky. A tell-tale > sign is, that it's native API headers define lowercase 'null' > as preprocessor symbol expanding to 0. Another one, huh? Did they learn that trick from Microsoft? > Unfortunately boost uses identifier 'null'. [snip] > Would it make sense to rename those identifiers and avoid > that name like boost avoids 'min' and 'max'? Boost doesn't avoid "min" and "max" but encloses them in parentheses to prevent preprocessor expansion. "null" could be treated similarly, though some may prefer to choose a different identifier. (At least there isn't an algorithm named "null"!) You'll need to find all the places where "null" occurs and file Trac tickets to get things fixed. If you supply patches against trunk, they are more likely to be applied. If you can apply the patches and run the tests yourself against several compilers on different platforms, you could send a summary reply to this thread with the Trac issues and the results of your testing. Then, someone might even submit all of your patches in one go. _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

11 17

Announce: Boost 1.51 installer for 32/64-bit Windows now available
by John Wiegley 24 Aug '12

24 Aug '12

BoostPro is happy to announce that we now have free 32-bit and 64-bit installers for Windows available for download: http://www.boostpro.com/download This version libraries and/or DLLs for the following compilers: Visual C++ 7.1 (Visual Studio 2003) [32-bit only] Visual C++ 8.0 (Visual Studio 2005 SP1) Visual C++ 9.0 (Visual Studio 2008 SP1) Visual C++ 10.0 (Visual Studio 2010 SP1) -- John Wiegley BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

2 2

Sequence Printer (usually part or all of a container) using type_erasure
by Paul A. Bristow 24 Aug '12

24 Aug '12

With the recent acceptance of type erasure as a Boost library, I have continued experiments with the sequence printer provided as an example by Steven Watanbe. This seems to me to have very general usefulness, providing a way of safely, neatly and painlessly printing the contents of a container of any type. To give a flavour of what can be done, given some items in a container, one can print the whole container: double da[] = {1., 2., 3., 4., 5., 6., 7., 8., 9., 10., 11., 12. }; decor_printer line_printer; // Using all decor_printer defaults. line_printer.print(da, std::cout); // "1 2 3 4 5 6 7 8 9 10 11 12" // Prints all on one line, space separator and newline at the end. Instead of providing several printer types (as Steven did), I have concentrated just one printer class decor_printer derived from his abstract printer. But I have added to it several constructor parameters to control the number of columns, the width of the columns, and string to prefix, separate, suffix and final terminator. // Construct a printer for 3 ragged columns, and comma as separator. decor_printer plain_printer(3, 0, "\n", ", ", "\n", "\n"); plain_printer.print(da, std::cout); which outputs: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 We can also apply this to std::vector (and all the other STL container types) and a more complex type like quantity<length, measurement<double> > (where there is a measurement value and estimate of its uncertainty (+/-). // Array of Boost.Units quantity with an uncertain type. quantity<length, measurement<double> > q[] = { measurement<double>(45210.0, 1234.0) * meters, measurement<double>(765.3, 2.5) * meters, measurement<double>(12.34, 12.5) * meters, measurement<double>(5.67, 2.5) * meters, measurement<double>(0.789, 2.7e-2) * meters, measurement<double>(7890, 2.5e-2) * meters, measurement<double>(5.78e-4, 2.5e-4) * meters, measurement<double>(765.3, 2.5) * meters, measurement<double>(0.0789, 2.7e-4) * meters, measurement<double>(7890, 2.5e-1) * meters, measurement<double>(5.78e-7, 2.5e-8) * meters, measurement<double>(76.3, 2.5) * meters, measurement<double>(53.8e6, 2.34e5) * meters }; To list this neatly we may need a column width of 25. decor_ printer fancy_printer(4, 25, "\n", ", ", "\n"); // 4 columns, 25 char wide fancy_printer.print(q, std::cout); which outputs: 45.21(+/-1.234) km, 765.3(+/-2.5) m, 12.34(+/-12.5) m, 5.67(+/-2.5) m, 789(+/-27) mm, 7.89(+/-2.5e-005) km, 578(+/-250) um, 765.3(+/-2.5) m, 78.9(+/-0.27) mm, 7.89(+/-0.00025) km, 578(+/-25) nm, 76.3(+/-2.5) m, 53.8(+/-0.234) Mm (Unless the email destroys the layout L ) Note the cool autoprefixing of quantities so the units change from m to km, mm, Mm as appropriate. Finally, the parameter to the printer is a *range*, so *part* of any container can nearly as easily be printed. Does anyone share my enthusiasm for this? Paul PS I have also re-ordered the abstract_printer parameters in the hope of providing std::cout as default, so one can write just line_printer.print(da); // "1 2 3 4 5 6" But so far I can't get it to find the charT and traits parameters, despite providing defaults. Two files attached (and need the sandbox version of type erase library. Can anyone more expert get this to work? --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

1 0

[config] NO_USER_DEFINED_LITERALS ?
by Matus Chochlik 24 Aug '12

24 Aug '12

Hello, does Boost.Config provide some macro for the detection of (un)availability of user-defined literals (N2765) ? I could not find any in the docs for 1.51.0 nor by grepping in the boost/config/* files. If not, would there be a big problem adding it (called for example BOOST_NO_USER_DEFINED_LITERALS), please ? Thanks in advance, Best regards, Matus

2 2

Equivalent of "bootstrap.sh --without-libraries" for Modularized and CMake-ified boost
by Julien Woillez 24 Aug '12

24 Aug '12

Dear boost(a)lists.boost.org, I'm trying to use CMake to build boost, using its Modularized and CMake-ified version at: https://github.com/ryppl/boost-zero I need to do the equivalent of --without-libraries=mpi with bootstrap.sh. Any idea if this is possible, and if so how to do it? Regards, -Julien

2 1

[type_erasure]bug:any(, binding<Concept>) can store wrong type
by Larry Evans 23 Aug '12

23 Aug '12

The attached runs OK without any compile or runtime errors. It seems to create a type_uns<1> from a type_uns<0> although there's no type_uns<1> CTOR for that. This sounds like another instance of the bug reported here: http://article.gmane.org/gmane.comp.lib.boost.devel/233101 Is it? -regards, Larry

2 6

[exception] is static only?
by Neal Becker 23 Aug '12

23 Aug '12

Is it necessary that exception builds only static libs? On many architectures, this would limit it's usefulness.

3 5

Boost 1.51.0 released!
by Marshall Clow 22 Aug '12

22 Aug '12

Release 1.51.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains 1 new library (Boost.Context, by Oliver Kowalke) and numerous enhancements and bug fixes for existing libraries. For details, including download links, see http://www.boost.org/users/news/version_1_51_0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.51.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team Beman Dawes Daniel James Eric Niebler Marshall Clow Rene Rivera Vladimir Prus

8 18

[1.51] PDF documentation build available
by John Maddock 22 Aug '12

22 Aug '12

The PDF build of the docs for 1.51 is now available from: https://sourceforge.net/projects/boost/files/boost-docs/1.51.0/ John.

1 0

[type_erasure] Review report -- ACCEPTED
by Lorenzo Caminiti 21 Aug '12

21 Aug '12

Hello all, Steven Watanabe's library Boost.TypeErasure is ACCEPTED into Boost. SUMMARY The library was reviewed from July 18 to August 3, 2012. There were 11 votes to accept the library and 2 votes to accept the library under the condition of some modifications (at the end, these 2 votes were essentially considered as "no" because there was no agreement on implementing all the required modifications). It was noted how the library offers non-intrusive and powerful programming techniques that can be used in place of usual Object Oriented (pure) virtual function interfaces (and with support for some from of virtual "template" functions). The library can also be seen as a generalization of existing Boost libraries like Any, Function, and AnyIterator. The library is accepted "as is", however most reviewers suggested to: 1) Dramatically ease the learning curve of the documentation by providing a motivation section, step-by-step tutorial(s) to introduce the basic features of the library, advanced topics section(s) to introduced the additional features, an example section with non-trivial use cases for the library, and additional examples to the reference section. 2) Support down-casting. While these changes are not a condition for the library acceptance, it would be best if they were made part of the very first release of the library. A few reviewers found the name Type Erasure confusing, however others did not. Alternative name were: Staged Typing, Deferred Typing, Type Interface, Interface, Static Interface, Value Interface, Structural Typing, Duck Typing, and Run-Time Concepts. There was some discussion on the meaning of Type Erasure in Java and on its definition on wiki (these should probably be both referenced in the documentation). The current library name is considered acceptable and the final decision on the library name is left entirely up to Steven. DETAILS "Yes" reviews: [1] http://lists.boost.org/Archives/boost/2012/07/195288.php [2] http://lists.boost.org/Archives/boost/2012/07/195297.php [3] http://lists.boost.org/Archives/boost/2012/07/195299.php [4] http://lists.boost.org/Archives/boost/2012/07/195308.php [5] http://lists.boost.org/Archives/boost/2012/07/195323.php [6] http://www.mentby.com/hossein-haeri/boost-typeerasure-review-ends-today-jul… [7] http://lists.boost.org/Archives/boost/2012/07/195327.php [8] http://lists.boost.org/Archives/boost/2012/07/195329.php [9] http://lists.boost.org/Archives/boost/2012/07/195334.php [10] http://lists.boost.org/Archives/boost/2012/07/195364.php [11] http://lists.boost.org/Archives/boost/2012/08/195420.php "Conditional-yes" reviews (essentially considered as "no"): [12] http://lists.boost.org/Archives/boost/2012/08/195455.php [13] http://lists.boost.org/Archives/boost/2012/08/195561.php Notable comments and discussions (not reviews): (1) http://lists.boost.org/Archives/boost/2012/07/195162.php (2) http://lists.boost.org/Archives/boost/2012/07/195130.php (3) http://lists.boost.org/Archives/boost/2012/07/195149.php (4) http://lists.boost.org/Archives/boost/2012/07/195167.php (5) http://lists.boost.org/Archives/boost/2012/07/195199.php (6) http://lists.boost.org/Archives/boost/2012/07/195200.php (7) http://lists.boost.org/Archives/boost/2012/07/195232.php (8) http://lists.boost.org/Archives/boost/2012/07/195234.php (9) http://lists.boost.org/Archives/boost/2012/07/195408.php (10) http://permalink.gmane.org/gmane.comp.lib.boost.user/75081 (11) http://lists.boost.org/Archives/boost/2012/08/195590.php (12) http://lists.boost.org/Archives/boost/2012/08/195663.php (13) http://lists.boost.org/Archives/boost/2012/07/195342.php (14) http://lists.boost.org/Archives/boost/2012/08/195543.php Note that Steven might have already implemented some of the changes listed below. Features: * Support down-casting. See [1], [10], and (4). * Add macros for defining concepts. These macros could be added in later revisions (they just provide a different syntax, no additional functionality). ** From [10]: BOOST_CREATE_CONCEPT(container_concept, typename T, (void (push_back, T), void (size)) ) ** From Steven: BOOST_TYPE_ERASURE_MEMBERS((push_back)(size)...) template<class V, class T = _self> struct container_concept : mpl::vector< has_push_back<void(const V&), T>, has_size<std::size_t(), const T>, ...> {}; * Add empty() to check if any holds a value or not. See [3] and [11]. * Add a built-in concept for unary plus +x (just pick a name for it). See (11). Implementation: * Can assertion enforce that same bindings are required for the placeholders? See [13] and (3). * Add assertion to check that in functions with multiple arguments the underlining any types must match. See (7). * Add in-code comments to the implementation (at least to normalize.hpp). See [8] and [13]. * Can static assertions be used to improve error messages (see [8])? Concept mismatch spew errors with internal implementation details, see [10]. * Fix bugs: ** http://lists.boost.org/Archives/boost/2012/07/195367.php ** http://lists.boost.org/Archives/boost/2012/07/195396.php ** http://lists.boost.org/Archives/boost/2012/08/195662.php Documentation: * A few typos listed in [9]. * A draft on a proposed way to restructure the docs was offered in [8]. * Sean Parent's BoostCon 2012 "Value Semantics" could be used to write a motivation section. See [9]. * Offer a comparison with usual OO (pure) virtual function interfaces. See [1], [7], [8], and [9]. * Make sure all important elements document in the reference section are also documented in a tutorial section (e.g., how the any constructor binds placeholders, conversions, BOOST_TYPE_ERASURE_MEMBER, concept_of, etc). See (1), (4), (6), and [1]. * Clarify that references can be assigned but they cannot be rebound to a different object. See (2). * Clarify the rationale for using _a, _b, ... instead of _1, _2, ... as soon as _a, _b, ... are first used (most users miss the "named vs. positional parameter" rationale from the design decision section and _1, _2, ... are such common constructs that many users will naturally question the _a, _b, ... choice). See (5). * Add an example section with non-trivial use cases of the library. Consider to add the following examples: ** How to implement visitation, see (8). ** Model view controller, see [1]. ** Run-time expression system (adding Concept = void specialization), see [3]. ** Multi-function, see [4]. ** Printing, see (11) (note that Steven needed to answer too many questions for Paul to be able to program this, ideally the docs would have been clear enough for Paul to program this example without Steven's help). ** Reference related work Adobe::Poly, see (13). * Document all built-in concepts (possibly with a usage example for each) and indicate which ones can be specialized. See [5], and [9]. * Add an example at the bottom of each reference page. See [11]. * Document that any(any<Concpet2, T2>, binding<Concept>) allows to convert the vtable once and re-use it for all anys reducing run-time cost. See [12]. * Consider a number of docs improvements as suggested in [13]. * Document the undefined behaviour pointed out in (12). * Document limitations that some algorithms might encounter if they need to access references and provide rationale of why references cannot be handled differently (i.e., constructor flag and/or overhead of managing vtable in dispatcher layer). See [12], and (14). Many thanks to everyone that participated in the review!! I believe Boost users will find this library useful. The review manager, --Lorenzo On Sat, Aug 4, 2012 at 12:32 PM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> wrote: > Hello all, > > The review of Boost.TypeErasure ended on Aug 3, 2012. Stay tuned for > my decision on the library. > > Thank you very much to Steven, everyone that submitted a review, and > everyone that participated in the discussions. > > The review manager, > --Lorenzo > > On Fri, Aug 3, 2012 at 11:00 AM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> wrote: >> Hello all, >> >> *** The review of Boost.TypeErasure ends today Aug 3, 2012. If you are >> planning to submit a review, please do so by the end of today. *** >> >> Thank you to all that have participated to the review so far. >> >> The review manager, >> --Lorenzo >> >> On Jul 27, 2012 1:41 PM, "Lorenzo Caminiti" <lorcaminiti(a)gmail.com> wrote: >>> >>> Hello all, >>> >>> After consulting the review wizards and Steven, I am extending >>> Boost.TypeErasure review of one week, until August 3, 2012. >>> >>> Thank you to all that have submitted a review already and I am looking >>> forward to receiving additional submissions. >>> >>> The review manager, >>> --Lorenzo >>> >>> On Jul 27, 2012 3:22 AM, "Lorenzo Caminiti" <lorcaminiti(a)gmail.com> wrote: >>>> >>>> Hello all, >>>> >>>> On Mon, Jul 23, 2012 at 9:09 AM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> >>>> wrote: >>>> > On Wed, Jul 18, 2012 at 1:13 AM, Lorenzo Caminiti >>>> > <lorcaminiti(a)gmail.com> wrote: >>>> >> *** The review of Steven Watanabe's proposed Boost.TypeErasure library >>>> >> begins on July 18, 2012 and ends on July 27, 2012. *** >>>> > >>>> > *** Boost.TypeErasure review ends in 5 days. Please submit your reviews >>>> > :D *** >>>> >>>> *** Boost.TypeErasure review ends today July 27, 2012. If you are >>>> planning to submit a review, please do so as soon as possible. *** >>>> >>>> Thank you to everyone who has commented on the library and submitted a >>>> review so far! >>>> >>>> The review manager, >>>> --Lorenzo >>>> P.S. I am considering extending the review until end of day Sunday >>>> July 29, 2012... I will keep you posted. >>>> >>>> > There have been interesting discussions on the library on the ML but I >>>> > have not received any official review yet :( Especially if you are a >>>> > user of Boost Any, Function, and Any Iterator, you definitely want to >>>> > take a look at Type Erasure as it generalizes solutions provided by >>>> > those other libraries. >>>> > >>>> > Thank you. >>>> > >>>> > The review manager. >>>> > --Lorenzo >>>> > >>>> >> THE LIBRARY >>>> >> >>>> >> C++ provides runtime polymorphism through virtual functions. They are >>>> >> a very useful feature, but they do have some limitations. >>>> >> * They are intrusive. In generic programming, we can design an >>>> >> interface which allows third-party types to be adapted to it. >>>> >> * They require dynamic memory management. Of course, most of the >>>> >> problems can be avoided by using an appropriate smart pointer type. >>>> >> Even so, it still acts like a pointer rather than a value. >>>> >> * Virtual functions' ability to apply multiple independent concepts to >>>> >> a single object is limited. >>>> >> The Boost.TypeErasure library solves these problems allowing us to >>>> >> mirror static generic programming at runtime. >>>> >> >>>> >> Library source: >>>> >> http://svn.boost.org/svn/boost/sandbox/type_erasure/ >>>> >> >>>> >> Pre-built documentation: >>>> >> >>>> >> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/ >>>> >> >>>> >> You can also download archives with pre-built documentation from: >>>> >> http://sourceforge.net/projects/steven-watanabe.u/files/ >>>> >> >>>> >> YOUR REVIEW >>>> >> >>>> >> Please submit a review to the mailing-list by replying to this email >>>> >> ("[boost] [type_erasure] Review ..." should be in the subject). >>>> >> >>>> >> Please state clearly whether you think this library should be accepted >>>> >> as a Boost library. >>>> >> >>>> >> Other questions you may want to consider: >>>> >> 1. What is your evaluation of the design? >>>> >> 2. What is your evaluation of the implementation? >>>> >> 3. What is your evaluation of the documentation? >>>> >> 4. What is your evaluation of the potential usefulness of the library? >>>> >> 5. Did you try to use the library? With what compiler? Did you have >>>> >> any problems? >>>> >> 6. How much effort did you put into your evaluation? A glance? A >>>> >> quick reading? In-depth study? >>>> >> 7. Are you knowledgeable about the problem domain? >>>> >> >>>> >> Thanks in advance to all who participate in the review discussion -- >>>> >> I'm looking forward to it!

3 2

[fusion] move-enabled containers?
by Gabriel Redner 21 Aug '12

21 Aug '12

Hi folks, I have been starting to ease into C++11, and am currently looking to add move-awareness to some classes which have members of boost::fusion container types. However, it seems that fusion containers are not move-aware. For a minimal example, take the code below: ========== #include <boost/fusion/include/vector.hpp> #include <iostream> class noisy { public: noisy() { std::cout << "noisy()\n"; } noisy(const noisy&) { std::cout << "noisy(const noisy&)\n"; } noisy(noisy&&) { std::cout << "noisy(noisy&&)\n"; } }; int main() { typedef boost::fusion::vector<noisy, noisy> noisyVector; noisyVector n; std::cout << '\n'; noisyVector n2(n); std::cout << '\n'; noisyVector n3(std::move(n)); } ========== I was hoping that the output would be: ========== noisy() noisy() noisy(const noisy&) noisy(const noisy&) noisy(noisy&&) noisy(noisy&&) ========== But instead I get: ========== noisy() noisy() noisy(const noisy&) noisy(const noisy&) noisy(const noisy&) noisy(const noisy&) ========== It is a simple matter to add move-awareness to fusion containers, or is there some technical reason why it cannot been done? Or (perhaps more likely), am I misunderstanding something about the situation? Thanks, -Gabe

4 5

Some library dependency and auto liker issues
by Vicente J. Botet Escriba 20 Aug '12

20 Aug '12

Hi, there is an issue https://svn.boost.org/trac/boost/ticket/7045 that I don't know how to fix. The problem is related to library dependencies and auto-linker. * 1st issue: Boost.Threads depends on Boost.DateTime but only for the header only part. Anyway, it includes a DateTime file that includes the boost/config/auto_link.hpp, and this makes the tools using the auto linker to create a dependency on Boost.DateTime. As the Boost.Threads build Jamfile doesn't link with Boost.DateTime, the command bjam toolset=msvc-11.0 --build-type=complete --with-thread doesn't build the library Boost.DateTime and so when a tool such as Visual studio uses the auto linker information, it tries to link with Boost.DateTime and not finds it, as not build (even if it is not needed). What is the best way to fix this? Should Boost.Thread link with Boost.DateTime, even if it don't needs it? Or just document that the user relaying on auto-linker needs to build explicitly the boost_date_time library with the command: bjam toolset=msvc-11.0 --build-type=complete --with-thread --with-date_time * 2nd issue: Boost.Threads depends on Boost.Chrono and the library is linked with boost_chrono. When a user includes for example <boost/thread/tss.hpp> the autolinker doesn't detects the chrono dependency as this file don't depends on any file in boost/chrono. But as boost_thread depends on boost_chrono, the linker find some unresolved symbols. What is the best way to fix this? Should Boost.Thread include boost/chrono.hpp in all their public files even if not needed other than by auto linker tools? Or just document that the user relaying on auto-linker needs to include only the top level file <boost/thread.hpp> so that all the dependencies are covered? Any suggestions are welcome, Vicente

2 5

Re: [boost] [type_erasure] Review started (July 18-27, 2012)
by Steven Watanabe 20 Aug '12

20 Aug '12

AMDG On 08/02/2012 12:29 PM, Larry Evans wrote: > On 07/18/12 00:13, Lorenzo Caminiti wrote: >> Hello all, >> >> *** The review of Steven Watanabe's proposed Boost.TypeErasure library >> begins on July 18, 2012 and ends on July 27, 2012. *** > [snip] > Should type_erasure be accepted into Boost? > > Answer: > No, not yet. > Why(in order of importance): > > 1) any<C,T>::any(U&, static_binding<Map>&) bug > > The bug reported here: > http://article.gmane.org/gmane.comp.lib.boost.devel/233101 > should be resolved. > > The bug is just too dangerous for the resolution to be delayed. > I added a static assert. > <snip> > > My review: > > 1. What is your evaluation of the design? > > Good, except for: > > [need variadic static_binding ctor]: > > The any CTOR: > > template<class U, class Map> > any(U & arg, const static_binding< Map > & binding); > > documented here: > > > http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… > > allows only a single argument to the constructor to the > underlying type. I'd suggest adding another CTOR with > interface: > > template<class Map, class... U> > explicit any(const static_binding< Map > & binding, U &&... arg); > > which is similar to: > > explicit any(const binding< Concept > & binding, U &&... arg); > > Then any constructor of the underlying could be used. > I think something like this is reasonable. I have to consider whether this is best approach, though. I don't consider this high priority, however, since the copy constructor should work most of the time. The STL got by just fine for years without emplace. > [too many any ctors]: > > According to `grep -e ' any('`, there are more than 45 any > constructors. That many makes it hard for the novice to know > which one to use. The Design notes: > The solution is simple. Don't use the source. Use the documentation page for any, which only shows 9 distinct constructors. > > http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… > > are some help, but those notes also mention ambiguities and > user rules, which sound like indications of usability problems > to me. > > Why wouldn't the following ctors be sufficent to do all the > current any constructors do (except for maybe requiring more > typing and maybe more constructor calls)? > > template > < class... U > > > any > ( static_binding<Map>const& > , U&&... > );//kind=binding constructor > > template > < class... U > > > any > ( binding<Concept>const& > , U&&... > );//kind=dispatching constructor > > template > < class Concept2 > , class Tag2 > > > any > ( any<Concept2,Tag2>U&& > , static_binding<Map>const& > );//kind=converting constructor > > template > < class Concept2 > , class Tag2 > > > any > ( any<Concept2,Tag2>U&& u > , binding<Concept2>const&b=binding_of(u) > );//kind=converting constructor > > Providing just these 4 constructors would improve the usabilty. Why? > Of course, I'm probably missing something, and if so, > explaining why the above would not work in the Design notes > would be helpful. > I think it should be obvious what's missing: a) any(const any&); The copy constructor is not a template. b) template<class U> any(const U&); This is the most commonly used constructor besides the copy constructor. It would be very inconvenient if it didn't exist. c) any(); The default constructor creates an empty any. d) A default argument can't refer to a prior argument. Your fourth constructor has to be two separate constructors. > 2. What is your evaluation of the implementation? > > [in-source comments]: > Very few in-source comments, as for example, the in the code: > > > http://steven_watanabe.users.sourceforge.net/type_erasure/boost/type_erasur… > > there are no in-source comments. This lack of in-source comments > made it very hard to understand the implementation. There is also > no tests in the directory: > > > > http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… > > which contain any string with 'normalize' in it; hence, I assume > there are no unit tests for any class or function with normalize > as part of its name. Such unit tests, hopefully, would have > provided more information of the purpose of the code in > */detail/normalize.hpp; hence, I'd recommend providing such tests > in addition to more in-source comments. > The tests only cover the public interface. I'm not going to add specific tests of the implementation details. > > 3. What is your evaluation of the documentation? > > Mostly good, but some documentation needs improvement. > For example: > > [vague:rebinding_any.html]: > > This doc: > > > http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… > > Claims rebind_any<Any,T>::type: > > returns any type corresponding to a placeholder. > > However, it doesn't say what the Any in rebind_any<Any,T> may be, > and if one assumes Any is a type_erasure::any<C,S> for some > concept, C, and placeholder, S, then that description makes no > sense because C does not contain any information about which > actual type is matched to which placeholder. Huh? As the documentation you quoted says, rebind_any returns a specialization of /any/. rebind_any<any<C, S>, T>::type is any<C, T>. > <snip> > > from Steven, in the reply: > > http://article.gmane.org/gmane.comp.lib.boost.devel/233067 > > did I finally conclude: > > The placeholders in concepts do *not* stand for the bound types > but instead for the any's containing those bound types. > That depends on the context. boost::type_erasure::call "unwraps" these any's. > Which is similar to the conclusion which I posted here: > > http://article.gmane.org/gmane.comp.lib.boost.devel/233078 > > Since the 233078 post got no replies, I assume that conclusion is > right. If so, then that should be made clear in the > documentation (including tutorials). In addition, the following > example code (and especially the comments), should reduce future > confusion on this topic: > > /* {***any_ctor_kinds.cpp*** */ > <snip> > I find this code almost completely unreadable. > If that conclusion is wrong, then the docs need to be modified > (I've no idea how) to clearly define "matching" as used in the > any.html#id2445089-bb reference. > > [incomplete:tuple.html]: > > The doc: > > > http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… > > makes no mention of how the binding produced by this call are > generated. > Already fixed. In Christ, Steven Watanabe

10 24

[multiprecision] Some rvalue reference experiments (performance inhancements #1)
by John Maddock 20 Aug '12

20 Aug '12

Folks, I've started to work through some of the points that came up in the multiprecision review, starting with further rvalue reference support. The idea (due to Marc Glisse) was to add operator overloads that look something like: Number&& operator+(Number&&a, const Number& b) { return static_cast<Number&&>(a += b); } Using my Polynomial Horner evaluation scheme as an example the number of temporaries dropped as follows: Type # temporaries No expression templates, no rvalue refs 24 No expression templates, rvalue refs 1 Expression template 0 Which is pretty impressive, but not necessarily typical usage, so by way of "real world" tests, I compared the times taken to evaluate Boost.Math's Bessel function test cases to 50 decimal places: Library Time/s # Allocations MPFR/mpreal (no ET's or rvalue refs) 9.4 13226029 MPFR/mpfr_class (ET's) 6.3 3948316 MPFR/mp_number(ET's) 6.0 2683646 GMP/mp_number(no ET's) 5.2 4186977 GMP/mp_number(ET's) 5.0 2594441 As you can see the number of allocations required when using mp_number with ET's turned off is almost double that without, I guess this is because many statements are similar to: a = b op c; Where a temporary is still required when relying on rvalue refs, but not for expression templates. Having said that the times are getting much closer now.... John.

8 25

Is there any interest in getting pseudo random number generation using preprocessor at compile time into the Preprocessor library?
by Alexander Stoyan 20 Aug '12

20 Aug '12

The complete code, approach and efficiency proofs I described in my blog: http://alexander-stoyan.blogspot.com/2012/07/getting-pseudo-random-numbers-a t.html Need your opinion regarding the relevance and the approach correctness of the feature. Thank you in advance.

4 7

[1.51.0] release candidates available
by Marshall Clow 19 Aug '12

19 Aug '12

Release candidate files for 1.51.0 are available at http://boost.cowic.de/rc/ At this point, the release branch is closed for changes without explicit permission from the release managers. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: 6a1f32d902203ac70fbec78af95b3cf8 *boost_1_51_0_rc1.tar.gz 4b6bd483b692fd138aef84ed2c8eb679 *boost_1_51_0_rc1.tar.bz2 ee8112e48088b05c248d68329cd5d908 *boost_1_51_0_rc1.zip e87d3747966ab7e0c9487884326d7d17 *boost_1_51_0_rc1.7z Thanks, --The release managers

5 6

Modularized Boost: How the files in libs/libXX must be included?
by Vicente J. Botet Escriba 19 Aug '12

19 Aug '12

Hi, the following ticket https://svn.boost.org/trac/boost/ticket/7200 report an issue while building Boost.Thread using the modularized cmake. What is the correct way to include the files in lib/libXXX? Best, Vicente

2 1

[type_traits][parameter] Inconsistent boost::is_convertible between gcc and clang
by John Bytheway 19 Aug '12

19 Aug '12

I have been tracking down an issue with some of my code which compiles fine with gcc but not clang. It manifested as a failure in Boost.Parameter but I eventually pinned it down to an inconsistency in the behaviour of boost::is_convertible. The following program demonstrates the issue: ============== #include <boost/type_traits/is_convertible.hpp> #include <boost/static_assert.hpp> class A {}; int main() { BOOST_STATIC_ASSERT((boost::is_convertible<A, A&>::value)); } ============== This compiles fine under g++ (4.7.1), but the assertion fires under clang++ (r160940). This is not too surprising because is_convertible is implemented in completely different ways on the two compilers: - on clang it is in terms of the __is_convertible intrinsic, which behaves like std::is_convertible and fails because rvalue references don't convert to lvalue references. - on gcc it has a complex custom implementation which at some point performs add_reference<> on the first argument and thus determines that the conversion is OK. Reading the docs for boost::is_convertible I think the clang interpretation is closer to the intention, in which case the gcc implementation is wrong, and so is Boost.Parameter (which relies on this behaviour). On the other hand, I suspect there's probably other code out there that depends on this in a similar way to Boost.Parameter, so perhaps it would be safer to tweak the clang implementation instead, and deviate from std::is_convertible. Any thoughts? John Bytheway

5 13

[odeint] Iterator semantics
by Karsten Ahnert 19 Aug '12

19 Aug '12

Hi, we have posted a review request for odeint (a library for solving ordinary differential equations) on this list some days ago. An ODE is dx/dt = f(x(t)) and one is looking for the solution x(t) which is a function of t. Solving ODEs is usually an iterative task, so one starts with x(0) and iteratively applies a solver to obtain a discretized (and approximated) representation of the solution: x(0) -> x(dt) -> x(2*dt) -> x(3*dt) -> ... I played around with an iterator which is doing exactly this iterative procedure. For example, it can be used via odeint::runge_kutta4< state_type > stepper; // ode solver std::array< double , 3 > x = {{ 10.0 , 10.0 , 10.0 }}; // initial state double res = std::accumulate( // parameters : solver , ode , state , time , time_step make_const_step_iterator_begin(stepper, lorenz(), x, 0.0, 0.01) , make_const_step_iterator_end( stepper, lorenz(), x, 1.0, 0.01) , 0.0 , []( double sum, const state_type &x) { return sum + x[0]; } ); The first iterator increments the time until the time of the second iterator is rearched t=0.0 -> t=0.01 -> t=0.02 -> .. t=1.0 and the first component of the solution is accumulated. In principle, this approach works quite well, but there are some problems at least semantically. Maybe someone here has some comments or ideas on this: The defintion of this iterator is: template< class Stepper , class System , class StepperTag > class const_step_iterator : public boost::iterator_facade < const_step_iterator< Stepper , System , StepperTag > , typename Stepper::state_type const , boost::single_pass_traversal_tag > { ... }; It is a single pass iterator, so it can only check for equality of two iterators. This is problematic since equality here means that the time (t) of the begin iterator is smaller then the time of the end iterator. To ensure commutativity of the != or == operation I needed to flag the begin and end iterator explicitly. This is the reason for the two factory functions make_const_step_iterator_begin and make_const_step_iterator_end, which are doing this flagging. The second semantically problem is that the end iterator in principle does not need to know the stepper as well as the system (lorenz() in the above example). But all algorithms from the standard library and Boost.Range assume that the begin and end iterator are of same type. Therefore you have to put the stepper and the system into the end iterator too. Of course, there are techniques like type erasure which might solve this problem, but they introduce some run-time overhead which we want to avoid here. Any ideas or comments about this? P.S. The code can be found in the iterator branch in odeint: boost/numeric/odeint/iterator/const_step_iterator.hpp and some examples libs/numeric/odeint/examples/const_step_iterator.cpp git clone -b iterator git@github.com:headmyshoulder/odeint-v2.git

5 19

Request for a typedef for the larger integer type that supports atomic loads and stores.
by Vicente J. Botet Escriba 18 Aug '12

18 Aug '12

Hi, I'm locking for a portable integer type that is the larger integer type that supports atomic loads and stores. The sig_atomic_t type defined in <csignal> supports atomic loads and stores but I'm not sure is the larger one. Does boost define such a typedef? If not, could such typedef be included in boost and where? Best, Vicente

2 1

What to do with platform defining 'null' as preprocessor symbol?
by Jan Hudec 17 Aug '12

17 Aug '12

Hello Folks, At work we develop, among others, for Bada. The system library provided is unfortunately somewhat flaky. A tell-tale sign is, that it's native API headers define lowercase 'null' as preprocessor symbol expanding to 0. Unfortunately boost uses identifier 'null'. So far we only hit the two cases in boost/test/utils/basic_cstring/basic_cstring.hpp, where I fixed it by renaming the symbols in our local copy of that header, but I noticed there are many more instances in other modules. Would it make sense to rename those identifiers and avoid that name like boost avoids 'min' and 'max'? Or perhaps I could try simply undefining it in config/platform somewhere and see whether Bada headers would break? Unfortunately I don't think gcc has ability to redefine macros temporarily to reinstate the original definition at the end of boost. Generally speaking, Bada provides it's own native API, which is different from anything else. It's object-oriented and looks nice at first sight, but sometimes is inflexible in surprising places. It looks like they wrote whatever they needed to implement applications that ship with the phones and stopped there. The platform also provides ANSI C library and some parts of POSIX, but many functions don't really work. Fortunately the platform is going to be merged with Titzen, so it should at least get working POSIX kernel (Linux) and standard libraries. That makes supporting this obscure platform even less worth big trouble. -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

1 0

[general] Endianity detection for ARM
by Jan Hudec 17 Aug '12

17 Aug '12

Hello All, Something in Boost.Test started using detail/endian.hpp internally between 1.43 and 1.50. Since at work I build Boost.Test-based tests for several mobile platforms, all of which use ARM, I needed to fix it. It is easy for all platforms built with either gcc or clang (Android, iOS and Bada). Gcc defines __ARMEB__ for big-endian ARM and __ARMEL__ for little-endian ARM. Windows CE is however another issue. Microsoft usually defines rather characteristic _M_<arch> macros, but _M_ARM is *not* defined in Windows CE, though it appears to be defined for Windows 8 ARM (I don't work with those yet). The WinCE projects define ARM and _ARM_, but those may appear on big-endian ARM platforms too. However since there are no big-endian Win32 platforms and they are unlikely to be created, I suggest just hardcoding little endian for anything that defines _WIN32 (the _M_* macros could then possibly be removed, but they don't cause any problems there). I therefore propose this patch: --- a/boost/detail/endian.hpp +++ b/boost/detail/endian.hpp @@ -57,7 +57,7 @@ || defined(_POWER) || defined(__powerpc__) \ || defined(__ppc__) || defined(__hpux) || defined(__hppa) \ || defined(_MIPSEB) || defined(_POWER) \ - || defined(__s390__) + || defined(__s390__) || defined(__ARMEB__) # define BOOST_BIG_ENDIAN # define BOOST_BYTE_ORDER 4321 #elif defined(__i386__) || defined(__alpha__) \ @@ -66,7 +66,9 @@ || defined(_M_ALPHA) || defined(__amd64) \ || defined(__amd64__) || defined(_M_AMD64) \ || defined(__x86_64) || defined(__x86_64__) \ - || defined(_M_X64) || defined(__bfin__) + || defined(_M_X64) || defined(__bfin__) \ + || defined(__ARMEL__) \ + || defined(_WIN32) // ARM Windows CE don't define __ARMEL__ nor _M_ARM, but there are no big-endian Windows versions # define BOOST_LITTLE_ENDIAN # define BOOST_BYTE_ORDER 1234 -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

1 0

Boost.Units does not honor setw width?
by Paul A. Bristow 17 Aug '12

17 Aug '12

> -----Original Message----- > From: Paul A. Bristow [mailto:pbristow@hetp.u-net.com] > Sent: Thursday, August 09, 2012 4:44 PM > To: 'boost(a)lists.boost.org' > Subject: RE: [boost] [type_erasure] Review started (July 18-27, 2012) Flushed with success using Steven Watanabe's type_erase for printing columns, I have enjoyed extending it to use a fixed column width. But I have stumbled on a feature of Boost.Units output where Boost.Units does not honor the iostream width fully. This can be seen in this minimal example: std::cout << std::setw(20) << 'm' << std::endl; outputs 19 spaces and 'm', total 20 as expected. quantity<length> ql = 2345.6 * meters; std::cout << std::setw(20) << ql << std::endl; outputs 2345.6 m but the m does not line up with the previous 'm'. There are 14 leading spaces and 5 digits, 1 period and a space and letter m for the unit, a total of 22. The reason is that the first item value() is output using the ios width setting, but the second unit() 'm' (and separating space) is not, as in this line in io.hpp . os << q.value() << ' ' << Unit() I have 'cured' this 'bug' (I suspect it is a feature really) thus in boost/units/io.hpp template<class Char, class Traits, class Unit, class T> inline std::basic_ostream<Char, Traits>& operator<<(std::basic_ostream<Char, Traits>& os, const quantity<Unit, T>& q) { if (units::get_autoprefix(os) == autoprefix_none) { std::streamsize w = os.width(); if (w > 0) { // Need to build a single string with the width specified // (or outputting severally would not honour the width). std::ostringstream oss; oss << q.value() << ' ' << Unit(); os << oss.str(); } else { // No os.width set (so save the time needed to construct an ostringstream?) os << q.value() << ' ' << Unit(); } } This works for no_prefix, giving the expected number of leading spaces. But not for autoprefix - when a similar trick looks to get much more complicated (and when I start to get that 'angels fear to tread' feeling ;-) Of course the jaggedness of the layout becomes clearer both as the units get longer and get auto-prefixes (eg engineering). And there is a similar problem using a User defined Type like the measurement.hpp example in std::ostream& operator<< os << val.value() << "(+/-" << val.uncertainty() << ")"; where the second item is additional to the width, not included in it. 1 But I am not sure if this is wise. Is this a 'feature'? 2 Is this the best way of solving it? 3 Can/how should this be applied to autoprefix? 4 Should submit a ticket for this? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

1 0

Review Wizard Status Report for August 2012
by Ronald Garcia 16 Aug '12

16 Aug '12

============================================== Review Wizard Status Report for August 2012 ============================================== News ==== 1. Multiprecision Arithmetic Reviewed 2. Type Erasure Reviewed 3. Boost 1.50.0 Released. New Libraries: 1) Algorithm 2) Functional/OverloadedFunction 3) LocalFunction 4) Utility/IdentityType Open Issues =========== The following libraries have been reviewed and await reports from their review managers: * Predef - reviewed February 2012; review manager: Joel Falcou. * Multiprecision - reviewed June 2012; review manager: Jeffrey Hellrung The following libraries have been accepted to Boost, but have not yet been submitted to SVN: * Constrained Value - accepted September 2010; author: Robert Kawulak. * GIL.IO - accepted January 2011; author: Christian Henning. The following libraries have been accepted and submitted to SVN, but have not yet appeared in a release: * Atomic - accepted July 2011; author Helge Bahmann. * Type Traits Introspection - accepted August 2011; author: Edward Diener. * Lockfree - accepted August 2011; author: Tim Blechmann. * Context - accepted January 2012; author: Oliver Kowalke. The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * Endian - accepted provisionally November 2011; author: Beman Dawes. * Log - accepted provisionally March 2010; author: Andrey Semashev. General Announcements ===================== As always, we need experienced review managers. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants, including library contributors, infrastructure contributors, and other mailing list participants with a substantial track record of constructive participation. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "rxg at cs dot cmu dot edu" and "phillips at pacific dot mps dot ohio-state dot edu" respectively. We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. If you are interested in reviewing a library but won't have time during the review period, you can always prepare your review ahead of time. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report, please email Ron or John. The review schedule is an unordered list of the libraries awaiting review. As such, any library on the schedule can be reviewed once the developer is ready, a review manager has been secured, and the manager, developer, and wizards agree on a date to schedule the review. Review Schedule =============== * Join (M) * Pimpl (M) * Sorting (M) * Quaternions, Vectors, Matrices (M) * Variadic Macro Data (M) * Block Pointer (M) * Singularity (M) * Extended Complex Numbers (M) * Metaparse (M) * Polygon: Voronoi Extensions * Coroutine * Range Extensions * Contract * Nowide (M) * ODEint * Array (M) * TypeIndex (M) ``(M)`` marks libraries that need review managers. -------------------- Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Pimpl ----- :Author: Vladimir Batov :Review Manager: Needed :Download: https://github.com/boost-vault/Miscellaneous/blob/master/Pimpl.zip :Description: The Pimpl idiom is a simple yet robust technique to minimize coupling via the separation of interface and implementation and then implementation hiding. This library provides a convenient yet flexible and generic deployment technique for the Pimpl idiom. It's seemingly complete and broadly applicable, yet minimal, simple and pleasant to use. Sorting ------- :Author: Steven Ross :Review Manager: Needed :Download: https://github.com/boost-vault/Sorting :Description: A grouping of 3 templated hybrid radix/comparison-based sorting algorithms that provide superior worst-case and average-case performance to std::sort: integer_sort, which sorts fixed-size data types that support a rightshift (default of >>) and a comparison (default of <) operator. float_sort, which sorts standard floating-point numbers by safely casting them to integers. string_sort, which sorts variable-length data types, and is optimized for 8-bit character strings. All 3 algorithms have O(n(k/s + s)) runtime where k is the number of bits in the data type and s is a constant, and limited memory overhead (in the kB for realistic inputs). In testing, integer_sort varies from 35% faster to 2X as fast as std::sort, depending on processor, compiler optimizations, and data distribution. float_sort is roughly 70% faster than std::sort. string_sort is roughly 2X as fast as std::sort. Quaternions, Vectors, Matrices ------------------------------ :Author: Emil Dotchevski :Review Manager: Needed :Download: http://www.revergestudios.com/boost-qvm/ :Description: QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the q_traits, v_traits and m_traits templates. Variadic Macro Data ------------------- :Author: Edward Diener :Review Manager: Needed :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/variadic_macro_data/>`__ :Description: This library adds support and functionality for variadic macros to Boost as well as integrating variadic macros with the Boost PP library without changing the latter library in any way. Block Pointer ------------- :Author: Phil Bouchard :Review Manager: Needed :Download: https://svn.boost.org/svn/boost/sandbox/block_ptr/ :Description: Deterministic memory manager of constant complexity capable of handling cyclic collections. Singularity ----------- :Author: Ben Robinson :Review Manager: Needed :Download: https://github.com/cppmaven/Singularity :Description: The Singularity Design Pattern allows you to restrict any class to a single instance. Unlike the infamous Singleton, Singularity gives you direct control over the lifetime of the object, does not require you to grant global access to the object, nor does it limit you to the default constructor for that object. Extended Complex Numbers ------------------------ :Author: Matthieu Schaller :Review Manager: Needed :Download: http://code.google.com/p/cpp-imaginary-numbers/ :Description: The library is an extension of the std::complex class addressing two issues: 1. The standard does not guaranty the behaviour of the complex class if instantiated with types other than float/double/long double. 2. Some calculation where pure imaginary numbers (i.e. multiples of sqrt(-1)) appear are unnecessarily slowed down due to the lack of support for these numbers. The code I submit contains two interleaved classes boost::complex and boost::imaginary which can be instantiated with any type T provided T overloads the usual arithmetic operators and some basic (real) mathematical functions depending on which complex function will be used. It is thus an extended version of Thorsten Ottosen's n1869 proposal (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1869.html) Metaparse --------- :Author: Abel Sinkovics :Review Manager: Needed :Download: http://abel.web.elte.hu/metaparse/metaparse.zip :Description: Metaparse is a library for constructing parsers parsing at compile-time based on template metaprogramming. The parsers built with the library take boost::mpl::strings as input and can produce - types - objects (types with public static members) - callable C++ functions (types with public static method) - template metafunction classes as output (based on the input being parsed). On compilers supporting constexpr the library provides the following syntactic sugar for writing the input of the parsers: BOOST_STRING("this is a string") The library can be used for implementing DSLs in C++, including DSLs making C++ template metaprogramming easier (see examples). Polygon: Voronoi Extensions --------------------------- :Author: Andril Sydorchuk :Review Manager: Lucanus Simonson :Download: http://svn.boost.org/svn/boost/sandbox/gtl/ :Description: This library extends Boost.Polygon with the following features: - Robust and efficient implementation of the sweepline algorithm that allows to construct Voronoi diagram, Delaunay triangulation and medial axis of a set of points and line segments. - Coordinates of the output geometries are computed within the 64 machine epsilon relative error (6 mantissa bits). - Voronoi diagram data structure that allows efficient traversal and data association with the output Voronoi graph. - No 3rd party dependencies (e.g. GMP, MPFR), all the required multiple precision types are implemented as part of the library. - The input and output coordinate type domains are configurable via coordinate type traits, thus allowing to compute coordinates of the Voronoi vertices within any required precision. - The full construction of the Voronoi diagram of 100 000 points takes only 0.27 seconds (see benchmarks). Coroutine --------- :Author: Oliver Kowalke :Review Manager: Hartmut Kaiser :Download: http://gitorious.org/boost-dev/boost-dev/archive-tarball/coroutine :Description: This library is an implementation of coroutines and generators using Boost.Context. Range Extensions ---------------- :Author: Akira Takahashi :Review Manager: Neil Groves :Download: https://github.com/faithandbrave/OvenToBoost :Description: This project adds some features of the Oven Range Library to Boost.Range. Features: - Additional Range Adaptors (taken, taken_while, dropped, dropped_while, elements, elements_key, memoized, outdirected) - Extensions for using Lambda (regular function, regular operator) - Infinite Range (iteration function) - and additional range utilities. Contract -------- :Author: Lorenzo Caminiti :Review Manager: Dave Abrahams :Download: http://sourceforge.net/projects/contractpp/files/latest/download :Description: This library implements Contract Programming for the C++ programming language (see the end of this email). In addition, the library implements virtual specifiers (final, override, and new, see C++11), concept checking, and named parameters. This library is implemented for the C++03 standard and it does not require C++11. Nowide ------ :Author: Artyom Beilis :Review Manager: Needed :Download: http://cppcms.com/files/nowide/ :Description: This library makes cross platform Unicode aware programming easier. It provides an implementation of standard C and C++ library functions, such that their inputs are UTF-8 aware on Windows without requiring to use Wide API. ODEint ------ :Author: Karsten Ahnert and Mario Mulansky :Review Manager: Steven Watanabe :Download: https://github.com/headmyshoulder/odeint-v2 :Description: odeint provides routines for numerically solving Ordinary Differential Equations, a task heavily required when approaching scientific problems numerically. In odeint we have implemented the most common algorithms in a modern, generic way which provides several advantages over existing implementations. The main focus of odeint is to separate algorithms from the underlying basic computation unit. This allows for example to easily use the power of modern GPUs via CUDA or OpenCL to speed up computational heavy simulations. Array ----- :Author: Brian Smith :Review Manager: Needed :Download: https://github.com/BrianJSmith/Array :Description: The array class is a C++11 compatible implementation of static multidimensional arrays. TypeIndex --------- :Author: Antony Polukhin :Review Manager: Needed :Download: https://github.com/apolukhin/type_index :Description: TypeIndex is an extended C++11 type_index library, that * works with disabled RTTI * can store const-volatile-reference info about types (if user requested it) * has all the functionality of std::type_index * has portable across compilers and platforms functionality for getting demangled type names * works across modules/shared libraries * does not require C++11 to work Libraries under development =========================== See http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

2 2

dramatically improved template error messages (was: C++11 decltype/SFINAE puzzler)
by Eric Niebler 16 Aug '12

16 Aug '12

(Andrew, a specific question for you below...) (Moderators: can you see why this msg from Andrew never reached the list (which he cc'ed))? On 8/14/2012 8:39 AM, Andrew Sutton wrote: >> GCC-4.7 gives a similarly terse error message. This, I think, is what >> I've been looking for. > > That's neat. Bravo! I've refined this idea. It now avoids cascading errors by detecting when a sfinae_error is passed as an argument to another function. (For the Haskell-ers out there, that makes it like the Either monad.) You can also get the full backtrace by uncommenting one line of code. IMO, this is now approaching something of real value. My personal experience using this with Proto-11 is that it dramatically improves error messages. I can also easily imagine how this can be used to implement a very nice concept-checking library for C++11 that approximates auto-concepts. Andrew, any thoughts on this? You've done far more work in this space than I have. I'd also like to know *why* this works, and indeed if it's guaranteed to. In particular, is it guaranteed that the virtual what() member of the sfinae_error class is instantiated at the outermost call site and not elsewhere (thereby eliminating the deep template back-trace)? I really just stumbled on this technique by accident, and I don't know how thin the ice is here. Both clang-trunk and gcc-4.7 think it's ok. (I'd also like to apologize to Paul Fultz for spelling his name wrong in an earlier message.) -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 8

boost::asio and resolve_async
by david.hagood＠gmail.com 16 Aug '12

16 Aug '12

I was looking at needing to do a large number of reverse DNS lookups for a log analysis program I am writing, and wanted to use some form of async lookup to speed the program up (vs. doing each look up in series, at a couple of seconds per lookup). boost::asio and the async_resolve functions looked to be just what I wanted, BUT: I can find no good examples of a simple lookup. By "simple" I mean "given an address, give me the host name(s) associated with that address". All the examples were for a lookup by host name/transport type/port, e.g. host name/tcp/80. In my case I neither need a port # nor even have one - I just want the RDNS for the address. It seems to me the documentation in the boost::asio is a bit light on the various types for resolver queries, endpoint types, and such - and seems to be more focused on TCP and UDP than generic IP. Are there any better examples out there of RDNS using boost::asio?

2 1

[Interest] Value Dispatch
by *smgreened＠obbligato.org 16 Aug '12

16 Aug '12

Hi all, This might be old hat to verteran boosters but I found it nifty. Maybe it could make a small addition to Boost. Inspired by Sean Parent's C++Now! talk and the various articles on cpp-next, I've been playing around with value semantics and C++11. I found an interesting use of pack expansion at stackoverflow and expanded on it in a local project to convert from a traditional inheritance/virtual function model to a more value-centered approach. It turns out that with pack expansion one can implement "virtual functions" without needing inheritance or pointer/reference semantics. One can consider a vrtual function as "just" a compiler-generated switch statement. With that in mind, here's an example: ----------- #include <iostream> /// This is a collection of node kinds. We use it to categorize /// various kinds of objects and dispatch to the correct routine. template<typename T, typename T::kind ...I> class kind_tuple {}; /// This is the "virtual function" dispatch mechanism. It /// statically generates a lookup table of routines, one for each /// kind. template<typename R, typename D, typename T> class dispatcher {}; /// This is the actual dispatch implementation. template<typename R, typename D, typename O, typename O::kind ...I> class dispatcher<R, D, kind_tuple<O, I...>> { private: // Call the "virtual function override" via the provided class-level // dispatcher. template<typename P, typename O::kind K, typename ...Args> static R dispatch_handler(P payload, Args ...args) { return D::template dispatch<K>(payload, args...); } public: // dispatcher is an object that knows which routine in N to call. template<typename P, typename ...Args> static R dispatch(P payload, typename O::kind kind, Args ...args) { using F = R(P, Args...); F *table[] = { dispatch_handler<P, I, Args...> ... }; return table[kind](payload, args...); } }; class vehicle { public: enum kind { Car, Bus, Boat, Train, Airplane }; typedef kind_tuple<vehicle, kind::Car, kind::Bus, kind::Boat, kind::Train, kind::Airplane> kinds; private: class drive_dispatcher { public: template<kind K> static void dispatch(vehicle v) { v.drive_impl<K>(); } }; class turn_dispatcher { public: template<kind K> static bool dispatch(vehicle v, std::string direction) { return v.turn_impl<K>(direction); } }; template<kind K> void drive_impl(void) {} template<kind K> bool turn_impl(std::string direction) { return false; } kind the_kind; public: vehicle(kind k) : the_kind(k) {} void drive(void) { dispatcher<void, drive_dispatcher, kinds>::dispatch(*this, this->the_kind); } // Return whether the turn was successfully completed. bool turn(std::string direction) { return dispatcher<bool, turn_dispatcher, kinds>:: dispatch(*this, this->the_kind, direction); } }; template<> void vehicle::drive_impl<vehicle::Car>(void) { std::cout << "Driving a car!\n"; } template<> void vehicle::drive_impl<vehicle::Bus>(void) { std::cout << "Driving a bus!\n"; } template<> void vehicle::drive_impl<vehicle::Boat>(void) { std::cout << "Driving a boat!\n"; } template<> void vehicle::drive_impl<vehicle::Train>(void) { std::cout << "Driving a train!\n"; } template<> void vehicle::drive_impl<vehicle::Airplane>(void) { std::cout << "Flying an airplane!\n"; } template<> bool vehicle::turn_impl<vehicle::Car>(std::string direction) { std::cout << "Turning a car " << direction << "!\n"; return true; } template<> bool vehicle::turn_impl<vehicle::Bus>(std::string direction) { std::cout << "Turning a bus " << direction << "!\n"; return true; } template<> bool vehicle::turn_impl<vehicle::Boat>(std::string direction) { std::cout << "Turning a boat " << direction << "!\n"; return true; } template<> bool vehicle::turn_impl<vehicle::Train>(std::string direction) { std::cout << "Turning a train " << direction << "?!?\n"; return false; } template<> bool vehicle::turn_impl<vehicle::Airplane>(std::string direction) { std::cout << "Turning an airplane " << direction << "!\n"; return true; } template<typename Iterator> void drive(Iterator start, Iterator end) { for (auto i = start; i != end; ++i) i->drive(); } template<typename Iterator> void turn(Iterator start, Iterator end, std::string direction) { for (auto i = start; i != end; ++i) if (i->turn(direction)) { std::cout << "Successfully turned " << direction << "\n"; } else { std::cout << "Could not turn " << direction << "\n"; } } int main(void) { vehicle rides[] = { vehicle(vehicle::kind::Car), vehicle(vehicle::kind::Bus), vehicle(vehicle::kind::Boat), vehicle(vehicle::kind::Train), vehicle(vehicle::kind::Airplane) }; drive(rides, rides + 5); std::cout << "\n"; turn(rides, rides + 5, "left"); return 0; } ----------- The central idea is the creating of a "virtual function table" via pack expansion. Not only can we keep value semantics and avoid coupling via inheritance, we also get virtual function-like behavior for template functions. Expanding the idea allows us to implement a completely generic GoF visitor without using inheritance at all: ----------- #include <iostream> #include <tuple> /// This is a collection of node kinds. We use it to categorize /// various kinds of objects and dispatch to the correct routine. template<typename T, typename T::kind ...I> class kind_tuple {}; /// This is the "virtual function" dispatch mechanism. It /// statically generates a lookup table of routines, one for each /// kind. template<typename R, typename D, typename T> class dispatcher {}; /// This is the actual dispatch implementation. template<typename R, typename D, typename O, typename O::kind ...I> class dispatcher<R, D, kind_tuple<O, I...>> { private: // Call the "virtual function override" via the provided class-level // dispatcher. template<typename P, typename O::kind K, typename ...Args> static R dispatch_handler(P payload, Args ...args) { return D::template dispatch<K>(payload, args...); } public: // dispatcher is an object that knows which routine in N to call. template<typename P, typename ...Args> static R dispatch(P payload, typename O::kind kind, Args ...args) { using F = R(P, Args...); F *table[] = { dispatch_handler<P, I, Args...> ... }; return table[kind](payload, args...); } }; class vehicle { public: enum kind { Car, Bus, Boat, Train, Airplane }; typedef kind_tuple<vehicle, kind::Car, kind::Bus, kind::Boat, kind::Train, kind::Airplane> kinds; private: kind the_kind; public: vehicle(kind k) : the_kind(k) {} kind get_kind(void) const { return the_kind; } }; // U is to distinguish among different kinds of visitors for the same // object type. template<typename O, typename U, typename R, typename ...Args> class visitor { private: typedef visitor<O, U, R, Args...> This; // This dispatcher expects a single object so wrap the visitor and // the visited object together. typedef std::tuple<This *, O> payload; class visit_dispatcher { public: template<typename O::kind K> static R dispatch(payload object, Args ...args) { return std::get<0>(object)-> template visit_impl<K>(std::get<1>(object), args...); } }; template<typename O::kind K> R visit_impl(O object, Args ...args) {} public: R visit(O object, Args ...args) { return dispatcher<R, visit_dispatcher, typename O::kinds>:: dispatch(std::make_tuple(this, object), object.get_kind(), args...); } }; // Visitor types class Driving {}; class Turning {}; template<> template<> void visitor<vehicle, Driving, void>::visit_impl<vehicle::Car>(vehicle v) { std::cout << "Driving a car!\n"; } template<> template<> void visitor<vehicle, Driving, void>::visit_impl<vehicle::Bus>(vehicle v) { std::cout << "Driving a bus!\n"; } template<> template<> void visitor<vehicle, Driving, void>::visit_impl<vehicle::Boat>(vehicle v) { std::cout << "Driving a boat!\n"; } template<> template<> void visitor<vehicle, Driving, void>::visit_impl<vehicle::Train>(vehicle v) { std::cout << "Driving a train!\n"; } template<> template<> void visitor<vehicle, Driving, void>::visit_impl<vehicle::Airplane>(vehicle v) { std::cout << "Flying an airplane!\n"; } template<> template<> bool visitor<vehicle, Turning, bool, std::string>:: visit_impl<vehicle::Car>(vehicle v, std::string direction) { std::cout << "Turning a car " << direction << "!\n"; return true; } template<> template<> bool visitor<vehicle, Turning, bool, std::string>:: visit_impl<vehicle::Bus>(vehicle v, std::string direction) { std::cout << "Turning a bus " << direction << "!\n"; return true; } template<> template<> bool visitor<vehicle, Turning, bool, std::string>:: visit_impl<vehicle::Boat>(vehicle v, std::string direction) { std::cout << "Turning a boat " << direction << "!\n"; return true; } template<> template<> bool visitor<vehicle, Turning, bool, std::string>:: visit_impl<vehicle::Train>(vehicle v, std::string direction) { std::cout << "Turning a train " << direction << "?!?\n"; return false; } template<> template<> bool visitor<vehicle, Turning, bool, std::string>:: visit_impl<vehicle::Airplane>(vehicle v, std::string direction) { std::cout << "Turning an airplane " << direction << "!\n"; return true; } template<typename Iterator> void drive(Iterator start, Iterator end) { visitor<vehicle, Driving, void> driver; for (auto i = start; i != end; ++i) driver.visit(*i); } template<typename Iterator> void turn(Iterator start, Iterator end, std::string direction) { visitor<vehicle, Turning, bool, std::string> turer; for (auto i = start; i != end; ++i) if (turer.visit(*i, direction)) { std::cout << "Successfully turned " << direction << "\n"; } else { std::cout << "Could not turn " << direction << "\n"; } } int main(void) { vehicle rides[] = { vehicle(vehicle::kind::Car), vehicle(vehicle::kind::Bus), vehicle(vehicle::kind::Boat), vehicle(vehicle::kind::Train), vehicle(vehicle::kind::Airplane) }; drive(rides, rides + 5); std::cout << "\n"; turn(rides, rides + 5, "left"); return 0; } ----------- Not only is inheritance not required, we only need single dispatch to implement the visitor. Because we don't use inheritance at all for these "virtual functions" and the above visitor we can maintain value semantics throughout any code that uses the above techniques. Of course the code above can be cleaned up and beautified. It's just a quick proof-of-concept. I'm sure someone has already posted about this technique somewhere. Is there any interest in expanding it into a Boost library? -Dave

4 6

[1.51, heap] permission to merge r80039
by Tim Blechmann 16 Aug '12

16 Aug '12

request for release manager: i'd like to merge r80039 to release, as it fixes bug #7233. ok or too late? thanks, tim

4 6

[1.51][hash] Permission to merge.
by Daniel James 15 Aug '12

15 Aug '12

Hello release managers, Please can I merge changeset 80038: https://svn.boost.org/trac/boost/changeset/80038/ The tests have cycled for most major compilers and libraries. I think the only missing one is Visual Age C++ which isn't affected since it doesn't have support for C++11 headers. This fixes a bug when compiled with Intel on windows. thanks, Daniel

3 3