June 2008 - Boost - lists.preview.boost.org

[ptr_container] Patch to avoid warnings
by Markus Schöpflin 09 Jun '08

09 Jun '08

Hello, attached patch fixes two warnings about unused template parameters in the current ptr_container library. I'm not 100% sure about the first chunk, which even might be a bug: template< class Compare, class Allocator > ptr_map_adapter_base( const Compare& comp, - const allocator_type& a ) + const Allocator& a ) : base_type( comp, a ) { } Is this the right fix? The second chunk should be fairly obvious. Could the author please check this and possibly apply the patch? Regards, Markus Index: ptr_map_adapter.hpp =================================================================== --- ptr_map_adapter.hpp (revision 46270) +++ ptr_map_adapter.hpp (working copy) @@ -227,7 +227,7 @@ template< class Compare, class Allocator > ptr_map_adapter_base( const Compare& comp, - const allocator_type& a ) + const Allocator& a ) : base_type( comp, a ) { } Index: detail/reversible_ptr_container.hpp =================================================================== --- detail/reversible_ptr_container.hpp (revision 46270) +++ detail/reversible_ptr_container.hpp (working copy) @@ -661,7 +661,6 @@ #define BOOST_PTR_CONTAINER_DEFINE_COPY_CONSTRUCTORS( PC, base_type ) \ \ - template< class U > \ explicit PC( const PC& r ) : base_type( r ) { } \ \ template< class U > \

1 0

[serialization] This() function is useless in basic_binary_oprimitive and basic_binary_iprimitive
by Vyacheslav E. Andrejev 09 Jun '08

09 Jun '08

Hello, It seems to me that the function "Archive * This();" defined in basic_binary_oprimitive and basic_binary_iprimitive is useless. Because the same function is defined in interface_iarchive and interface_oarchive. And it apparently is not used in basic_binary_oprimitive and basic_binary_iprimitive themselves. -- -- Vyacheslav Andrejev -- System Architect, Optech International, Inc.

2 2

Property Tree quickbook docs uploaded
by Ryan Gallagher 08 Jun '08

08 Jun '08

Reposting the following incase anyone missed it a few days ago: Patch and quickbook files uploaded in bug 1989 attachments: http://svn.boost.org/trac/boost/ticket/1989 As the bug describes, more work is needed on this. Some updates for recent library changes including removing some sections need to be made at least. Also, linking with main boost docs still needs to be done. These patches are based upon Marcin's original docs. Unfortunately, there are some sections (e.g. property tree synopsis) that don't seem quite as good with the new docs (in this case because the class synopsis itself isn't embedded in this section, just the reference section). These and other polish items could be done, but a better understanding of quickbook/boostbook is needed. I can continue to look into this when I get a chance, but it might be a little while before I can do it. Anyhow, whoever is interested, feel free to build and review the docs based upon these patches. Hopefully this is at least a starting point, but let me know if there are any major issues. -Ryan

1 0

[GTL] clipping and merge of general polygons with attributes
by Simonson, Lucanus J 08 Jun '08

08 Jun '08

