- Boost - lists.preview.boost.org

[utility][optional] boost::equal_pointees -- move it?
by Andrzej Krzemienski 29 May '14

29 May '14

Hi, I recently noticed that there is a plan to move everything out of Boost.Utility. Is that right? There is a small feature in there: http://www.boost.org/doc/libs/1_55_0/libs/utility/OptionalPointee.html (header <boost/utility/compare_pointees.hpp>, added along Boost.Optional. Should it be moved out of Utility to Boost.Optional also? If so, any hints on how I should preserve the backwards compatibility for its users? Regards, &rzej

1 0

Re: [boost] [config][predef] Is it OK for boost.config to depend on boost.predef?
by Rene Rivera 29 May '14

29 May '14

On Wed, May 28, 2014 at 12:45 PM, Robert Ramey < robertmacleranramey(a)gmail.com> wrote: > > The whole existence of boost predef was a huge surprise to me. > It was reviewed and accepted ;-) > Looking at the dates it seems its been in boost for a while. I perused > the documentation. I'm still not getting how this doesn't overlap with > config..hpp. I thought that config.hpp was designed to address the issue > of portability between platforms. > Boost Config is indeed designed to address portability between platforms. As a requirement of that design it also has to deal with detecting the different platforms it's trying to define feature/defect macros for. Detecting the platform is not a requirement for Config to work. And you can run the Config configure program to generate a set of portability feature/defect definitions without knowing about the platform. > So I would expect that a facility such as > > #include <boost/predef/platform/windows_desktop.h> > #include <boost/predef/platform/windows_runtime.h> > > would depend upon config.hpp rather than the other way around. > > And since config.hpp is designed to determine the platform automatically, > I'm very surpassed to see predef at all. > "config.hpp" has to partially determine the "platform" by need not by design. > Any additional information you want to submit would be interesting to see. > Predef's design is to *not* detect or define feature/defect macros. All it does is the detection of the platform (compiler, libraries, etc). With enough fine grained platform information one can use it to define know feature/defect macros. Predef defines a much larger superset of the Config platform defs <http://tinyurl.com/o68ovjz> in a consistent (and consistent to check) manner. Or more succinctly: * Predef detects the environment you are compiling in. * Config defines what is or isn't broken with that environment relative to the ideal/standard -conforming environment. HTH -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 1

[config] any macro to detect "Rvalue references for *this"?
by Andrzej Krzemienski 29 May '14

29 May '14

Hi, Is there a macro in Boost.Config that would help me test if a compiler supports a C++11 feature "Rvalue references for *this" ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2439.htm)? Regards, &rzej

3 11

Adding spirit::is_container to boost::traits
by Rodrigo Madera 28 May '14

28 May '14

Is there any intention of including is_container [1] into boost::traits? I find myself using that particular Spirit header, which could be useful if isolated into traits. Cheers, Madera [1] http://www.boost.org/doc/libs/1_55_0/libs/spirit/doc/html/spirit/advanced/c…

4 9

[interprocess] Is message_queue experiencing problems in 1.55?
by Joseph Van Riper 28 May '14

28 May '14

