- Boost - lists.preview.boost.org

[move] move's is_convertible does not compile with aligned data
by Tobias Loew 09 Apr '13

09 Apr '13

The implementation of move's is_convertible-type has the same problems on MSVC with aligned types as reported for type_trait's is_convertibale in Ticket #5271 https://svn.boost.org/trac/boost/ticket/5271 As type_trait's implementation has been fixed, a simple solution would be letting the user (and not the code in move.hpp:41) [not] define BOOST_MOVE_AVOID_BOOST_DEPENDENCIES regards Tobias -- View this message in context: http://boost.2283326.n4.nabble.com/move-move-s-is-convertible-does-not-comp… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

boost/thread.hpp UBICOM processor
by Aswin Paranji 09 Apr '13

09 Apr '13

Hi, I'm trying to compile boost library 1.53 using the ubicom toolchain provided by our embedded partner. During compilation of the boost library there was a linker error (_sync_fetch_add). This was overcome by adding define statement BOOST_SP_USE_PTHREADS, along with FENCED in user-config.hpp. The application was linked properly. Running the application within the embedded box exits with a segmentation fault happening before printing the first line of the main function. This was narrowed down to boost/thread.hpp header. Removing the header allows the application to print the first line and return. The problem I have is, I do not have GDB/GDBServer to assist me. Also, i could not use back_trace as the toolchain does not have the necessary header files. Can anyone tell me what might be causing the problem. I'm sure there is some sort of conflict between the processor architecture with thread or the toolchain which was used to compile boost. The GCC version is 4.4.1 Appreciate if someone can help me on this. Thanks, Aswin Paranji

2 2

[phoenix] doesn't compile with gcc 4.9 snapshot
by Nathan Ridge 08 Apr '13

08 Apr '13

Hi, I'm trying to compile some code that uses Boost with a GCC 4.9 snapshot, but something seems to be going badly wrong. Something as simple as a file containing the include: #include <boost/phoenix/core.hpp> fails to compile, with the following errors: In file included from boost/proto/matches.hpp:42:0, from boost/phoenix/core/domain.hpp:12, from boost/phoenix/core/actor.hpp:17, from boost/phoenix/core.hpp:15, from test.cpp:1: boost/proto/traits.hpp: In instantiation of 'struct boost::proto::tag_of<boost::proto::_>': boost/phoenix/core/domain.hpp:25:18: required from here boost/proto/traits.hpp:241:42: error: no type named 'proto_tag' in 'struct boost::proto::_' typedef typename Expr::proto_tag type; ^ In file included from boost/phoenix/core/argument.hpp:15:0, from boost/phoenix/core.hpp:17, from test.cpp:1: boost/phoenix/core/terminal.hpp: In instantiation of 'struct boost::phoenix::detail::placeholder_idx<boost::proto::make<boost::is_placeholder<boost::proto::_value>()> >': boost/phoenix/core/terminal.hpp:122:18: required from here boost/phoenix/core/terminal.hpp:115:16: error: 'value' is not a member of 'boost::proto::make<boost::is_placeholder<boost::proto::_value>()>' struct placeholder_idx ^ The exact same code compiles fine with GCC 4.8 and earlier. Any ideas as to what might be going wrong? Thanks, Nate

1 1

Boost.Graph for GSoC
by Daniel Mitchell 08 Apr '13

08 Apr '13

Hi all, I'm a researcher and graduate student at the University of Texas at Austin and I'm interested in doing a Boost.Graph project for GSoC. I was thinking of doing one or more planar graph algorithms, in particular the multiple source shortest paths algorithm for planar graphs described at http://courses.csail.mit.edu/6.889/fall11/lectures/L11.html The algorithm assumes that the sources are located on a single face. It proceeds by calculating the shortest paths tree from one source and then minimally modifying the tree to efficiently get the shortest paths from the other sources. The algorithm uses a dynamic tree data structure, so developing that data structure would be part of the project too. I've made prior contributions to BGL. I worked with Doug Gregor to implement color maps for the breadth first and Dijkstra's algorithms. One of my current areas of research is movement ecology, where planar graphs can be used to study movement. Let me know what you think. Daniel Mitchell

3 4

[container] stable_vector::back() is broken in Boost 1.53
by Klaim - Joël Lamotte 08 Apr '13

08 Apr '13

Tested on both VS2010 and VS2012, boost 1.53, with default boost no option set: ############ #include <boost/container/stable_vector.hpp> #include <iostream> int main() { boost::container::stable_vector< int > values; values.emplace_back( 42 ); int& bad_value = values.back(); // bad address int& good_value = values.front(); int& also_good_value = values.at(0); // imply values[0] std::cout<< " ADDRESS OF BAD VALUE : " << &bad_value << std::endl; std::cout<< " ADDRESS OF GOOD VALUE : " << &good_value << std::endl; std::cout<< " ADDRESS OF ALSO GOOD VALUE : " << &also_good_value << std::endl; } ############ This code displays addresses of the bad_value object very low on Debug and very high on Release. I believe that .back() is broken. However, when I test there : http://liveworkspace.org/code/3F11CK$2 it seems to work with any available compiler. So either it's LiveWorkspace which use an older boost version, or this issue arise only on VC. I made a ticket: https://svn.boost.org/trac/boost/ticket/8412 Joel Lamotte

