- Boost - lists.boost.org

[ptr_container] Fix for Tru64/CXX
by Markus Schöpflin 09 Jun '08

09 Jun '08

Hello, attached patch contains a fix for Tru64/CXX, which somehow seems to have troubles with the following code in the class associative_ptr_container: using base_type::begin; using base_type::end; using base_type::cbegin; using base_type::cend; It looks like the compiler doesn't consider these using declarations when performing overload resolution for one of these methods. The fix is easy, it simply adds inline definitions for these methods. Can this patch please be applied? Regards, Markus Index: detail/associative_ptr_container.hpp =================================================================== --- detail/associative_ptr_container.hpp (revision 46270) +++ detail/associative_ptr_container.hpp (working copy) @@ -18,6 +18,7 @@ #endif #include <boost/ptr_container/detail/reversible_ptr_container.hpp> +#include <boost/detail/workaround.hpp> namespace boost { @@ -347,10 +348,42 @@ } public: +#if BOOST_WORKAROUND(__DECCXX_VER, BOOST_TESTED_AT(70190006)) + iterator begin() + { + return base_type::begin(); + } + + const_iterator begin() const + { + return base_type::begin(); + } + + iterator end() + { + return base_type::end(); + } + + const_iterator end() const + { + return base_type::end(); + } + + const_iterator cbegin() const + { + return base_type::cbegin(); + } + + const_iterator cend() const + { + return base_type::cend(); + } +#else using base_type::begin; using base_type::end; using base_type::cbegin; using base_type::cend; +#endif protected: local_iterator begin( size_type n )

2 1

[iterators][range] size compile failure in 1.35
by Jeff Flinn 09 Jun '08

09 Jun '08

