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

GSoC 2012
by sultana rashid 09 Feb '12

09 Feb '12

Hello all, I am Sultana Rashid,a CSE student.As a computer engineering student I have good programming skills and am familiar with many new tools and technologies.I keep an eye on Boost libraries for almost last one year. Boost libraries are very useful and rich.But I found some new things can be added to it while exploring the libraries as Graph,Math,Geometry etc. I saw that Boost'd like to participate again in GSoC and I wish to work with the organization as a developer.Can I propose my ideas here just now? Thanking you, Sultana rashid. [1] http://lists.boost.org/Archives/boost/2012/02/190176.php

3 2

[interest] Type Aspects and compile-time constraints
by Beren Minor 09 Feb '12

09 Feb '12

Hi everyone, I would like to introduce a project I'm working on and a mechanism that emerged from the projects needs and, as far as I could feel, may be useful in a general case. By lack of words (let say), I named this Type Aspects, as an analogy to Type Traits. The project I'm working on, for quite a while now, is about creating a statically, strongly typed, compile-time checked and heavily simplified interface to OpenGL. I know that "Boost.OpenGL" is a subject that has been discussed many times on this list and that every time the outcome of the discussion is that Boost is not going to support a mere wrapper around some existing API. Well, I perfectly understand this and I'm not looking for the possibility to have this included in Boost. The project itself and its functional goal isn't actually the subject of my post, but it is a good introduction to type aspects, as it is what led me writting this as a general supporting mechanism. So, to introduce the idea, if some people do not know OpenGL, it is a typical C API, full of enumerations (well not even enumerations, integers preprocessor constants), loosely typed, and full of bloated function names with fixed number of parameters of various flavors. Obviously, every single function call takes an average of two of those constants as parameters. And obviously most combinations of values are leading to undefined operations, whithout having anyone complaining about anything, except a black window on your screen and a poor-man error code whenever there is one. Probably the most hideous nightmare you could ever have to use as a programmer. That was my observation. So I decided to take all these constants, that any OpenGL programmer is usually giving directly to feed the function calls, as parameters, to take all these functions, wrapp them all, rename related functions to use nice C++ overloading... but above all, convert these constants as types. This way I was able to write compile time constraints, checking the combination of constants provided to these functions. The goal was (and I must admit that it's working pretty much fine), that I would certainly be able to write the constraints described in the OpenGL specifications in term of templated C++ type constraints, making good use of static assertions with nice messages referring to the spec itself, and of metaprogramming techniques to achieve this. Then it appeared, after struggling a while trying to abstract all the data in use in OpenGL, that I could extract some fundamental properties of all these types and that the constraints described in the specifications would be experessed as simple and clear constraints on these properties. That's what I defined as Type Aspects. Let say OpenGL is able to handle 10 different type of textures. These types are different by the way color components are packed together, by their order, by their precision or numeric type (floating point or integral). All these are aspects of the texture type. Some OpenGL function might then be used to load data to a given texture, but depending on the texture type, it will only accept a certain type of source data. For example, integral textures only accept integral data, whereas floating point textures accept any data. This would be implemented as a simple constraint checking that the "Numeric" aspect of the source data type is compatible with the "Numeric" aspect of the texture type. Moreover, this also allows the user to provide a limited set of these aspects that he desires to have, and not others that he doesn't care of, and the compiler would be able to resolve the more relevant type to use depending on the use case. Type Aspects, as I defined it for the use in my projects, are like axises describing a type, every axis taking a value in a given set of possible values. This is not limited: as these values are types as well, they can also have aspects and be described. As an example that's what I did to describe the "Numeric" aspects of OpenGL data. Numeric aspect takes a value in a given set of predefined numeric archetypes. Every single archetype then has some values the three aspects describing a number type: its signness (signed, unsigned, any), its integralness (floating, fixed point, integral, boolean, any), and its width (number of bits/bytes, any). Well to conclude, I can see that this is certainly not related to OpenGL anymore and that this is a general mechanism that can be used to describe types and create relationships between types. I don't know if it is a subject that already has been discussed or if there's anything like that in Boost already (I don't think so but I don't know all the Boost libraries by heart). Do you see any interest in this kind of thing? Do you think that this could be something that worth working on deeper? TL;DR: 1. OpenGL sucks, I implemented compile-time constraints wrapping the functions calls. 2. Thinking about compile-time constraints made me qualify the types in use with a general mechanism describing the type's "aspects". 3. Aspects are axises and a given set of predefined values on these axises using which a type and its properties can be described. 4. Constraints can then be easily written as MPL checks on aspects axises and values as long as type aspects are formalized. 5. Does it already exist? Is that interesing? Should I try to go deeper in the abstraction? Kind regards, -- Beren Minor

3 7

Re: [boost] [optional] generates unnessesary code for trivial types
by Hite, Christopher 09 Feb '12

09 Feb '12

On Tuesday, February 07, 2012 17:00:04 Andrey Semashev wrote: > Do I understand it correctly that optional_with_traits is an advanced > replacement for optional? If so, will the good old optional be optimized? No, optional will be ("isA") optional_with_traits. It's just a work around. I'd prefer to redefine optional: template<typename T, typename Traits=optional_traits<T> > class optional; That might in rare cases it could break user code like: mpl::quote1<optional> Personaly I doubt that this is such an issue, but have the best of both worlds I can define a temporary "optional_with_traits" which when boost goes to 2.0 we could deprecate and add the parameter to optional. template<typename T, typename Traits=optional_traits<T> > class optional_with_traits; template<typename T> class optional : public optional_with_traits<T> {...}; Do we gurantee boost users that templates will never add default parameters? > BTW, I would really like to see optional< T& > optimized to store T* > internally. I'm going to say something provacative here. I agree with Lucanus. I see no reason for optional<T&>. As far I can tell you could use a T*. The only justification I can think of is on system without memory protection you can build checks into operator*(). Maybe if you're mixing code with old libraries where T* might imply ownership you might use optional<T&> to imply no ownership and some temporary validity. Perhaps we should define a new "smart pointer" called dumb_ptr<T> which can't be assigned into auto_ptr,unique_ptr,shared_ptr, or any pointer type which implies ownership. Maybe I'm missing something, but I don't see the justification. Chris

5 4

Re: [boost] [optional] generates unnessesary code for trivial types
by Andrzej Krzemienski 09 Feb '12

09 Feb '12

> optional< T& > is a useful thing when you want to apply operators (such as > relation operators or streaming) to the referred value. In generic code you > don't have to specialize for pointers to do the right thing. I'm going to use > this property in my Boost.Log library. Andrey, would you mind giving us a short example of how you want to use an optional reference? I am in the middle of designing the new optional interface for TR2, and came to the conclusion that in order to avoid counter-intuitive semantics for optional reference assignment, I had better remove it at all; that is, optional references are to be limited: they should provide no assignment. You could still use optional values and optional references in generic code but with reduced interface: template <typename T> // T is a ref or a value void use( std::tr2::optional<T> opt, T nval ) { if (opt) { std::cout << *out; // fine *opt = nval; // fine, assigning T's not optionals opt = nval; // invalid if T is a ref opt = opt; // invalid if T is a ref } if (needToRebindAReference()) { opt.emplace(nval); // valid - always rebinds } }; Would such a limited interface as I described above be enough for your generic usage of optional? Regards, &rzej

2 1

Simple boost polygon boolean OR doesn't work: help needed
by Praveen Vs 09 Feb '12

09 Feb '12

Hi, Below is code for doing a boolean OR operation. I'm not sure of the mistake I'm doing here. The output generated is wrong. I'm not using the operator+() becaue of the compile issue on MSVC2010. #include <boost/polygon/polygon.hpp> namespace gtl = boost::polygon; using namespace gtl; using namespace boost::polygon::operators; using namespace std; typedef gtl::polygon_set_data<double> CPolygonSet; typedef gtl::polygon_data<double> CPolygon; static void test_boost_polygons() { CPolygonSet polyset1, polyset2, rset; CPolygon polygon1, polygon2; typedef gtl::polygon_traits<CPolygon>::point_type CPoint; vector<CPoint> poly1Points, poly2Points; poly1Points.push_back(gtl::construct<CPoint>(0.0000, 0.0000)); poly1Points.push_back(gtl::construct<CPoint>(50.0000, 50.0000)); poly1Points.push_back(gtl::construct<CPoint>(100.0000, -50.0000)); poly1Points.push_back(gtl::construct<CPoint>(50.0000, -50.0000)); poly2Points.push_back(gtl::construct<CPoint>(50.0000, 0.0000)); poly2Points.push_back(gtl::construct<CPoint>(100.0000, 50.0000)); poly2Points.push_back(gtl::construct<CPoint>(150.0000, -50.0000)); polygon1.set(poly1Points.begin(), poly1Points.end()); polygon2.set(poly2Points.begin(), poly2Points.end()); vector<CPolygon> polygonArray1, polygonArray2; polygonArray1.push_back(polygon1); polygonArray2.push_back(polygon2); polyset1.insert(polygonArray1.begin(), polygonArray1.end()); polyset2.insert(polygonArray2.begin(), polygonArray2.end()); gtl::arbitrary_boolean_op<CPolygonSet::coordinate_type> bop; bop.execute(rset, polyset1.begin(), polyset1.end(), polyset2.begin(), polyset2.end(), 0); vector<CPolygon> polys; rset.get(polys); for(unsigned int i = 0; i < polys.size(); ++i) { CPolygon::iterator_type it = polys[i].begin(); for(; it != polys[i].end(); ++it) { cout<<"("<<(*it).x()<<", "<<(*it).y()<<")"<<endl; } } } void main() { test_boost_polygons(); } -- -praveen

2 6

GSoC idea on Geometry library
by sultana rashid 08 Feb '12

08 Feb '12

Hello, I have several ideas on some libraries.Today I present on Geometry library. *1.Conics:* I did not found *conics* in Geometry library.Ellipse,parabola,hyperbola concept is very useful in geometry.Can Boost add some functionality of conics? as: 1.Area determination of conics 2.Foci determination 3.Major-minor axis 4.Determine whether a point on a conic 5.Focal length,center determination etc... etc... Or at least add something on Conic in Concept section? If this idea seems useful to you,please let me know.I will describe details on what I want to do about Conic section in Geometry library. *2. **Convex HUll: *There is only one algorithm implemented .We can implement *Gift wrapping*<http://en.wikipedia.org/wiki/Gift_wrapping_algorithm> *O*(*nh*) ; *Divide and conquer* *O*(*n* log *n*) or *Chan's algorithm*<http://en.wikipedia.org/wiki/Chan%27s_algorithm> *O*(*n* log *h*). Jarvis march ,Chan's algo are output sensitive.These are useful when we can assume that the result will not be too large. Thanking you, Sultana

3 2

Manually marking noexcept for a constructor
by Daryle Walker 08 Feb '12

08 Feb '12

I realized that my proposed C++11 update for base_from_member should propagate noexcept. But how do I manually specify the noexcept status of an inner constructor? (Beta versions of C++11 may just have core language changes but not the library changes, so I shouldn't rely on is_nothrow_XXX_constructible just like not relying on std::forward.) I originally thought of: class MyType{ MyInnerType x;public: MyType() noexcept( noexcept(MyInnerType()) );}; This expression includes the inner default constructor call, but it also secretly includes a destructor call (for MyInnerType), and therefore includes it in the calculations! But how about: class MyType2{ MyInnerType x;public: MyType2() noexcept( noexcept(new (std::nothrow) MyInnerType()) );}; Hopefully this, or something like it, includes the constructor call, without calling a destructor. I think the C++11 version of nothrow_t-new is marked noexcept, and I hope the complete new call doesn't hide the constructor call. Daryle W.

1 0

MSVC 2010 Compile error for polygon_set_data
by Praveen Vs 08 Feb '12

08 Feb '12

Hi, Below code gives a compile error in MSVC2010. Any ideas whats the issue? #include <boost/polygon/polygon.hpp> namespace gtl = boost::polygon; using namespace gtl; using namespace boost::polygon::operators; using namespace std; typedef gtl::polygon_set_data<double> CPolygonSet; static void test_boost_polygons() { CPolygonSet polyset1, polyset2, rset; rset = polyset1 + polyset2; } void main() { test_boost_polygons(); } Error: ===== \boost\polygon\polygon_45_set_data.hpp(1458): error C2825: 'iT': must be a class or namespace when followed by '::' 1>\boost\polygon\polygon_45_set_data.hpp(1524) : see reference to function template instantiation 'void boost::polygon::get_error_rects_shell<cT,const boost::polygon::point_data<T>*>(cT &,cT &,iT,iT)' being compiled 1>with 1>[ 1> cT=stlp_std::vector<boost::polygon::rectangle_data<Unit2>>, 1> T=double, 1> iT=const boost::polygon::point_data<double> * 1>] 1>\boost\polygon\polygon_45_set_data.hpp(1621) : see reference to function template instantiation 'void boost::polygon::get_error_rects<stlp_std::vector<_Tp>,boost::polygon::polygon_45_with_holes_data<T>>(cT &,cT &,const pT &)' being compiled 1>with 1>[ 1> _Tp=boost::polygon::rectangle_data<Unit2>, 1> T=double, 1> cT=stlp_std::vector<boost::polygon::rectangle_data<Unit2>>, 1> pT=boost::polygon::polygon_45_with_holes_data<double> 1>] 1>\boost\polygon\detail/polygon_set_view.hpp(102) : see reference to function template instantiation 'void boost::polygon::polygon_45_set_data<Unit>::applyAdaptiveBoolean_<0>(boost::polygon::polygon_45_set_data<Unit> &,const boost::polygon::polygon_45_set_data<Unit> &) const' being compiled 1>with 1>[ 1> Unit=double 1>]

1 1

[utility] Don't mind if I "change" base_from_member?
by Daryle Walker 08 Feb '12

08 Feb '12

Since the suggested trick of using GCC (4.6) from MacPorts as a Darwin GCC worked, I've tried out my first C++11 update: base_from member. It's very straightforward. //$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$Index: boost/utility/base_from_member.hpp===================================================================--- boost/utility/base_from_member.hpp (revision 76917)+++ boost/utility/base_from_member.hpp (working copy)@@ -1,6 +1,6 @@ // boost utility/base_from_member.hpp header file --------------------------// -// Copyright 2001, 2003, 2004 Daryle Walker. Use, modification, and+// Copyright 2001, 2003, 2004, 2012 Daryle Walker. Use, modification, and // distribution are subject to the Boost Software License, Version 1.0. (See // accompanying file LICENSE_1_0.txt or a copy at // <http://www.boost.org/LICENSE_1_0.txt>.)@@ -10,6 +10,7 @@ #ifndef BOOST_UTILITY_BASE_FROM_MEMBER_HPP #define BOOST_UTILITY_BASE_FROM_MEMBER_HPP +#include <boost/config.hpp> #include <boost/preprocessor/arithmetic/inc.hpp> #include <boost/preprocessor/repetition/enum_binary_params.hpp> #include <boost/preprocessor/repetition/enum_params.hpp>@@ -68,12 +69,19 @@ protected: MemberType member; +#if defined(BOOST_HAS_RVALUE_REFS) && defined(BOOST_HAS_VARIADIC_TMPL)+ template <typename ...T>+ explicit BOOST_CONSTEXPR base_from_member( T&& ...x )+ : member( static_cast<T&&>(x)... ) // some libs don't have std::forward+ {}+#else base_from_member() : member() {} BOOST_PP_REPEAT_FROM_TO( 1, BOOST_PP_INC(BOOST_BASE_FROM_MEMBER_MAX_ARITY), BOOST_PRIVATE_CTR_DEF, _ )+#endif }; // boost::base_from_member //$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ I don't use std::forward because I've heard that some beta C++11 modes implement the core-language ideas needed (r-value references) but not the library changes (i.e. std::move and std::forward), and I didn't want to find (and conditionally?) #include another header. What I got will work just fine, right? Do the constructors need any marking besides "explicit" and "constexpr"? (I believe the "constexpr" will be safely ignored if the forwarded constructor isn't "constexpr" itself without a compile-time error. It was designed that way, right?) I'll just update the documentation and commit the change, then. Daryle W.

1 0

docs on new build system?
by Neal Becker 07 Feb '12

07 Feb '12

I am testing 1_49_0_beta1. I see my usual build failed, saying 'warning: mismatched versions of Boost.Build engine and core'. Taking a wild guess, tried cd tools/build/v2 sh ./bootstrap.sh sudo ./b2 install --prefix=/usr/local I see I now have a new bjam, and something called 'b2'. Should I be reading some new docs on how to use this stuff? Are there some docs? My old build procedure: bjam -sHAVE_ICU=1 -sEXPAT_INCLUDE=/usr -sEXPAT_LIBPATH=/usr/lib64 -- layout=tagged threading=single,multi stage Seems to be proceeding normally (so far)

2 1