I am currently porting pre-existing internal code for performing scanline based merge of arbitrary-angle planar polygons into GTL. The algorithm carries generic property values associated with the input polygons through to the output. That means that if polygon A has property X and polygon B has property Y the output of merge would be potentially three types of polygons, those with property X, those with property Y and those with property {X, Y}. This is essentially the 2D version of the interval set operations proposed by Joachim Faulhaber. Obviously, it can be used as the foundation for general Boolean operations: e.g. the intersection between all polygons with property X and all polygons with property Y is simply the portion of the output with property {X, Y}. I wanted to ask Bruno and Barend to comment on whether they think this algorithm would be useful and solicit the boost community in general to comment on my progress designing the interfaces to it. I looked at Barend's library and could only find rectangle clipping, did I miss it, or is a comparable capability not provided by Barend's geometry library? I also looked at the documentation for Mateusz Loskot's geos library, but was only able to find linestring intersection algorithms, and the geometry container and polygon container types didn't obviously support Boolean operations, though I could have missed it. I would have expected that it would. I have added arbitrary angle polygon data types and concepts to GTL to support the API the algorithm will provide. These are different from those proposed by Barend, though the concepts should be compatible with his data types. My concepts for polygons center around the idea that they should be able to provide iterator range semantics for getting and setting their contents. I have concepts for the following struct polygon_90_concept {...}; struct polygon_90_with_holes_concept : polygon_90_concept {...}; struct polygon_45_concept : polygon_90_concept {...}; struct polygon_45_with_holes_concept : virtual polygon_45_concept, polygon_90_with_holes_concept {...}; struct polygon_concept : polygon_45_concept {...}; struct polygon_with_holes_concept : virtual polygon_concept, polygon_45_with_holes_concept {...}; A polygon_90 is a polygon that is restricted to axis-parallel edges, and has angles that are all multiple of 90-degrees. A polygon_45 is a polygon that has angles that are all multiple of 45-degrees. A polygon is a polygon with arbitrary angles. The concepts inherit from each other to share some implementation, such as the holes, and to allow some measure of polymorphism of polygon types. For instance, the result of a Boolean operation on 90-degree geometry could be stored to arbitrary angle polygons at the output with the same generic function call as would be used to store to 90-degree polygons because an arbitrary angle polygon can represent 90-degree angle data. The high level overview of the API proposal is that generic free functions detect the conceptual type of geometry objects that are called on and redirect the call to the function of the same name defined within the appropriate geometry concept, sometimes with tag dispatching to select between different versions of the function within the concept. For example contains: template <typename geometry_type_1, typename geometry_type_2> bool contains(const geometry_type_1& geometry_object, const geometry_type_2& contained_geometry_object, bool consider_touch = true) { return geometry_concept<geometry_type_1>::type::contains(geometry_object, contained_geometry_object, consider_touch, typename geometry_concept<geometry_type_2>::type()); } might be called on a rectangle and a point, a polygon and a rectangle, or any other sensible combination of geometry objects, provided that the associated concept structs define the algorithm required conforming to the syntax expected. For example, the rectangle contains point function is defined as follows: template <typename rectangle_type, typename point_type> static bool contains(const rectangle_type& rectangle, const point_type point_contained, bool consider_touch, point_concept tag) { return interval_concept::contains(get<HORIZONTAL>(rectangle), point_concept::get<HORIZONTAL>(point_contained), consider_touch, no_type()) && interval_concept::contains(get<VERTICAL>(rectangle), point_concept::get<VERTICAL>(point_contained), consider_touch, no_type()); } This indirection leads to some welcome benefits to usability. It leads to very simple and straightforward syntax errors in incorrectly formed user code, for instance, say the user calls vertical(user_point_object), which shouldn't work because vertical expects a rectangle or prism, the compiler generates the fairly readable error: gtl.hpp: In function typename component_type<geometry_type>::type vertical(const geometry_type&) [with geometry_type = point_data<int>]: main.cpp:14: instantiated from here gtl.hpp:125: error: vertical is not a member of point_concept , telling the user only where their mistake was (main.cpp:14) and what is wrong (vertical is not a member of point_concept), which is exactly the information the user needs to fix their error and not more. Other syntax errors may result in substitution failure such as if the user calls center(user_point_object), which shouldn't work because a point doesn't have a center, the compiler generates a substitution failure error instead: main.cpp:14: instantiated from here post_geometry_traits_definitions.hpp:24: error: no type named center_type in struct point_concept::registration<point_data<int> > main.cpp: In function void foo(): main.cpp:14: error: no matching function for call to center(point_data<int>&) main.cpp: In function bool testRectangle(): , informing the user that point doesn't provide a center_type and giving them the very clear error that there is no function center() which takes their data type. In the case that the user has not registered their type with the library the error will look like: ... gtl.hpp:125: error: <function name> is not a member of no_type I could change the name of no_type to undefined_concept to make it a little more obvious what is going on. I am currently considering adding a coordinate_concept and coordinate_traits to the library because for 32-bit integer we would like to use 64-bit integer for area types and double for Euclidean distance, but for floating point coordinates we would just use the coordinate type for those. With the need for numerical robustness of arbitrary geometry algorithms looming the use of more advanced coordinate data types looks likely, which might necessitate traits. As always, I welcome any feedback that will help me improve the library and make it conform to boost standards/expectations for eventual review when I have completed the re-write. You can find the up-to-date re-write of the library in sandbox/gtl. Thanks, Luke

2 2

A few questions about Phoenix, Boost.Bind, and FC++
by Daniel Walker 08 Jun '08

08 Jun '08

