- Boost - lists.boost.org

Re: [boost] [Boost-commit] svn:boost r77194 - in trunk: boost/config boost/config/compiler boost/config/stdlib libs/config/doc/html/boost_config libs/config/test libs/config/test/all
by Michel Morin 07 Mar '12

07 Mar '12

Hi Marshall, > Author: marshall > Date: 2012-03-03 22:00:49 EST (Sat, 03 Mar 2012) > New Revision: 77194 > […] > --- /trunk/libs/config/test/boost_no_0x_hdr_array.ipp (original) > +++ trunk/libs/config/test/boost_no_cxx11_hdr_array.ipp 2012-03-03 22:00:49 EST (Sat, 03 Mar 2012) > […] > -namespace boost_no_0x_hdr_array { > +namespace boost_no_0cxx11_hdr_array { `boost_no_0cxx11_hdr_array` should be `boost_no_cxx11_hdr_array` ;) Regards, Michel

2 1

[numeric] Applying trivial bugfix
by Antony Polukhin 06 Mar '12

06 Mar '12

Hi, There are a lot of feature requests to support compilation with disabled exceptions #5731, #5076, #5393, #5800. Fix is trivial and well known: replace throw x; with BOOST_THROW_EXCEPTION(x); in a converter_policies.hpp file. But the library maintainer does not like BOOST_THROW_EXCEPTION because of code bloat. Can I apply another trivial fix: struct def_overflow_handler { void operator() ( range_check_result r ) // throw(negative_overflow,positive_overflow) { #ifndef BOOST_NO_EXCEPTIONS if ( r == cNegOverflow ) throw negative_overflow() ; else if ( r == cPosOverflow ) throw positive_overflow() ; #else if ( r == cNegOverflow ) ::boost::throw_exception(negative_overflow()) ; else if ( r == cPosOverflow ) ::boost::throw_exception(positive_overflow()) ; #endif } } ; Adding this will fix all the tickets and allow some of the dependent libraries to build with disabled exceptions. Boost.Lexical_cast tests will cover Boost.Numeric usage cases with disabled exceptions. Best regards, Antony Polukhin

4 7

[msm]omitting region id at the entry pseudo state
by Takatoshi Kondo 05 Mar '12

05 Mar '12

Hello, Now, I'm using Boost.Msm (Version1.49.0). I have a question about a transition behavior when I omit a region id at the entry pseudo state. The document said that when we use the explicit entry, if the state machine satisfied the conditions below, we can omit the region id. http://www.boost.org/doc/libs/1_49_0/libs/msm/doc/HTML/ch03s02.html#d0e852 " Thanks to the mpl_graph library you can also omit to provide the region index and let MSM find out for you. The are however two points to note: - MSM can only find out the region index if the explicit entry state is somehow connected to an initial state through a transition, no matter the direction. - There is a compile-time cost for this feature. " Because of the discussion below, I believe that this rule can also be applied to entry pseudo states. http://boost.2283326.n4.nabble.com/msm-how-to-distinguish-region-ids-tt3612… However, when I omitted the region id, the state machine transitioned to the SubState1. struct Entry1:msmf::entry_pseudo_state<> {}; If I provided the region id, the state machine transitioned to the SubState2. struct Entry1:msmf::entry_pseudo_state<0> {}; See entry_pt_omit_rid.cpp (Attached file) As far as I can understand, Entry1 and SubState1, initial_state, are connected. (See fig.png) Is there any reason that I can't omit the region id in this case? Thanks, Takatoshi

2 3

[Thread] Dll Plugin depending from boost thread
by Keraval Yannick 05 Mar '12

05 Mar '12

Hi guys, An application developed in my company uses the concept of "plugin" which relies on the use of DLL (windows 7 box, Visual Studio 2005). We are using Boost v 1.43 and when loading a plugin with a call to LoadLibrary, application asserts with the following message Debug Assertion Failed! Program: C:\Windows\system32\regsvr32.exe File: f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dllinit.cpp Line: 587 --> ASSERT(AfxGetModuleState() != AfxGetAppModuleState()); We could point out that this is due to the use of the boost thread library. A quick google search pointed us to an issue in the Boost.Thread library (e.g. http://stackoverflow.com/questions/5355931/adding-include-boost-thread-mutex -hpp-breaks-my-activex-control). One proposed solution is to build a DLL instead of a static lib but this is impossible in our company (only plugin can be compiled as dll). We also try to update boost to V1.49 but the debug assertion is still raised. Is there another way to fix this ? We could not find any ticket related to this problem (neither in the opened tickets nor in the closed tickets), is this behavior considered as normal ? Thanks -- View this message in context: http://boost.2283326.n4.nabble.com/Thread-Dll-Plugin-depending-from-boost-t… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Parts of linkflags are disappearing: $ISALIST gone
by Maciej (Matchek) Bliziński 05 Mar '12

05 Mar '12

My linkflags setting involves a dollar sign: linkflags='-R/opt/csw/lib/$ISALIST' The $ISALIST dynamic token tells the linker to iterate through supported instruction sets and pick the best one[1]. When the Boost binaries are built, the RPATH in the binaries is missing the dollar sign and everything after it: $ /usr/ccs/bin/dump -Lv work/solaris10-sparc/pkgroot/opt/csw/gxx/lib/sparcv9/libboost_iostreams.so.1.49.0 | grep RPATH [13] RPATH /opt/csw/lib/64:/opt/csw/gxx/lib/:/opt/csw/gxx/lib/64:/opt/csw/lib/ Do you see the /opt/csw/lib/ bit with the slash at the end? It could be explained by the contents of linkflags being interpolated by a shell. In my build, it's important to pass the dollar sign unchanged. Here's an example of correctly set RPATH: /usr/ccs/bin/dump -Lv /opt/csw/lib/libz.so.1 | grep RPATH [6] RPATH /opt/csw/lib/$ISALIST:/opt/csw/lib I need to pass the same flag to Boost libraries. Has anyone else seen this problem? Maciej [1] http://docs.oracle.com/cd/E19082-01/819-0690/appendixc-3/index.html

1 0

[context] Providing template class enumerate in context.hpp
by Julien Nitard 04 Mar '12

04 Mar '12

Hi all, I am trying to use the newly accepted boost.context and I am wondering why something as useful as the template enumerate is not diretly given when including "context.hpp" and not even in a separate header. Since it's in the doc it would be a good addition IMHO. Thanks, Julien PS: the link to boost.context doc is broken and the git repos seems to have moved.

5 14

bug in gcc.jam
by Oliver Kowalke 04 Mar '12

04 Mar '12

Hello, gcc.jam:451 applies always -m32 for 32bit systems. In the case of ARM architecture this is false because gcc on arm does not recognize -m32. In order to correct this issue I need to know how to test for ARM architecture at this code line (sorry I'm not that boost.build expert). Oliver

1 0

boost::adaptors::keys for mutable ranges of pairs
by Valentin Ziegler 04 Mar '12

04 Mar '12

Hello, map.hpp defines two overloads for adaptors::values, one for StdPairRange& and another for const StdPairRange const& rng. On the other hand, there is just a single adaptors::keys which takes StdPairRange const&. In particular, the code below will not compile: boost::find_if( boost::adaptors::keys(rng), SomePredicate() ).base()->second=NewValue(); Therefore, I would propose an adaptors::keys(StdPairRange& rng) overload similar to adaptors::values(StdPairRange&). Iterators of the returned range shall have a mutable base iterator. Further, iterators of the returned range should have a reference type of range_value<StdPairRange>::type::first_type& , so the elements in keys are mutable where StdPairRange admits this. Regards, Valentin -- Valentin Ziegler | vziegler(a)think-cell.com Software Engineer think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

2 1

[config] std::unique_ptr, std::ref detection?
by Peter Dimov 04 Mar '12

04 Mar '12

Suppose I want to implement a shared_ptr constructor taking std::unique_ptr. To avoid breaking pre-C++11 compilers, I need to, at least, know whether <memory> contains std::unique_ptr. (I'd also like to know if there's std::ref in <functional> because the specification of the constructor uses it.) But the config library doesn't seem to provide a way. There's no macro for std::unique_ptr, and there's no macro for "generic C++11 compiler and library".

9 23

Possible Bug in Boost Geometry's Huiller Algorithm
by Brian Ahr 03 Mar '12

03 Mar '12

Hi Folks. I was looking at the implementation of the huiller algorithm in boost, and it seems to be partially incorrect. See boost/geometry/strategies/spherical/area_huiller.hpp In the apply() function, we have if(lon2 < lon1){ E =-E;} which I believe should instead be calculation_type lon;if( lon2 < lon1 ) lon = lon1 - lon2;else lon = lon1 - lon2 + two_pi;if(2* half_pi < lon ) E =-E; according to Graphics Gems 5, pg 45 - 46. The comments at the top of the C++ file state that the code was derived from code in Graphics Gems 4, though the code was later corrected in Graphics Gems 5. I noticed this when trying to calculate areas of polygons on a sphere, where one of the points was (0, 0). In that case, it would always return a negative area, even though the polygon was defined counter-clockwise. Using a point other than (0,0) seemed to alleviate the problem, which got me wondering what was going on. Can anybody else confirm that this is an issue? Any suggestions for cleanly overriding boost's implementation until this is fixed? Thanks! - Brian

2 2