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

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

10 Feb '12

> I have a question though. Why prohibit opt = opt assignment? It looks > quite safe and has a fairly obvious behavior. If I have an optional > reference as a member of my class, the lack of assignment in optional > would force me to define a custom assignment operator for my class. > This seems to be an unnecessary requirement. Also, in the source code > I dealt with I often saw people writing something like opt = > optional<T>() to clear the value. This would break with references for > no apparent reason. First, let me show why opt = nval; is controversial. Current semantics for boost::optional<T&> is to rebind on assignment, which means that in the following code: int i = 1; int j = 2; optional<int&> oi = i; oi = j; The effect of this program is that i remains 1, j remains 2 and oi holds a reference to j. This is surprising to those that think of optional as delayed initialization. I lean towards disabling opt = opt because it is very similar to opt = nval; int i = 1; int j = 2; optional<int&> oi = i; optional<int&> oj = j; i = j; The effect here is that i remains 1, j remains 2 and oi and oj both hold a reference to j. You may find it less surprising but if you think of optional reference as a regular reference that is initialized a bit later, the behavior is not what you would expect. Note that if you store a normal reference to int as class member, you already have to write your assignment yourself. changing a normal reference to an optional reference should not come as something irregular.

3 2

Re: [boost] [git] neglected aspects
by David A. Greene 09 Feb '12

09 Feb '12

Thomas Heller <thom.heller(a)googlemail.com> writes: > On 02/08/2012 07:30 AM, Steven Samuel Cole wrote: >> A quick read on submitting bugs on boost.org, svn co yadi yadi, fix the >> typos locally. Of course I don't have write privileges to the repo, so >> the best I can do for now is create a patch and attach that to a bug >> report. Within minutes, someone takes care of the bug, comments and >> takes ownership. Excellent! Smithers, money fight! > > Great! Now with something like github you create your own fork, push > to that and eventually create a pull request and wait until it gets > applied ... as you described. The process didn't change. You just > named the steps differently. No. The fundamental part you're missing is that the source control utility (git in this case) handles it for you. There is no need to go outside the sournce control utility to make additional changes. >> What are my options now ? Revert my changes, base the new ones on the >> head revision and send another patch ? Create a new patch file and >> manually remove the diffs of the old changes I already sent ? How will >> the upstream maintainer know which changes are based on what version ? > > Simple. Update the bug you already filed with the patch containing all > fixes. What would be the options with git? Update the pull request? > Again, same thing, different name. No, not the same thing. Again, this is all happening within the source control utility. Steven is relating real issues with svn. I have encountered them many times. I have found that git eliminates them. >> Also, I notice a few other things that in my opinion could be done >> better to facilitate adoption of the iostreams library. > So with git you pushed them to your personal fork. Over time, your > fork and the upstream version eventually diverge. You have to maintain > your changes. Same thing when the changes lurk on your local svn > working. There are several advantages to a git fork over an svn local workarea. - You can make a new branch for each feature, keeping the code for logical features separate. You can submit them whenever you want, in whatever order you want. - You can share the forks and branches with others. - You can massage the fork/branch over time to respond to review feedback, all supported directly by the source control utility. IME, git rebase -i and git add -i are killer features for the code review process. >> A couple of hours later: I get an email from boost bugs/svn; the >> upstream maintainer has committed my changes. However, I actually >> receive not one, but two emails, because the upstream guy chose to split >> my patch into changes on documentation and changes on source code (which >> presumably required extra work on his part). > > Frankly, I don't see how this would change with git. Actually, git would make things easier for the maintainer here. Either he/she could request the submitter to break up the patch, which is easily done with rebase -i/add -i or the maintainer could use the same tools to do it him/herself. >> I do an svn up and now have to deal with conflicts between my local >> changes and the new commits: I make a note of my second set of changes >> and overwrite my local files with the new repo versions, then bring the >> second set back in. > > Same again. How is this significantly different to what you'd do with git? It's all within the utility. There's no need to back out patches (the second set of changes in this case) manually from the source and re-apply them manually after update. Because each feature is in its own (local) branch, updates of one branch don't conflict with unrelated features in other branches. Yes, you'll need to resolve conflicts but it's much less messy with this kind of separation. >> Uff! That's a lot of work just to fix some typos! And these are just >> cosmetic issues in discrete chunks that do not require any testing; >> contributing changes to source code would take even more effort and more >> caution - build and test on several platforms, peer review, etc. > > Right, all that wouldn't change with having git as the tool of choice. It does, dramatically. git actually directly supports workflows that developers use when working on large projects. svn does not and there are all sorts of hacks out there to work around those problems. I've written a fair number myself. I don't need any of them with git. >> I don't have to wait for the first set of changes to be merged into >> the trunk before I resync, resolve conflicts and base the second >> set on the new head revision; I simply create a new branch for >> a new change set and send a new pull request once my work is complete. > > Errm ... you can still do that with svn. just continue working. Make a > new patch, update the patch in the bug report you filed, yes trac can > do that. There really is no need to wait for anything. But now you're conflating multiple features. Many times I have a feature in-progress and another feature I'd like to work on that's unrelated to the first feature. I don't want to disturb the source tree of the first feature because I might have to update it (respond to feedback, etc.). I need to be able to test both features in isolation. >> The upstream maintainer has no peer pressure to merge any changes in: >> He/she is sitting on the head revision and is looking at a number of >> pull requests for change sets in various personal forks like mine; > > So, how is it really different from the current trac system? svn doesn't support distributed operation so it can't support cherry-picking from multiple developers. You have to go outside the tool (manual diff/patch) to do it. That is painful. > I think i miss something fundamental here. Yes, you are. You're missing that every operation Steven is talking about is directly supported in git. You use the source control tool to manage source changes, always. There's no need to ever do a manual diff/patch. git manages multiple changes for you and organizes them in a logical way. It is easy to change among them, apply some, test them, revert some of them and so on. It's incredibly easy and productive compared to doing the same in svn. > While there are shortcomings in the current process, they won't be > solved by changing tools. Many will be. -Dave