Hello, With all the recent discussion about Functional Programming, I thought I'd take a closer look at some of the FP libraries that I haven't really used before, and I started last night by browsing through Phoenix's documentation. This led me to a few questions: Does Phoenix allow side-effects or is it "pure" functional like Fusion and FC++? Does it allow modification of arguments by reference - either builtin references or reference_wrapper? What is the status of the Phoenix msvc port? The documentation seems to indicate that it's possible but not necessarily forthcoming. Is there any immediate plan to make Phoenix interoperable with the coming standard library's std::bind, std::placeholders, std::is_bind_expression, and std::is_placeholder? Regarding Boost.Bind, will it eventually support is_bind_expression? I mean will it treat types for which is_bind_expression is true as full-blown bind sub-expressions? (I know it's a matter of time and work and testing to get this, and I'd be willing to help out, write test cases, whatever's needed.) Also, Peter, weren't you thinking of proposing operator overloads for bind expressions in C++0x? I think you have some already implemented in Boost.Bind. Do you think operator overloads are likely to make it into the final draft? Finally, I noticed the Phoenix documentation cites BLL and FC++ as major influences. I'm fairly familiar with BLL (with its implementation and usage, rather than its history) but not at all familiar with FC++. I hope at least to skim through the documentation over the next few days. However, one thing I noticed right away while reading about Phoenix was that it borrows the term rank-2 polymorphic function from FC++. I'm just learning this terminology, so I'm trying to gain confidence that I understand it. From briefly skimming (McNamara, 2000) in JFP, I'm under the impression that a rank-2 polymorphic function can only have two parametric types, i.e. two template parameters. So, for example, std::make_pair is rank-2 polymorphic, and FC++ has functions that will produce pairs when called with two different types. A rank-n polymorphic function can have arbitrarily many different template parameters; an example would be std::make_tuple. Doesn't Phoenix actually support rank-n polymorphism? For example, isn't the following a rank-3 polymorphic function in Phoenix and couldn't you write similar function objects for higher ranks? struct tupler_ { template<class> struct result; template<class F, class T0, class T1, class T2> struct result<F(T0,T1,T2)> { typedef tuple<T0,T1,T2> type; }; template<class T0, class T1, class T2> tuple<T0,T1,T2> operator()(T0 t0, T1 t1, T2 t2) const { return make_tuple(t0,t1,t2); } }; phoenix::function<tupler_> tupler; One last thing - I noticed that FC++ was submitted for inclusion in Boost a few years back. What ever happened with that? Thanks in advance! Daniel Walker

7 17

Property Tree Library status?
by Jonathan Biggar 08 Jun '08

08 Jun '08

Is this finally going to make it into a release? 1.36? -- Jon Biggar Floorboard Software jon(a)floorboard.com jon(a)biggar.org

3 4

Multisignature function v1.2.2
by Marco Costalba 08 Jun '08

08 Jun '08

Hi all, I have upload in Vault the file msf-1.2.2.zip with a new version of multi signature boost::function extension New in this version is a workaround for a rare compile error in MSVC due to a bug in the compiler that requires a using::operator() declaration also in a class where there are no other operator() defined ! I have also added in the examples a runtime object factory, i.e. where the key to query the factory for an object of a chosen class is a runtime variable, not a compile time constant or something similar. Factory allows to pass any number and type of arguments to ctor of the chosen class. Functionality is similar to factory_24_2_08.zip already in Vault, but this time I've used all the arsenal of boost, namely: fusion, switch (in sandbox, the Vault version is broken), mpl and of course the multi signature function (MSF) that is the core of the factory. Due to this I think the implementation is the most minimal, clean and simple that I know. A peculiarity of this implementation is that MSF uses its polymorphic function object support to bind c'tors wrappers in a naturally and very clean way. This is a good example of how it is possible to take advantage of polymorphic function support in real code. Thanks Marco

1 0

[property tree] code conversion
by Johan Råde 07 Jun '08

07 Jun '08

The rapid xml parser used by the property tree reads the input stream using stream buffer iterators. This means that if the stream has been imbued with a locale with a code conversion facet, then the code conversion facet is never invoked. It may be better if the stream were read using stream iterators. --Johan Råde

1 0

[future] Early draft of wait for multiple futures interface
by Johan Torp 07 Jun '08

07 Jun '08

