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

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

[predef] Thanks for all the comments..
by Rene Rivera 01 Mar '12

01 Mar '12

I would like to than everyone who reviewed and/or commented on my library. Instead of trying to respond individually to each point raised I will do a single post about all the points I've gathered, and will gather when I reread all the posts. Hopefully I can write that up by Monday. Needless to say there are a few changes I need to do, regardless of acceptance results :-) Again, thanks to all. And thanks to Joel for managing the review. Rene. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

1 0

Adapting Polygon to work with point attributes
by Paul Miller 01 Mar '12

01 Mar '12

Boost::Polygon looks like exactly what I need to do some boolean operations on polygons but my polygons have additional attributes per point that I want to carry through the operation. But I can't figure out how to get polygon to create sensible values for the attributes other than X,Y, and I can't find an example that covers this scenario. It seems from the documentation that this is possible however. Can someone point me to an example, to say, adapt a polygon with this Point type? struct Point { int x, y; float r, g, b, a; }; Ideally it would average new r, g, b, a values together to make new points and polygon join points, but it could just copy one of the existing Points' attributes instead. I'm not picky. Cheers!

2 2

[TypeTraits] Patch: improving detectability of clang's intrinsics
by Michel Morin 01 Mar '12

01 Mar '12

Attached a patch to improve detectability of `__is_pod` and `__is_empty` intrinsics in clang. This is done by newly introduced `__has_feature(__is_pod__)` and `__has_feature(__is_empty__)` macros. (Clang trunk now accepts feature names with preceding and following double underscores.) Regards, Michel

2 1

Re: [boost] [git] neglected aspects
by Brian Wood 01 Mar '12

01 Mar '12

Dave Abrahams: > I don't see any advantage at all in having a "Boost supertree." If I > need a cluster of five libraries to get a job done, I don't see a reason > to mess around with anything more than those five. And with the > dependencies properly encoded, I won't even have to ask for all of those > explicitly. +1 for keeping things simple. This effort has been discussed for years. Is it close to being ready? Regards, Brian Wood Ebenezer Enterprises http://webEbenezer.net

1 0