4 3

[thread] wrong guard for explicit bool operators (c++11)
by Juergen Hunold 09 Feb '12

09 Feb '12

Hi Vicente, your commit New Revision: 76951 URL: http://svn.boost.org/trac/boost/changeset/76951 Thread: Added explicit to operator bool for locks (11 hours ago) leads to the following errors when using gcc-4.6.1 in non-c++11 mode: $BOOST_ROOT/boost/thread/locks.hpp:1323:34: warning: explicit conversion operators only available with -std=c++0x or -std=gnu++0x [enabled by default] It seems that the guards checking for explicit conversion operators are wrong. -#ifndef BOOST_NO_EXPLICIT_CONVERSION_OPERATORS +#if defined(BOOST_NO_EXPLICIT_CONVERSION_OPERATORS) Patch attached. Ok to commit? Yours, Jürgen -- Dipl.-Math. Jürgen Hunold | IVE mbH Software-Entwickler | Lützerodestraße 10 Tel: +49 511 897668 33 | 30161 Hannover, Germany Fax: +49 511 897668 29 | http://www.ivembh.de juergen.hunold(a)ivembh.de | | Geschäftsführer: Sitz des Unternehmens: Hannover | Univ.-Prof. Dr.-Ing. Thomas Siefer Amtsgericht Hannover, HRB 56965 | PD Dr.-Ing. Alfons Radtke

3 2

IDL to C++11 Language Mapping
by Johnny Willemsen 09 Feb '12

09 Feb '12

Hi, Last year I posted a question on this list related to the IDL to C++11 Language Mapping for CORBA. We are currently working on creating such a new mapping and maybe there are people on this list that are interested in giving feedback. All details about this effort are online at http://osportal.remedy.nl (example code and a draft OMG specification) and http://www.orbzone.org for a discussion forum. Best regards, Johnny Willemsen Remedy IT http://www.theaceorb.nl

1 0

quickbook abuse without boostbook
by Andreas Pokorny 09 Feb '12

09 Feb '12