We've been discussing the need to implement a mechanism to wait for multiple futures in a separate thread: www.nabble.com/Review-Request%3A-future-library-%28Gaskill-version%29-to166… I've come up with some interfaces which I find intuitive and useful. I've never implemented thread waiting, so please let me know if you think something like this is viable. ------------------------------ Proposal ------------------------------ A future can be constructed and thereafter wait on four different "future conditions" * a promise * a future_switch * a future_barrier * another future Each condition has a specified return type and the futures you create from it must match this type. They all have the same possible states - isn't ready, has value or an expression. I have left these and alot of other details out of the interface below for conciseness. ------------------------------ Interface drafts ------------------------------ /// Future condition which is ready when any of the added conditions is ready. Has an arbitrary return-type template<class ReturnType> class future_switch { public: /// Direct return template<class FutureConditionWithMatchingReturnType> void add_case(FutureConditionWithMatchingReturnType f); /// Possibility to perform custom functor, bind state, perform some logic etc before fulfilling it's condition template<class FutureCondition, class FutureTypeToReturnTypeFunctor> void add_case(FutureCondition f, FutureTypeToReturnTypeFunctor case); /// Only valid in is_ready state. Removes last fulfilled futurecondition and enables new futures to be /// constructed. Existing futures will have copied the value or exception already and will still work. void remove_ready_case(); bool empty() const; }; /// Future condition which is ready when all added futures are. /// This interface is less promising and has some flaws. Maybe you can get inspired by it though. template<class ReturnType> class future_barrier { public: future_barrier(const function<ReturnType()>& onReady); template<class FutureCondition> void add_condition(const future<FutureType>& f); }; ------------------------------ Example usage ------------------------------ template<class T> future_switch<T> operator||(const future<T>& lhs, const future<T>& rhs) { future_switch<T> sw; sw.add_case(lhs); sw.add_case(rhs); return sw; } template<class T> T and_impl(const future<T>& lhs, const future<T>& rhs) { return lhs.get() && rhs.get(); } template<class T> future_barrier<T> operator&&(const future<T>& lhs, const future<T>& rhs) { // Rather large runtime insecurity, we might forget to add lhs and rhs as conditions to the barrier future_barrier b(bind(&and_impl, lhs, rhs)); b.add_condition(lhs); b.add_condition(rhs); return b; } // This is an experimental use case for using switch as a dynamic set of future conditions // It handles three future responses and calls the three functions on the next lines bool handle_response_a(ResponseA r); bool handle_response_b(ResponseB r); bool handle_response_c(ResponseC r); void handle_pending_requests(const future<ResponseA>& a, const future<ResponseB >& b, const future<ResponseC >& c) { future_switch<void> sw; sw.add_case(a, &handle_repsonse_a); sw.add_case(b, &handle_repsonse_b); sw.add_case(c, &handle_repsonse_c); bool all_ok = true; while (!sw.empty()) { // Will automatically remove ok:ed futures from sw future<bool> next_response_was_ok(sw); bool all_ok = all_ok && next_response_was_ok.get(); sw.remove_ready_case(); } return all_ok; } ------------------------------ Some comments ------------------------------ There is a lot to improve here. I'd appreciate it if we could focus on determining whether this is a viable solution and the way we want to go before diving into details. These abstractions has the following property: A Users can compose conditions and poll them without the need of waiting. B We do not need to spawn extra threads for waiting - we only wait on the "outmost" future C Threads needn't awake and poll readiness - assuming the and/or logic is handled by waitingcode. D No "user logic" from the future-blocking threads propagate to the promise-fulfilling thread. E It's possible to implement efficient laziness by keeping readiness/waiting logic internal in the future library "wait for all" can be implemented without adding future_barrier, by simply calling wait() on all futures. We lose property A and E for "wait for all" if we do it this way. The blocking thread will awake unnecessarily many times. Property C means promise-fullfilling threads need to do some basic and/or logic. I think this can be implemented in a safe and efficient manner, O(log(N)) for barrier/all and O(1) for switch/any. I also think it is much preferable to waking and switching to future-blocking threads which re-check readiness conditions. Note property D. Whatever mechanism we choose I think it's desirable to be able to easily "lift" existing functions to futures; R foo(A1 a1, A2 a2, A3 a3) should be easily rewritable as; future<R> foo(future<A1> a1, A2 a2, future<A3> a3) // Some parameters need not be lifted Johan -- View this message in context: http://www.nabble.com/-future--Early-draft-of-wait-for-multiple-futures-int… Sent from the Boost - Dev mailing list archive at Nabble.com.

8 43

Polymorphic function (was: Multi signature boost::function v1.0)
by Marco Costalba 07 Jun '08

07 Jun '08

On Sat, May 31, 2008 at 8:23 AM, Marco Costalba <mcostalba(a)gmail.com> wrote: > >> Sorry for the delay. I just put it on vault. > > I'm just back after a week off-line due to my job. This is a great > news, I'm going to download right now. > > More to come... > Hi Daniel, I have downloaded and tested Function Objects/polymorphic_function.zip from boost vault. Very nice stuff! really! a lot of new tricks to learn ;-) I have immediately replaced boost::function with boost::functional::polymorphic_function in msf-1.2 (also under vault, but in base directory) and gave it a spin. Unfortunately I was not able to make it work. Some boost::function API, necessary for msf-1.2, are not supported: operator==(), empty(), clear(), contains() I said, ok not a biggie, I can just use polymorphic_function::target() and build something similar myself. But what stopped me is that target() does not seem to work. int foo1(char) { return -1; } boost::functional::polymorphic_function<int(char)> poly_fun(foo1); poly_fun.target(); // compile error here ! Under gcc 4.2.3 I have test.cpp: In function 'int main(int, char**)': test.cpp:88: error: no matching function for call to 'boost::functional::polymorphic_function<int ()(char), false>::target()' I have checked the code and especially the SFINAE conditions in RANK_N_ACCESSOR, but I failed to understand why it doesn't work. Thanks Marco

2 3