6 10

GSoC 2013: Boost is a mentoring organization
by Boris Schaeling 08 Apr '13

08 Apr '13

Boost is a mentoring organization in this year's GSoC program. Thanks to everyone who added proposals to <https://svn.boost.org/trac/boost/wiki/SoC2013> and to Google for inviting us! According to the GSoC calendar at <https://google-melange.appspot.com/gsoc/events/google/gsoc2013> we have now two weeks where would-be student participants discuss application ideas. If you are interested in participating in the program - either as a student or as a mentor - get active now! :) 1) Have a look at our ideas list at <https://svn.boost.org/trac/boost/wiki/SoC2013>. Find something which interests you or think of a brand new project. 2) Send a mail to the mailing list at <mailto:boost@lists.boost.org> to let people know what you are interested in and what you have to offer. 3) Discuss your idea with others and try to turn it into an actual GSoC project. You need at least a project description, a goal, a mentor and a student. :) Boris

1 0

Adding some image libs to boost build
by Christian Henning 08 Apr '13

08 Apr '13

I have added jpeg, png, and tiff jam files to boost trunk. These files will be needed by gil::io tests. There are still some remaining issues which I like to discuss in this thread: 1. building these libs sometimes requires renaming header and/or source files to the correct architecture. Should we leave that up to the user or should bjam take care of it. And if so, how will we configure that. One example is jpeg: see jconfig.vc -> jconfig.h 2. Tiff has a file nmake.opt which is included in the makefile. How will we include all those options? Regards, Christian

3 5

Release milestone.
by Vicente J. Botet Escriba 08 Apr '13

08 Apr '13

Hi, I would like to merge some fixes in Boost.Thread, but I suspect that the release branche should be blocked as for https://svn.boost.org/trac/boost/wiki/ReleaseSchedule. On which stage (milestone) is the release process? Best, Vicente

2 2

[gil] numeric extension, arithmetic operators
by Harg Tholan 08 Apr '13

08 Apr '13

Hey, Do we plan to overload arithmetic operators for Pixel as wrappers of the numeric extension? or should users derive a class from Pixel adding such functionality? ATM, for diving two pixels (rgb_8 for example), I have to call the division this way: pix_r = pixel_divide_t<rgb_8_pixel_t, rgb_8_pixel_t, rgb_8_pixel_t>().operator()(pix2, pix1); The thing is that I have a template class that makes use of operator/ at some point on one of the template parameters, and I would like to be able to use it with 'Pixel' type. Thank you!

3 7

Re: [boost] future<>::then() Error returning future<void> (on trunk)
by Vicente J. Botet Escriba 07 Apr '13

07 Apr '13

Le 22/01/13 22:56, Vicente Botet a écrit : > Fernando Pelliccioni wrote >> Hi Vicente, hi all, >> >> I noticed that in the trunk there is a implementation of >> future<>::then(). >> Thank you very much for your efforts to implement it! > Hi Fernando, > > I have started with a restricted implementation. While trying to cover with > the whole requirements I didn't reach to get correct implementation. This is > way this new feature is not delivered yet. For the time been I don't think > the current implementation is ready for production code. > > >> The following example, compiles OK >> >> boost::future >> <int> >> f1 = boost::async([]() { return 123; }); >> f1.then([](boost::future >> <int> >> const& f) { >> return std::string(""); >> }); >> >> >> But this one fails to compile: >> boost::future >> <int> >> f1 = boost::async([]() { return 123; }); >> f1.then([](boost::future >> <int> >> const& f) { >> }); >> >> Here future<>::then() have to returns future >> <void> >> like ... >> >> boost::async([]() { }); >> >> Am I right? > Yes, it should. I have no access to my development environment for this > week. Could you post the compiler error? > > >> On the other hand, have you taken into account the following paper? >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3451.pdf > I read it and the mail exchanges related to this paper. > Currently I didn't reached to make it working at all when the future > destructor blocks, but I'm not sure this is the hidden problem as I have > also other issues when the future destructor doesn't blocks. > > I'm really sorry that the current state is not really usable :( > Hi Fernando, I have reworked the future::then function, and even if it is not yet complete (e.g. deferred is not implemented for c++98 compilers) it start to be usable for c++11 compilers, even if BOOST_THREAD_DONT_PROVIDE_FUTURE_INVALID_AFTER_GET is not defined. BTW, joining on the async future destructor works also. Please could you give it a try and let me know whatever you can find that doesn't works as you expect, Best, Vicente

2 3