Hi, My company is using docbook for end user documentation and to some degree also for design documentation. Since docbook is nothing anyone seems to be fond of writing, I now started looking into quickbook. The features that attract me the most are the neat syntax and programmability. The docbook environment that I am supposed to use is based on a different docbook version, than the one referenced in boostbook. So at the moment I have an xml file containing the book and booinfo header containing our corporate design foobar and disclaimer stuff. Then each chapter is referenced. The chapters are written in quickbook as chapter documents. When running the toolchain, it complains that it could not find the boostbook dtd - probably because downloading of dtd is disable, or fails because of our proxy. Is there a way to surpress the DOCTYPE tag within the chapter xml output files? regards Andreas Pokorny

6 7

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

[hash] regular behaviour of hash function for double values
by Kai Schroeder 07 Feb '12

07 Feb '12

Hi, the following code: double fStart = 31337; double fEnd = 65536; double fStep = fStart - fEnd; fStep /= 512; for (int i = 0; i < 512; i++) { std::cout << std::hex << boost::hash<double>()(fStart + i * fStep) << std::endl; } leads to the output of surprisingly regular hash values (see end of mail). This seems to occur mainly if a power of two number of points is sampled equidistantly within an interval. Especially since some hash table implementations (e.g. intel's threading building blocks) only use the last few bits to determine the bucket, this can lead to very bad caching behaviour for the rather common case of regularly sampled points (equidistant samplings of power of 2 are e.g. common in computer graphics and numerical algorithms). Are you aware of this? Would you consider it a bug? Best regards, Kai Schroeder Output of code using Boost 1.48 (similar behaviour can be observed for other start and end values and other power of 2 step counts): ff9f20000000000f e5042f900000000f 52f13f200000000f 297ac8b00000000f 48721e400000000f 2f9b8dd00000000f 3df0b1600000000f d19cf2f00000000f 9201c800000000f 9409aa100000000f 7cb3fba00000000f d7a42b300000000f b15982c00000000f 5f7900500000000f e0ba85e00000000f 255ee5700000000f cec119000000000f 955bd6900000000f 6a58f4200000000f 843a37b00000000f 590797400000000f 7e8db4d00000000f 1721b6600000000f 37acf9f00000000f df5f65800000000f 88b1a5100000000f 494a0a00000000f bb1082300000000f 1ea62bc00000000f ...

11 43

unordered_map 32bit VS 64bit
by Avikam Bara-nes 07 Feb '12

07 Feb '12

Hi, I'm porting a project from Linux 32bit to Linux 64bit. While doing so I notice that I have a dramatic performance degradation with unordered_map. My platform is Ubuntu 10.4.3 64bit running on Intel Xeon X3220 but, I tested similar program on WindowsXP SP2 64bit which running on Intel i5 and I get the same degradation. My boost version is 1_46_1. I use the following program in order to test unordered_map - Hop I didn't make any copy mistakes :-). #include <stdio.h> #include <sys/time.h> #include <boost/unordered_map.hpp> int main(int argc, char *argv[]) { struct timeval tv_before, tv_after; boost::unordered_map<boost::int_32_t, boost::int32_t> boost_map; boost_map[1] = 2; boost_map[3] = 4; gettimeofday(&tv_before, NULL); for(int i = ; i < 100000; i++) boost_map.find(1); gettimeofday(&tv_after, NULL); printf("Boost time is %f \n", (double)(((tv_after.tv_sec - tv_before.tv_sec) * 1000000 + (double)(tv_after.tv_usec - tv_before.tv_usec)) / 100000)); return 0; } I use the following compile commands: 64bit - g++ -O3 perf_test -o perf_test_64bit 32bit - g++ -m32 -O3 perf_test -o perf_test_32bit When I run the 32bit program I get 0.5 sec When I run the 64bit program I get 1.54 sec Any ideas ???

6 16

[MPI]: All tests failing -- branch and trunk
by Steve M. Robbins 07 Feb '12

07 Feb '12

Hi, I have been running a daily test of the Boost release branch for a long time. It normally takes an hour or so. However, two days ago (rev 76868), the build time shot up to over 9 hours. The same thing happened for testing the Boost trunk branch. Others on the boost-test list have experienced the same and Jurgen Hunold pointed out that all the MPI tests are failing. According to http://www.boost.org/development/tests/trunk/developer/mpi.html this is true for about half the tester machines. Should probably be fixed before 1.49 is released! -Steve

1 0

[functional] adding overload
by Lorenzo Caminiti 06 Feb '12

06 Feb '12