I'm embarrassed to ask this, but I don't see documentation to help me through a problem like this. I assume I'm doing something wrongly, since I assume someone would have seen something like this earlier. Note that I've boiled this down to the simplest reproducible problem... originally, I tried to simply make use of the message queue using the example code in the documentation, but I can't get past the compile error. I started removing code to find the problem, only to strip ... well ... all of it away. I also tried looking through trac to see if someone already reported this, but I didn't see anything (which doesn't necessarily mean anything, as I may have failed to properly search the thing). Steps to reproduce: 1. On VC++ 2013, create an empty command-line project. 2. At the top of the main .cpp file, add "#include <boost/interprocess/ipc/message_queue.hpp>" 3. Ensure the project can find the boost headers. 4. Compile. Expected result: A completely pointless, but compiled .exe is created. Actual result: Compile error: 1>------ Build started: Project: msgqueue_test, Configuration: Debug Win32 ------ 1> stdafx.cpp 1> msgqueue_test.cpp 1>c:\users\tvanriper\documents\code\sdks\boost\include\boost-1_55\boost\intrusive\detail\has_member_function_callable_with.hpp(200): error C2228: left of '.select_on_container_copy_construction' must have class/struct/union 1> type is 'boost::move_detail::add_rvalue_reference<U>::type' 1> c:\users\tvanriper\documents\code\sdks\boost\include\boost-1_55\boost\intrusive\detail\has_member_function_callable_with.hpp(276) : see reference to class template instantiation 'boost::container::container_detail::has_member_function_callable_with_select_on_container_copy_construction_impl<Fun,true,>' being compiled 1> with 1> [ 1> Fun=std::allocator<std::pair<const boost::interprocess::ipcdetail::sync_id *const ,boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<std::pair<const boost::interprocess::ipcdetail::sync_id,void *>>>>> 1> ] 1> c:\users\tvanriper\documents\code\sdks\boost\include\boost-1_55\boost\container\allocator_traits.hpp(262) : see reference to class template instantiation 'boost::container::container_detail::has_member_function_callable_with_select_on_container_copy_construction<const Alloc,>' being compiled 1> with 1> [ 1> Alloc=std::allocator<std::pair<const boost::interprocess::ipcdetail::sync_id *const ,boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<std::pair<const boost::interprocess::ipcdetail::sync_id,void *>>>>> 1> ] 1> c:\users\tvanriper\documents\code\sdks\boost\include\boost-1_55\boost\container\detail\tree.hpp(217) : see reference to class template instantiation 'boost::container::allocator_traits<A>' being compiled 1> with 1> [ 1> A=std::allocator<std::pair<const boost::interprocess::ipcdetail::sync_id *const ,boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<std::pair<const boost::interprocess::ipcdetail::sync_id,void *>>>>> 1> ] 1> c:\users\tvanriper\documents\code\sdks\boost\include\boost-1_55\boost\container\detail\tree.hpp(246) : see reference to class template instantiation 'boost::container::container_detail::intrusive_rbtree_type<A,boost::container::container_detail::tree_value_compare<Key,std::pair<const Key,T>,Compare,boost::container::container_detail::select1st<std::pair<const Key,T>>>>' being compiled 1> with 1> [ 1> A=std::allocator<std::pair<const boost::interprocess::ipcdetail::sync_id *const ,boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<std::pair<const boost::interprocess::ipcdetail::sync_id,void *>>>>> 1> , Key=const boost::interprocess::ipcdetail::sync_id * 1> , T=boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<std::pair<const boost::interprocess::ipcdetail::sync_id,void *>>> 1> , Compare=boost::interprocess::ipcdetail::sync_handles::address_less 1> ] 1> c:\users\tvanriper\documents\code\sdks\boost\include\boost-1_55\boost\container\map.hpp(83) : see reference to class template instantiation 'boost::container::container_detail::rbtree<Key,std::pair<const Key,T>,boost::container::container_detail::select1st<std::pair<const Key,T>>,Compare,Allocator>' being compiled 1> with 1> [ 1> Key=const boost::interprocess::ipcdetail::sync_id * 1> , T=boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<std::pair<const boost::interprocess::ipcdetail::sync_id,void *>>> 1> , Compare=boost::interprocess::ipcdetail::sync_handles::address_less 1> , Allocator=std::allocator<std::pair<const boost::interprocess::ipcdetail::sync_id *const ,boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<std::pair<const boost::interprocess::ipcdetail::sync_id,void *>>>>> 1> ] 1> c:\users\tvanriper\documents\code\sdks\boost\include\boost-1_55\boost\interprocess\sync\windows\sync_utils.hpp(226) : see reference to class template instantiation 'boost::container::map<const boost::interprocess::ipcdetail::sync_id *,boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<T>>,boost::interprocess::ipcdetail::sync_handles::address_less,std::allocator<std::pair<const Key,boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<T>>>>>' being compiled 1> with 1> [ 1> T=std::pair<const boost::interprocess::ipcdetail::sync_id,void *> 1> , Key=const boost::interprocess::ipcdetail::sync_id * 1> ] ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

2 2

Is there any interest in a library for actor programming?
by Charousset, Dominik 28 May '14

28 May '14

Hi, is there any interest in a library for actor programming? The library we've developed is a C++11 open source library named "libcppa". It is currently released under LGPL2, but re-releasing the library under the boost license is not an issue. You'll find all important links and ressources either under http://libcppa.org or on the GitHub project page: https://github.com/Neverlord/libcppa, including a user manual as HTML or PDF. We've also submitted a paper to the C++Now conference. What is actor programming? For those of you who aren't yet familiar with the actor model: actors basically represent tasks or services that communicate via message passing. In libcppa, actors are very lightweight (you can spawn literally millions of them) and scheduled cooperatively using a thread pool (although actors are allowed to opt-out of the cooperative scheduling). Some of the main strengths of this programming paradigm are: (1) network transparency, (2) race conditions are avoided by design, (3) a strong failure model that enables developers to build reliable distributed systems, and (4) the actor model addresses both concurrency (multiple actors on one host) and distribution (any number of actors on any number of hosts). Here's the classical hello world example: ---------------------------------------------------------------------------------- #include <string> #include <iostream> #include "cppa/cppa.hpp" using namespace std; using namespace cppa; void mirror() { // wait for messages become ( // invoke this lambda expression if we receive a string on_arg_match >> [](const string& what) { // prints "Hello World!" via aout (thread-safe cout wrapper) aout << what << endl; // replies "!dlroW olleH" reply(string(what.rbegin(), what.rend())); // terminates this actor ('become' otherwise loops forever) self->quit(); } ); } void hello_world(const actor_ptr& buddy) { // send "Hello World!" to our buddy ... sync_send(buddy, "Hello World!").then( // ... and wait for a response on_arg_match >> [](const string& what) { // prints "!dlroW olleH" aout << what << endl; } ); } int main() { // create a new actor that calls 'mirror()' auto mirror_actor = spawn(mirror); // create another actor that calls 'hello_world(mirror_actor)' spawn(hello_world, mirror_actor); // wait until all other actors we have spawned are done await_all_others_done(); // run cleanup code before exiting main shutdown(); } ---------------------------------------------------------------------------------- A message is simply a tuple of values that is pattern matched at the receiver. For example, " on_arg_match >> [](const string& what) {...}" defines a message handler that is called whenever a tuple with one single string element arrives. "on_arg_match" simply defines a pattern that matches the signature of the given lambda. Please have a look at the examples folder on GitHub (https://github.com/Neverlord/libcppa/tree/master/examples) or at the user manual (http://neverlord.github.io/libcppa/manual/) if you want to see more examples. Best regards, Dominik Charousset

17 62

[foreach] Can should_copy_impl return type be simplified?
by Mostafa 28 May '14

28 May '14

I'm studying the implementation of foreach and I had a question about should_copy_impl. For reference, here's the overload that's vexing me: // If the collection is an array or is noncopyable, it must be an lvalue. // If the collection is a lightweight proxy, treat it as an rvalue // BUGBUG what about a noncopyable proxy? template<typename LValue, typename IsProxy> inline BOOST_DEDUCED_TYPENAME boost::enable_if<boost::mpl::or_<LValue, IsProxy>, IsProxy>::type * should_copy_impl(LValue *, IsProxy *, bool *) { return 0; } Why is enable_if needed? Can't the return type just be "IsProxy *"?

2 1

[Math] Rationale Behind Epsilon Values
by Axel Ismirlian 28 May '14

28 May '14

Hello, I am new to this mailing list, so its possible the format of my question may be off by a little. My team has been working on getting boost to run on PPC 64-LE. There are many tests in boost that rely on the machine epsilon value. Why was this value chosen to determine success or failure of a particular test knowing that it is hardware specific? More specifically, the Long Double type is very different on both platforms. However, by forcing the x86 Long Double epsilon value on the PPC machine we were able to get many of the previously failing tests to pass. This change was inspired by the fact that a similar fix was already in the code for Darwin platform, but the value that it returns for the Darwin platform is not the x86 value. Also the LDBL_MANT_DIG on both the Darwin platform and our platform (PPC 64-LE) are the same, and are equal to 106. How was the Long Double value on the Darwin platform determined? For reference, the actual code lies in boost/math/tools/precision.hpp. We were also wondering whether or not this was a valid solution to fixing the problem? Part of us feel this doesn't address the underlaying problem. Sincerely. -Axel

3 3

[convert] An approach that might actually work. :-)
by Vladimir Batov 28 May '14

28 May '14

To move forward in a coordinated way how about we create a working group (say, >= 5 people). Then we'd address convert-related issues in the order of importance. Public API first, converter API then, etc. (Or maybe some other design altogether). We'd focus on one thing at a time. Discuss it and then vote. The solution accepted by the majority wins, we document it and move forward to the next item of importance... without running in circles about the previous issues... unless we realize down the track that our solution is flawed somehow. That won't require any more of the time of the participants than it is now. I am happy to coordinate (whatever that might be), do implementation (to the best of my abilities), etc. Still, if anyone feels strongly about doing that "coordination" thing, step forward, no drama. Such collaborative approach would take subjectivity out and might bring new unexpected ideas, etc. That I think might actually work. Any one willing to sign up? Jeroen, Roland, Rob? What people think? Let me know if you feel like participating, contributing... If there is no appetite for that, it's still OK. -- View this message in context: http://boost.2283326.n4.nabble.com/convert-An-approach-that-might-actually-… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 3

Compiling without Long Double Support
by Axel Ismirlian 28 May '14

28 May '14

Hello, My team and I are working to make boost compatible with PPC 64-LE and we were wondering how to compile boost without long double support, so that in the mean time we can isolate other problems not related to floating point problems. Sincerely, -Axel

2 1