I'm moving from 1.34.1 to 1.35.0 The following compiles in 1.34.1 and fails in 1.35.0 on MSVC 8. Any thoughts on how to correct this? #include <vector> #include <boost/bind.hpp> #include <boost/iterator/filter_iterator.hpp> #include <boost/range/iterator_range.hpp> template<class Predicate, class Range> boost::iterator_range<boost::filter_iterator<Predicate, typename Range::iterator> > filteredRange(Range& range, Predicate p) { return boost::make_iterator_range( boost::make_filter_iterator<Predicate>(p, range.begin(), range.end()), boost::make_filter_iterator<Predicate>(p, range. end(), range.end())); } bool filt(int ) { return true; } int main() { std::vector<int> c; filteredRange(c, boost::bind(&filt, _1)).size(); return 0; } And the errors are: 1>IteratorAndRangeSizeTest.cpp 1>f:\gene_codes\external_libraries\boost_1_35_0\boost\iterator\iterator_adaptor.hpp(225) : error C2027: use of undefined type 'boost::STATIC_ASSERTION_FAILURE<x>' 1> with 1> [ 1> x=false 1> ] 1> f:\gene_codes\external_libraries\boost_1_35_0\boost\iterator\iterator_adaptor.hpp(348) : see reference to function template instantiation 'void boost::detail::iterator_adaptor_assert_traversal<boost::bidirectional_traversal_tag,boost::random_access_traversal_tag>(void)' being compiled 1> f:\gene_codes\external_libraries\boost_1_35_0\boost\iterator\iterator_facade.hpp(554) : see reference to function template instantiation '__w64 int boost::iterator_adaptor<Derived,Base,Value,Traversal>::distance_to<boost::filter_iterator<Predicate,Iterator>,Iterator,boost::use_default,boost::bidirectional_traversal_tag,boost::use_default,boost::use_default>(const boost::iterator_adaptor<Derived,Base,Value,Traversal> &) const' being compiled 1> with 1> [ 1> Derived=boost::filter_iterator<boost::_bi::bind_t<bool,bool (__cdecl *)(int),boost::_bi::list1<boost::arg<1>>>,std::_Vector_iterator<int,std::allocator<int>>>, 1> Base=std::_Vector_iterator<int,std::allocator<int>>, 1> Value=boost::use_default, 1> Traversal=boost::bidirectional_traversal_tag, 1> Predicate=boost::_bi::bind_t<bool,bool (__cdecl *)(int),boost::_bi::list1<boost::arg<1>>>, 1> Iterator=std::_Vector_iterator<int,std::allocator<int>> 1> ] 1> f:\gene_codes\external_libraries\boost_1_35_0\boost\iterator\iterator_facade.hpp(852) : see reference to function template instantiation '__w64 int boost::iterator_core_access::distance_from<Derived1,Derived2>(const Facade1 &,const Facade2 &,boost::mpl::true_)' being compiled 1> with 1> [ 1> Derived1=boost::filter_iterator<boost::_bi::bind_t<bool,bool (__cdecl *)(int),boost::_bi::list1<boost::arg<1>>>,std::_Vector_iterator<int,std::allocator<int>>>, 1> Derived2=boost::filter_iterator<boost::_bi::bind_t<bool,bool (__cdecl *)(int),boost::_bi::list1<boost::arg<1>>>,std::_Vector_iterator<int,std::allocator<int>>>, 1> Facade1=boost::filter_iterator<boost::_bi::bind_t<bool,bool (__cdecl *)(int),boost::_bi::list1<boost::arg<1>>>,std::_Vector_iterator<int,std::allocator<int>>>, 1> Facade2=boost::filter_iterator<boost::_bi::bind_t<bool,bool (__cdecl *)(int),boost::_bi::list1<boost::arg<1>>>,std::_Vector_iterator<int,std::allocator<int>>> 1> ] 1> f:\gene_codes\external_libraries\boost_1_35_0\boost\range\iterator_range.hpp(278) : see reference to function template instantiation '__w64 int boost::operator -<Derived,int,boost::bidirectional_traversal_tag,int&,__w64 int,Derived,int,boost::bidirectional_traversal_tag,int&,__w64 int>(const boost::iterator_facade<Derived,Value,CategoryOrTraversal,Reference,Difference> &,const boost::iterator_facade<Derived,Value,CategoryOrTraversal,Reference,Difference> &)' being compiled 1> with 1> [ 1> Derived=boost::filter_iterator<boost::_bi::bind_t<bool,bool (__cdecl *)(int),boost::_bi::list1<boost::arg<1>>>,std::_Vector_iterator<int,std::allocator<int>>>, 1> Value=int, 1> CategoryOrTraversal=boost::bidirectional_traversal_tag, 1> Reference=int &, 1> Difference=__w64 int 1> ] 1> f:\gene_codes\external_libraries\boost_1_35_0\boost\range\iterator_range.hpp(276) : while compiling class template member function '__w64 int boost::iterator_range<IteratorT>::size(void) const' 1> with 1> [ 1> IteratorT=boost::filter_iterator<boost::_bi::bind_t<bool,bool (__cdecl *)(int),boost::_bi::list1<boost::arg<1>>>,std::_Vector_iterator<int,std::allocator<int>>> 1> ] 1> f:\dev\iteratorandrangesizetest\iteratorandrangesizetest.cpp(24) : see reference to class template instantiation 'boost::iterator_range<IteratorT>' being compiled 1> with 1> [ 1> IteratorT=boost::filter_iterator<boost::_bi::bind_t<bool,bool (__cdecl *)(int),boost::_bi::list1<boost::arg<1>>>,std::_Vector_iterator<int,std::allocator<int>>> 1> ] Thanks, Jeff

4 4

SF 2008 Community awards
by joaquin＠tid.es 09 Jun '08

09 Jun '08

Hello, I just received an invitation to nominate a project for SF 2008 Community awards and naturally decided to go for Boost in the category of Best Tool or Utility for Developers. Once in the nomination page I clicked "Search", typed Boost, and now comes the problem: SF locates two different Boost projects: Name: Boost, URL: http://boost.org Name: Boost C++ Libraries, URL: http://sourceforge.net/projects/boost/ Of course both projects are actually the one and only Boost, but I wonder whether we should agree on which one to formally nominate so that our voting force does not get split. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

6 8

[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