Hello all, During Boost.Local review, it was proposed to move the overload template out of Local and in Boost.Functional. What would the best name for it? 1) boost::overload_function (my preference) 2) boost::overloaded_function 3) boost::function_overload 4) boost::functional::overload (Boost.Functional seems to use boost:: directly and not boost::functional-- to mimic C++11 <functional>). For example: void print_text(char const* text) { std::cout << text << std::endl; } void print_add(int x, int y = 10) { std::cout << (x + y) << std::endl; } boost::function<void (int, int)> f = print_add; boost::overload_function< void (char const*) , void (int, int) , void (int) > print(print_text, f, print_add); print("abc"); // abc print(1, 2); // 3 print(1); // 11 Docs: https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost/loc… Thanks. --Lorenzo

8 18

[filesystem] windows/posix inconsistencies.
by Thorsten Ottosen 06 Feb '12

06 Feb '12

Hi Beman, I noticed the following in v3 whie hunting down a bug in my unit test: # ifdef BOOST_WINDOWS_API const std::string string() const { return string(codecvt()); } const std::string string(const codecvt_type& cvt) const; // string_type is std::wstring, so there is no conversion const std::wstring& wstring() const { return m_pathname; } const std::wstring& wstring(const codecvt_type&) const { return m_pathname; } # else // BOOST_POSIX_API // string_type is std::string, so there is no conversion const std::string& string() const { return m_pathname; } const std::string& string(const codecvt_type&) const; const std::wstring wstring() const { return wstring(codecvt()); } const std::wstring wstring(const codecvt_type& cvt) const # endif I can understand, that it is more efficient to return a reference when a referenec can be formed. However, consider const std::string& ext = iter->path().extension().string(); This is fine on windows, as a temporary is returned, and its lifetime is extended; on linux, extension() returns a temp path object, from where we get a reference. I'm not a 100% sure, but I think the C++ standard does not guarantee that this path object be kept alive. The net efffect is a crash on linux. I'm not sure its a great idea to have different reference-ness on the return types here. It could lead to other subtle differences. kind regards -Thorsten

9 14

[mpl] Nested Scopes w/Placeholders
by Kitten, Nicholas 06 Feb '12

06 Feb '12

I've recently been doing a lot mpl::folding (in boost 1.47), and I was disappointed when I realized that a nested fold wouldn't work with a lambda expression passed to the inner call, as in this example which extracts elements of sequences: using namespace mpl; using namespace mpl::placeholders; typedef vector< vector<char>, vector<int> > vec_of_vecs; typedef vector< char, int > expected_result; typedef fold< vec_of_vecs, vector<>, fold< _2, _1, *push_back< _1, _2 >* // wrong - refers to outer arguments > >::type result; BOOST_MPL_ASSERT(( equal<result, expected_result> )); After looking around for a solution I came across an old thread<http://lists.boost.org/boost-users/2004/12/9269.php> on the same subject, where it was suggested using mpl::protect might work. Indeed, the following modification does what I want, without any changes to the library: typedef fold< vec_of_vecs, vector<>, fold< _2, _1, *protect< lambda< push_back< _1, _2 > >::type >* // correct > >::type result; Of course, this is a little on the verbose side. In the old thread, Daniel Wallin suggested suggested changing the definition of lambda to yield syntax more in line with the runtime version of boost::bind, but that would apparently break other code. What about instead adding a specialization to protect for placeholder expressions? Indeed, the source in protect.hpp seems to indicate such a thing might've been in the works at one point, but I didn't see any more references to it: template< typename BOOST_MPL_AUX_NA_PARAM(T) * , int not_le_ = 0 // not lambda expression?* > struct protect : T { ... typedef protect type; }; What about changing it to something like this? template< typename BOOST_MPL_AUX_NA_PARAM(T) * , typename not_le_ = typename is_lambda_expression< T >::type* > struct protect : T { ... typedef protect type; }; *template< typename T >* *struct protect< T, mpl::true_ > : lambda<T>* *{* *...* *typedef protect type;* *};* Doing so would remove the inner lambda<...>::type expression, yielding the expected syntax. Could that be done without messing up everything else? Thanks, *Nick Kitten* Software Engineer Center for Video Understanding Excellence ObjectVideo, Inc.

3 6

[gsoc] Summer of Code 2012
by Andrew Sutton 05 Feb '12

05 Feb '12

Has it been a year already? Google has just announced the 2012 Summer of Code program, and we'd like to participate again. I think last year was particularly successful. We reviewed and accepted two new libraries and moved several more into a state where they can be reviewed. This year should be interesting. We have a new C++ programming language, several libraries in the standard, and we want more. Many, many more. If you didn't get a chance to watch Herb Sutter's keynote talk at GoingNative 2012, you should. It will be available on-demand from this site some time in the next few days. http://channel9.msdn.com/Events/GoingNative/GoingNative-2012 [Spoiler alert] Herb wants libraries -- and not just tools for programmers. C++ wants UI libraries, graphics, database connectivity, cryptography, XML, network protocols, SMS support, back office support, etc. I would love to see some of these libraries developed through Boost. In C++11. Bjarne Stroustrup said he hadn't seen this much energy around C++ in a decade. People are excited to be writing C++11 -- and they're younger people for the first time in a long time. We should be capitalizing on this. If you have library ideas, please email me here: andrew.n.sutton -at- gmail.com. I will collect these and put them on the idea page. Some comments for mentors: I'm not concerned with summer-long time constraints this year. I'd really like to establish long-term relationships with our students. I'm not strictly concerned with backwards compatibility support. I think we should be encouraging students (and people in general) to write in C++. Hiding new language features behind compatibility macros isn't exciting. It might be fine for when time comes for releases, but let's not require students to build release-ready software. This year, I'd like to see proposals for *new* libraries to be written in C++11. Andrew

1 0

[bgl] Maximum Adjacency Search
by Fernando Vilas 04 Feb '12

04 Feb '12

Hi, Well, it took me longer than "a few days" to make time to clean up the code, but here is a patch against today's SVN-trunk. It will probably need more cleanup before it is ready, but it should be at a point where public review will help. -- Thanks, Fernando Vilas fvilas(a)iname.com

2 1

1.49.0 Beta 1 Release Candidate
by Steve M. Robbins 04 Feb '12

04 Feb '12

Hi, I'm starting a build (using the Debian package configuration) and noticed several known bugs still present: These two bugs are patched on the trunk but not release. Can these be moved over, please? https://svn.boost.org/trac/boost/ticket/4657 https://svn.boost.org/trac/boost/ticket/6338 This issue has a simple patch that works around the problem for gcc versions prior to 4.6.3: https://svn.boost.org/trac/boost/ticket/5538 This issue has a patch that works (is used in Debian), though a jam expert could likely find a better fix: https://svn.boost.org/trac/boost/ticket/6286 Regards, -Steve (Boost maintainer for Debian)

5 9

[random] Determining interest in Pseudo-Random Functions and Counter Based Random Number Generators
by John Salmon 03 Feb '12

03 Feb '12

I am co-author of "Parallel Random Numbers, as Easy as 1, 2, 3". which recently won the best paper award at the IEEE/ACM SC'11 conference. I'm also co-author of the related Random123 library: http://deshawresearch.com/resources_random123.html My colleagues and I would like to contribute a similar library to Boost as well. This isn't just a "port" of the Random123 library. Boost's focus on C++ allows for both simplification and clarification of the ideas in the paper and the original library. I've done a preliminary draft of some code that fits nicely into the existing Boost Random library. It's incomplete, but I think there's enough for folks to look at and gauge further interest. A zip file with a boost-like layout is here: http://thesalmons.org/john/random123/prf_boost/prf_boost.zip The README from the zip file is appended. I look forward to your comments and suggestions. John Salmon -------------- README ------------------- This extension of the Boost Random library adds "Pseudo-Random Functions" (PRFs) as an alternative to conventional "Uniform Random Number Generators" and "Random Number Engines". It is an incomplete draft, intended to start a conversation. It is not ready-to-use library. The case for using PRFs in Monte Carlo and statistical simulation is given in the paper, "Parallel Random Numbers -- As Easy as 1, 2, 3", by Salmon, Moraes, Dror & Shaw, in the Proceedings of SC'11: http://dl.acm.org/citation.cfm?doid=2063405 also available at http://www.thesalmons.org/john/random123/papers/random123sc11.pdf PRFs have been known for many years, but either their advantages were unrecognized or they were thought to have poor performance with respect to conventional URNGs. The paper shows that PRFs exist with excellent statistical properties, and highly desirable space and time characteristics. Also, note that the terminology in the paper, is slightly different from that used here. In the paper they're called "Counter Based Random Number Generators". PRFs are well-known in cryptography, but the PRFs here (except for AES) are *not* cryptographically strong. Nevertheless, they have satisfied extensive tests of statistical quality and should satisfy the needs of Monte Carlo simulation and other fields that routinely use random numbers. PRFs are pure functions (functors in C++) with the property that they return "random" values, even when presented with highly regular inputs (see the paper for a discussion of how randomness is empirically established). The user of a PRF assembles the input, calls the function and obtains a "random" result which can then be used in the same way as a value obtained from a conventional URNG or Engine. In contrast, a conventional Random Number Engine has a much more limited API: the caller is restricted to seeding the engine, once and for all, and then repeatedly asking for the "next" random value. PRFs eliminate the sequential dependence inherent in conventional RNGs. With a PRF, one can compute the "n-th" value in O(1) time, without stepping through earlier values. In fact, with a PRF, the notion of an "n-th" value loses its significance. One simply obtains a random value. Eliminating sequential dependence can be especially useful for parallel, multi-threaded applications. For example, one can assemble a PRF's input from application-level data, e.g., object id, voxel number, user-supplied seed value, timestep, iteration number, etc. This kind of application data is unchanged when the application is parallelized, and is generally invariant as more or fewer threads become available. The resulting random value is thus invariant to the parallelization as well. This can be enormously helpful when correctness dictates that separate "parallel" threads should use the same "random" value, or when trying to reproduce results on different platforms with different levels of parallelism. Four PRFs are implemented: threfry, philox, ars and aes, each implemented in its own header file, e.g., boost/random/ars.hpp. The file boost/random/counter_based_urng.hpp implements the counter_based_urng adapter class, which creates a Uniform Random Number Generator from a PRF, allowing programmers to use the PRF APIs together with Boost or C++1x Random Number Distributions. The file boost/random/counter_based_engine.hpp implements the counter_based_engine adapter class, which creates a Uniform Random Number Engine from a PRF, allowing PRFs to be used with software that relies on the Uniform Random Engine concept. For better or worse, wrapping a PRF in a counter_based_engine adapter completely obscures the PRF's API and reintroduces sequential dependence. The zip file also contains a copy of the candidate Boost Endian library copied from boost sandbox. Endian-swapping is required by the AES engine on bigendian machines, and the library meets our needs. Concepts -------- All PRFs have a domain_type and a range_type and with d a "permissible" object of the domain type, the expression: prf(d) is of the range_type. In many cases, every possible value of domain_type will be "permissible", but we leave open the possibility that the prf may place restrictions on the values of domain_type that produce "random" results. The values returned by the prf should be "random", a concept that is difficult to make both precise and achievable. Roughly, for most sequences, including highly "regular" sequences, of distinct, permissible domain_type values, d1, d2, d3, ..., the sequence: prf(d1), prf(d2), prf(d3), ... is statistically indistinguishable from a sequence of independent, uniformly distributed random variables sampling the range_type. In most cases, the output of the prf will uniformly sample all possible values of the range_type, but we leave open the possibility that it may only sample a subset and that the output is only uniform over the subset. Keyable PRFs have a key_type, a corresponding constructor, and setkey() and getkey() member functions. Keyable PRFs constructed with different keys must also be statistically independent. I.e., even for highly regular sequences of distinct (key, domain) pairs: (k1, d1), (k2,d2), ... the sequence: Prf(k1)(d1), Prf(k2)(d2), ... is statistically indistinguishable from a sequence of independent random uniformly distributed samples of the range_type Keyable PRFs may also be Seedable in which case they also have seed() member functions and corresponding constructors similar to those of Random Number Engines. Seeding a PRF is equivalent to setting its key to some value corresponding to the output of sseq.generate(). A PRF has a Countable Domain if its domain_type has member functions begin(), end(), and back() with semantics identical to that of boost::array<Uint, N> for some unsigned integral type Uint and some N. It must also have member functions domain_array_min() and domain_array_max() that specify the permissible domain values. Any array, da, whose members, da[i], satisfy: prf.domain_array_min() <= da[i] <= prf.domain_array_max[] must be "permissible". A PRF has an Integer Array Range if its range_type has member functions begin(), end(), and size() with semantics identical to boost::array<RangeInt, N>, for some integral type, RangeInt and constant N. It must also have static constexpr member functions, range_array_min() and range_array_max() that specify the subset of range values sampled by the PRF. For any sequence of permissible domain value, d1, d2, ..., the integers: prf(d1)[i], prf(d2)[i] must be statistically indistinguishable from independent uniformly distributed RangeInts from range_array_min() up to and including range_array_max(). If a PRF has a Countable Domain and an Integer Array Range, then: counter_based_urng<Prf> satisfies the requirements of a Uniform Random Number Generator. If, in addition, the PRF is Seedable, Streamable and Equality Comparable, then: counter_based_engine<Prf> satisfies the requirements of a Random Number Engine. A PRF is a Pseudo-Random Bijection if it is one-to-one and onto. I.e., if it has an inverse. It is not necessary for the inverse to have a practical implementation. It is sufficient that the inverse exist mathematically. A PRF is a Pseudo-Random Permutation if it is a Bijection and its domain_type is the same as its range_type. The four implemented PRFs are CopyAssignable, EqualityComparable, Streamable, Keyable, Seedable, Pseudo-Random Permutations with Integer Array ranges and Countable domains. Hence, they satisfy the requirements of counter_based_engine and counter_based_urng. Differences from Random123 -------------------------- This code is inspired by the Random123 library, but there are significant differences. New terminology: threefry<2, uint64_t> is a "Pseudo-Random Function" (PRF). PRFs take a key_type as a constructor argument, and are bijections on their ctr_type. Thus, instead of: typedef r123::Threefry2x64 r123_t; r123_t::ctr_type c; r123_t::key_type k r123_t::ctr_type r = r123_t(c, k) You now say: typedef boost::random::threefry<2, uint64_t> prf_t; prf_t::key_type k; prf_t myprf(k); prf_t::domain_type c; prf_t::range_type r = myprf(c); // Or alternatively, (more reminiscent of Random123) prf_t::range_type r2 = prf_t(k)(c); AESNI ----- Use of AESNI is tricky because we want both compile-time and runtime control over whether AESNI is used. The compile-time control is determined by BOOST_HAS_AESNI, which we assume will be set by some config file based on compiler-specific symbols (__AES__, __x86_64__, __ICC, __GNUC__) and possible user-overrides. But even if AESNI support is compiled in, we have to detect it and fall back to a software implementation at runtime if it's not available. The check requires either an asm with GCC-compatible compilers or an intrinsic with MSVC-compatible compilers. Endianness is another complication. The AESNI implementation only works on x86_64 platforms, so it is not endian-sensitive. In fact, it *defines* how multi-byte quantities are to be interpreted. In contrast, the software implementation has to be endian-aware. The current implementation has not been tested with other endians, and hence is almost certainly broken. And finally, the AESNI intrinsics are *very* fast. We don't want to weigh them down with lots of runtime checks. With AESNI enabled, the runtime overhead should cost no more than a single conditional at the top of operator()(c). The choice between hardware and software AES is controlled by a member data field, useAESNI, of the prf class. If hw AES is compiled in, useAESNI is initialized by a runtime check of the CPU capabilities. It can be changed with a mutator method. If hw AES is not compiled in, useAESNI is initialized false and it is an error to try to set it to true. In detail/aes_impl.hpp, we implement two classes: detail::hw128 detail::sw128 with a common interface that minimally meets the needs of AES and ARS. The interface includes +=, ^= constructors from array<uintW, N>, aesenc, and aeskeygenassist primitives, etc. The crucial functions in AES and ARS are then written with a template parameter that is assumed to provide the interface. An idiom like: #if BOOST_HAS_AESNI if( useAESNI ) method<detail::hw128>(args); else #endif method<detail::sw128>(args); gives the desired compile-time and runtime control.

7 10