- Boost - lists.preview.boost.org

[1.43] [MPL] Okay to merge fix for bug #1992 to the release branch?
by Aleksey Gurtovoy 27 Apr '10

27 Apr '10

Changeset: https://svn.boost.org/trac/boost/changeset/60888 The fix is a low-risk one liner that has been committed to the trunk about a month ago (without any disturbance). Thanks, -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

[1.43] [MPL] Okay to merge gcc 4.5 fix to the release branch?
by Aleksey Gurtovoy 27 Apr '10

27 Apr '10

Changeset: https://svn.boost.org/trac/boost/changeset/61467 As predicted, the fix did not break anything in the trunk. Thanks, -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

[sandbox] Request for Account
by Murilo Adriano Vasconcelos 26 Apr '10

26 Apr '10

Hello, I am one of this year GSoC students and i want an account in sandbox. How do I have to proceed? Best, -- Murilo Adriano Vasconcelos Ciência da Computação Universidade Federal de Goiás http://murilo.wordpress.com

2 1

Automatic differentiation (and complex numbers) with lazy component evaluation
by Hal Finkel 26 Apr '10

26 Apr '10

Hello, I've uploaded to a subversion repository on SourceForge my Lazy Types library. This library provides template classes for dual numbers (used for automatic differentiation) and complex numbers. Expression templates are used in order to evaluate only those components which are actually needed. All of the standard-library math functions (and arithmetic operators) are supported. http://lazytypes.sourceforge.net/ http://sourceforge.net/projects/lazytypes The dual-number formalism is especially useful because it enables the compiler to generate analytic expressions for the derivative of "any" function (where "any" is restricted to those functions which compute using operators and functions the library knows about, which include all of the standard ones). These are *not* finite-difference approximations, but exact answers (to machine precision). Functions which use conditional statements, loops, etc. are fine, although the derivative might not have a meaning if evaluated at a point of discontinuity. This code has been released under the BSL 1.0. Although some Boost headers are used (enable_if, type_traits, etc.), Boost.Proto is not used. Is there any interest in having these libraries in Boost: 1. As-is (plus more documentation, tests, namespace change, etc.) 2. Only if rewritten to use Boost.Proto (which I am willing to do, so long as the performance of the current implementation can be matched). The project Wiki page (to which http://lazytypes.sourceforge.net/ redirects) has some documentation and usage examples. Here is a quick example of taking the derivative (and the second derivative) of a multivariate function: #include <lazy_types.hpp> namespace lt = lazy_types; ... template <typename X> X f(X &v1, X &v2) { using namespace lt; return pow(v1, 3) + pow<3>(v1) + pow<2>(v2 + v1) + v2*v1/5.0 + 3.0; } // A pow<> template is provided which works with the expression-template types. ... lt::dual<double, 2> fv1(2.0, 0), fv2(4.0, 1); lt::dual<double, 2> fv = f(fv1, fv2); std::cout << fv << " " << fv.eps(0) << " " << fv.eps(1) << std::endl; // This computes the derivative of the function f with respect to both of its arguments evaluated at the point where the function itself has been evaluated. // An example of computing the second derivative: template <typename X> X df(X &v1, X &v2, size_t ei) { lt::dual<X, 2> d1(v1, 0); lt::dual<X, 2> d2(v2, 1); return f(d1, d2).eps(ei); } lt::dual<double, 2> df0 = df(fv1, fv2, 0); lt::dual<double, 2> df1 = df(fv1, fv2, 1); std::cout << df0.eps(0) << " " << df0.eps(1) << std::endl; std::cout << df1.eps(0) << " " << df1.eps(1) << std::endl; If there is interest in adding these types (or some rewritten version of them) to Boost, please let me know, and I'll work on getting the library ready for review. Sincerely, Hal Finkel

3 4

[asio] how to handle "boost::asio::placeholders::error" in "boost::function"?
by 曹亚文 26 Apr '10

26 Apr '10

Hi all, I met a problem which can't be solved. Can any kind people help me? The code looks like the below: class transfor_data { public: void one_fun( const boost::system::error_code& e, connection conn ) { ... } void another_fun() { { //compile error because of the placeholder boost::function<void(void)> fun = boost::bind(&transfor_file_push::write_file, this, boost::asio::placeholders::error, conn); } { //fine without placeholder boost::system::error_code e; boost::function<void(void)> fun = boost::bind(&transfor_file_push::write_file, this, e, conn); } } }

3 2

[shared_ptr] Bug in perfect forwarding test?
by John Maddock 26 Apr '10

26 Apr '10

Now that rvalue refs are enabled for VC++10 the perfect forwarding test fails: http://tinyurl.com/367o3ab This looks like a legitimate failure to me, as the constructor to Y requires an "int&" non-const reference, but the make_shared_ptr function passes a "const int&". Ah... actually this may be to do with the fact that the header is predicated on BOOST_HAS_VARIADIC_TMPL as well as BOOST_HAS_RVALUE_REFS where as the test case is only predicated on BOOST_HAS_RVALUE_REFS? BTW there's an rvalue-refs related failure with gcc-4.5 in C++0x mode as well: http://tinyurl.com/37quwbj Cheers, John.

2 1

[1.43] Wrong version in version.hpp
by John Maddock 26 Apr '10

26 Apr '10

Just a note to point out that the release branch still has the version number set to 1.42 in boost/version.hpp. John.

2 1

[async] messages threads and networks
by Scott Woods 26 Apr '10

26 Apr '10

Hi Boost, Is anyone interested in a framework for asynchronous programming? This is based on the thinking contained in; * SDL (http://www.sdl-forum.org/SDL/index.htm) * Active Objects (http://www.cs.wustl.edu/~schmidt/PDF/Act-Obj.pdf) SDL is the ITU standard for specification of signaling systems. AO is a pattern for concurrent programming. These have been combined to create an environment where objects exchange messages, possibly between threads or even over networks. Objects are created simply; id = create<object_type>(); and once created, anything can be sent to it; send( anything, id ); The framework takes care of threading, network addresses, queueing, encoding and optimal I/O, as appropriate. Threads are equally simple to create; p = start<message_processor>(); and objects can be assigned to specific threads at creation time; id2 = create<object_type>( p ); A network server can be created as simply as; listen = create<socket_listen>(); server = create<socket_server<my_server> >(); service operational( "loopback:5500", server ); send( operational, listen ); Connecting is equally simple; connect = create<socket_connect>(); client = create<my_client>(); service operational( "localhost:5500", client ); send( operational, connect ); >From that point on, client and server can exchange messages using the send primitive without any knowledge that messages are actually travelling across a network. There is in fact no difference between inter-thread messaging and inter-processes (i.e. for the application). Feel free to poke around in the software at; http://groups.google.co.nz/group/pact-serialization/web I am interested in a Boost review of this library but suspect it is too large. It also overlaps with several existing boost components. But good to get further opinions. Cheers, Scott

5 18

[Interprocess] Patch: Various standard-conformance fixes
by Doug Gregor 26 Apr '10

26 Apr '10

The attached patch contains several fixes to improve the interprocess library's conformance to the C++ standard. The fixes are: - Added two missing "template" keywords where the left-hand side of a member access (with ->) is dependent - Removed a "mutable" from a reference type in two places - Removed an extra space from the end of the file name in INCLUDE_BOOST_CONTAINER_MOVE_HPP - Doug

2 1

[Iterators] Iterators and higher-order programming
by Thomas Jordan 25 Apr '10

25 Apr '10

Hi, One of the interesting things about the iterators library, it seems to me, is the additional support it gives for higher-order, functional-style programming. For example, you can use the transform and filter iterators to produce a simple 'Comprehension' object which permits list-comprehension type of syntax to be used, instead of conventional loops (or, e.g., std::transform). I found this quite exciting. I guess I could have come across this nice library sooner if it had been called 'Higher-Order Iterators' or at least co-categorised under the Function Objects and Higher-Order Programming library category. Anyway, is the the intention that we now have a 'computationally-complete' alternative to loops, with which we can write general loops in a more functional, type-ful way? Regards, Tom

2 1

[type_traits] optimized std::copy example wrong?
by Thorsten Ottosen 25 Apr '10

25 Apr '10

Hi John & co, IIRC, std::copy() cannot use memcpy(), since the memory is allowed to overlap. Therefore it can only use memmove(). regards -Thorsten

5 5

[1.43][Serialization] Serialization library seriosly broken
by Hartmut Kaiser 25 Apr '10

25 Apr '10

As I alluded to in my mail yesterday, the serialization library seems to be utterly broken in the current trunk, and unfortunately in the current release branch as well. We're seeing assertions at application initialization time during serialization registration in the file void_cast.hpp, line 225. That is in debug builds. In release builds we're seeing aborts later on. These problems seem to be caused by registering the same type more than once but from different shared libraries. We do not intentionally register the types more than once, even more, we have no control over this. Here is the simplified code causing the multiple registrations from different modules: struct Parameter_impl : ::Par // ::Par is a C-struct { private: friend class boost::serialization::access; template<class Archive> void serialize(Archive &ar, const unsigned int version) { ar & lambda; ar & allowedl; // more serialization going on } }; struct Parameter { boost::shared_ptr< Parameter_impl > p; // ... private: friend class boost::serialization::access; template<class Archive> void serialize(Archive &ar, const unsigned int version) { ar & p; } }; Note: no BOOST_..._EXPORT or other serialization macros are utilized in this file. This code is included by several files from different shared library modules as it is passed around. It is just including this file into compilation units from different shared libraries what causes the problems described above. All code worked before and still does with V1.42. If this error stays in the release branch the whole Boost release will be unusable for us, causing endless grief in the future. Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

6 13

[tokenmap] updated perfect hash container in sandbox
by Slawomir Lisznianski 25 Apr '10

25 Apr '10

Changes: * To eliminate a possibility of the algo for finding free slots becoming slower as the load factor increases, the container now keeps track of open slots in unused nodes. This guarantees constant time insertion of new elements at a slight bookkeeping overhead. Consequently, the load-factor has been removed. Pointed by Daniel James. * More STL compliant (iterators, size(), empty(), etc)

4 9

Help with VeecoFTC - exception - cloning_test / msvc-9.0~wm5~stlport5.2
by Emil Dotchevski 24 Apr '10

24 Apr '10

Can someone help me figure out what's going on here: http://tinyurl.com/ybpbsp4 Thanks! Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

3 5

callback or file based construction of CSR graph
by Dan Jiang 24 Apr '10

24 Apr '10

Is there any way for CSR graph to provide a constructor that takes a file stream pointer or a callback functor? If not, how hard is it to add it? I am using edges_are_sorted CSR constuctor. It doubles memory I passed in during constructor calls. My graph is huge (>30 million arcs) and It took >8gb ram to construct my CSR. If I can have callback or file-based construction, I could cut down the memory usage by half. Dan _________________________________________________________________ Hotmail & Messenger. Get them on your phone now. http://go.microsoft.com/?linkid=9724463

2 2

(no subject)
by Dan Jiang 24 Apr '10

24 Apr '10

Is there any way for CSR graph to provide a constructor that takes a file stream pointer or a callback functor? If not, how hard is it to add it? I am using edges_are_sorted CSR constuctor. It doubles memory I passed in during constructor calls. My graph is huge (>30 million arcs) and It took >8gb ram to construct my CSR. If I can have callback or file-based construction, I could cut down the memory usage by half. Dan _________________________________________________________________ Videos that have everyone talking! Now also in HD! http://go.microsoft.com/?linkid=9724465

1 0

[1.43.0] File version.hpp in release branch still says V1.42
by Hartmut Kaiser 24 Apr '10

24 Apr '10

Go figure ... Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

2 1

[1.43.0] Beta 1 now available from SourceForge
by Beman Dawes 24 Apr '10

24 Apr '10

Boost release 1.43.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/ For details of what's in the release, see http://beta.boost.org/users/news/version_1_43_0. Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files. There are known issues with GCC 4.5 and VC++ 2010. These compilers were released a few weeks ago so support is still rough around the edges. Some fixes will make it into the final 1.43.0 release, but full support will not be available until 1.44.0. Please download the beta, give it a try, and report any problems you encounter here. -- The Boost Release Team

3 4

[type_traits] what a about a trait that allows memcpy provided that destructors are not called?
by Thorsten Ottosen 24 Apr '10

24 Apr '10

Hi All, I'm looking into writing a boost::malloc_allocator<T> class. This allocator can also reallocate memory in-place via call's to realloc() which can be a benefit for vector-implementation and all it's functions that grow or shrink the vector. However, it is normally only safe to call memcpy() for objects with a trivial assignment operator. But we may also safely relocate a much larger set of classes, e.g. boost::shared_ptr<T> or std::vector<T>. At first I thought a trait like has_trivial_move_constructor<T> would be enough, but that seems to rule out e.g. smart pointers. The compiler can probably not detect this property, so what about a trait like template< class T > struct is_reallocable; Thoughts? -Thorsten

1 0

[1.43][beta] Fix for MPL under gcc 4.5
by joel falcou 24 Apr '10

24 Apr '10

Can : https://svn.boost.org/trac/boost/ticket/4061 be fixed by merging the attached trivial patch ? gcc 4.5 borks up on a deep MPL internals that prevent some other component to not compile. Thanks -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

16 30

[Serialization] Assertion when registering same type from different modules, release branch broken?
by Hartmut Kaiser 24 Apr '10

24 Apr '10

Hi, In the newest version of the serialization library (trunk) I'm seeing assertions in file void_cast.cpp, line 227 during application startup. The reason appears to be that the same type gets registered for serialization from different modules (shared libraries). The very same code worked for us before (and still works for V1.42). I did not check with the release candidate yet, but a comparison of the file void_cast.cpp in trunk and release branch lets me assume the error is there as well (both files are identical). I will try to recompile everything on the release branch over the weekend. If the same behavior shows up in the release branch I'd consider the serialization library seriously broken. The problem is, that I really don't know how to avoid this multiple registration from different modules as the type in question is defined in a header file (no EXPORT macro) which is being used from different modules. I don't think this is something really special. Any ideas what we could do? What's the rationale of changing the registration behavior in the serialization library? Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

1 0

Request to merge r61245 into release branch
by Jeremiah Willcock 23 Apr '10

23 Apr '10

Is it too late for this one? It fixes one warning (class vs. struct) and several errors for VC++ 10 (ambiguous begin and end calls). -- Jeremiah Willcock

2 1

[range] Merge to fix defects
by Neil Groves 23 Apr '10

23 Apr '10

Boosters, I have had a commit on the trunk to resolve some defects that I noticed by carefully reviewing all of my new code. There is one serious defect in the istream_range which on the release branch is useless. Of course, this is merely a lack of a new feature rather than a regression but I would like to have it working for the proper release. There are also some changes to return types to address the concern brought up in the review about inconsistent return types of various functions. Both of these fixes have been tested on the trunk for many days. I recently reverted a host of other changes on the trunk that are unrelated to these issues that would increase risk. The recently reduced changeset on the trunk is also passing regression tests. Thanks in anticipation, Neil Groves

2 3

[GIL] [Patch] References cannot be mutable
by Doug Gregor 23 Apr '10

23 Apr '10

boost/gil/extension/dynamic_image/apply_operation_base.hpp has two references marked "mutable", at lines 141 and 157, but references cannot be mutable. This patch removes the "mutable" keyword from both cases. - Doug

1 0

[any] allocator support?
by Kenny Riddile 23 Apr '10

23 Apr '10

This may have been brought up before, but I have a case where I need to use boost::any with types that require custom allocation. As far as I can tell, this isn't currently possible. Is there a reason boost::any doesn't allow specifying an allocator? std::allocator would obviously be the default. Has anyone maybe done this themselves already and be willing to share?

1 0

[geometry] few questions
by Janek Kozicki 23 Apr '10

23 Apr '10

Hello, By looking at the documentation I can see that Geometry library is great for 2D polygons. I am working in 3D, so I wanted to ask about what I can, and what I can't. Is it possible to define 3D shapes, calculate their intersections, unions and so on? What about centroids and second (geometrical) moments of inertia? Does the geometry deal with spheres, or maybe other classical 3D geometries, like ellipsoid, torus or cone? What about the infinite geometries (like infinite cone)? Or infinitely long line? Also I wanted to ask about 3D points regarded as vectors. Can I add and subtract them? What about 3D vector cross product. What about dot product? I guess that I need to write that 'very old formula' function myself? In fact, since you are well into the subject, perhaps you could tell me if there are anywhere in boost a vector dot product and cross product implemented? Last but not least - I am doing frequently a 3D rotation of 3D points using quaternions for that (this could work with rotation matrices too). I suppose that I would need to implement this myself to "link" boost::quaternion with boost::geometry::point3d. please enlighten me and thank you very much for your time -- Janek Kozicki http://janek.kozicki.pl/ |

3 4

BOOST_EXPLICIT_OPERATOR_BOOL macro?
by Christian Holmquist 23 Apr '10

23 Apr '10

Hi, IIUC, c+0x allows the safe bool idiom to be implemented as explicit operator bool() const { ...} but in c+03 emulating that behaviour is a bit messy. There appears to be a solution for c+03 in boost/smart_ptr/detail/operator_bool.hpp, but it's targeted for the smart_ptr classes only. Would it be possible to extract operator_bool.hpp into a reusable macro, something like: #include <boost/utility/operator_bool.hpp> struct some { BOOST_EXPLICIT_OPERATOR_BOOL( m_value != 0; ) int m_value; }; What do you think? Cheers, Christian

3 5

[range] new adaptor for iterating over equal_ranges
by Thorsten Ottosen 23 Apr '10

23 Apr '10

Hi Neil & others, I think it could be useful with a range adaptor of the following kind to iterate over equal_ranges in a multimap. E.g. SomeMultiMap map = ...; for( auto rng : map | boost::adaptors::equal_ranged ) for( auto iter : rng ) { // do something with the objects with equal keys } The resulting range would probably be bidirectional with value_type std::pair<boost::range_iterator<SomeMultiMap>::type,...>. Thoughts? -Thorsten

2 1

Fwd: Re: [interprocess][move] enum template argument fails to be a valid base class
by Ion Gaztañaga 23 Apr '10

23 Apr '10

>i think I spoke too fast, is_enum needs compiler intrinsics according >to >boost documentation, so maybe this approach is not very useful... Forget it. I was talking about is_union instead. God, the lack of coffee is killing me ;-) Best, Ion

2 4

[1.43.0] Beta 1 Release Candidates available
by Beman Dawes 23 Apr '10

23 Apr '10

The 1.43.0 Beta 1 Release Candidate files are available at http://boost.cowic.de/rc/ Before these get pushed out to SourceForge, we like to get verification that they download and build OK on at least Linux and Windows. So please download one of these for your favorite platform, try a build, and report success or failure here. Thanks, --Beman

5 9

[containers] flat_multimap compile errorin trunk
by Thorsten Ottosen 22 Apr '10

22 Apr '10

Hi Ion, The following code is making the compiler (vc9) choke: template<class D, class S> static D force_copy(S s) { value_type *vp = reinterpret_cast<value_type *>(&*s); return D(vp); } I don't get the code either? What is it good for, and why is a static_cast not good enough? If it helps, I'm using flat_multimap<BitSet,BitSet>, and not a build-in type. -Thorsten

3 4

[atomic] review schedule?
by Janek Kozicki 22 Apr '10

22 Apr '10

Hello, I recall that Atomic library was submitted for review, but I'm not seeing it in http://www.boost.org/community/review_schedule.html Why is that? When it will be reviewed? best regards -- Janek Kozicki http://janek.kozicki.pl/ |

1 0

[Fusion] [Phoenix] VC10
by Richard Crossley 22 Apr '10

22 Apr '10

I'm trying to port an existing program from V9 to VC10. With both Boost head and the 1.43RC I get a lot of errors relating to Phoenix and Fusion, none of which I've been able to recreate with a simple test and the back trace of the error messages are somewhat confusing. However if I the change the two BOOST_WORKAROUND(BOOST_MSVC, <= 1500) to 1600 in /boost/fusion/container/vector/vector.hpp all the problems seem to go away. Perhaps someone who is more knowledge about this could take a look? Thanks, Richard. 4>c:\boost_1_43_0_beta1\boost/fusion/container/vector/detail/vector_n.hpp(68 ): error C2665: 'boost::fusion::vector_data2<Derived,T0,T1>::vector_data2' : none of the 3 overloads could convert all the argument types 4> with 4> [ 4> Derived=boost::fusion::vector2<boost::phoenix::argument<0>,boost::phoenix::v alue<bool (__cdecl property_t::* )(void) const>>, 4> T0=boost::phoenix::argument<0>, 4> T1=boost::phoenix::value<bool (__cdecl property_t::* )(void) const> 4> ] 4> c:\boost_1_43_0_beta1\boost/fusion/container/vector/detail/vector_n.hpp(45): could be 'boost::fusion::vector_data2<Derived,T0,T1>::vector_data2(const boost::phoenix::argument<N> &,const boost::phoenix::value<T> &)' 4> with 4> [ 4> Derived=boost::fusion::vector2<boost::phoenix::argument<0>,boost::phoenix::v alue<bool (__cdecl property_t::* )(void) const>>, 4> T0=boost::phoenix::argument<0>, 4> T1=boost::phoenix::value<bool (__cdecl property_t::* )(void) const>, 4> N=0, 4> T=bool (__cdecl property_t::* )(void) const 4> ] 4> while trying to match the argument list '(const boost::phoenix::composite<EvalPolicy,EvalTuple>, const boost::mpl::void_)' 4> with 4> [ 4> EvalPolicy=boost::phoenix::mem_fun_ptr_eval, 4> EvalTuple=boost::fusion::vector<boost::phoenix::argument<0>,boost::phoenix:: value<bool (__cdecl property_t::* )(void) const>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost: :fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void _,boost::fusion::void_> 4> ] 4> c:\boost_1_43_0_beta1\boost/fusion/container/vector/detail/vector_n.hpp(105) : see reference to function template instantiation 'boost::fusion::vector_data2<Derived,T0,T1> boost::fusion::vector_data2<Derived,T0,T1>::init_from_sequence<Sequence>(con st Sequence &)' being compiled 4> with 4> [ 4> Derived=boost::fusion::vector2<boost::phoenix::argument<0>,boost::phoenix::v alue<bool (__cdecl property_t::* )(void) const>>, 4> T0=boost::phoenix::argument<0>, 4> T1=boost::phoenix::value<bool (__cdecl property_t::* )(void) const>, 4> Sequence=const boost::phoenix::composite<boost::phoenix::logical_not_eval,boost::fusion::ve ctor<boost::phoenix::composite<boost::phoenix::mem_fun_ptr_eval,boost::fusio n::vector<boost::phoenix::argument<0>,boost::phoenix::value<bool (__cdecl property_t::* )(void) const>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost: :fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void _,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fu sion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,b oost::fusion::void_,boost::fusion::void_,boost::fusion::void_>> 4> ] 4> c:\boost_1_43_0_beta1\boost/fusion/container/vector/vector.hpp(58) : see reference to function template instantiation 'boost::fusion::vector2<T0,T1>::vector2<Sequence>(const Sequence &)' being compiled 4> with 4> [ 4> T0=boost::phoenix::argument<0>, 4> T1=boost::phoenix::value<bool (__cdecl property_t::* )(void) const>, 4> Sequence=const boost::phoenix::composite<boost::phoenix::logical_not_eval,boost::fusion::ve ctor<boost::phoenix::composite<boost::phoenix::mem_fun_ptr_eval,boost::fusio n::vector<boost::phoenix::argument<0>,boost::phoenix::value<bool (__cdecl property_t::* )(void) const>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost: :fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void _,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fu sion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,b oost::fusion::void_,boost::fusion::void_,boost::fusion::void_>> 4> ] 4> c:\boost_1_43_0_beta1\boost/spirit/home/phoenix/core/composite.hpp(71) : see reference to function template instantiation 'boost::fusion::vector<T0,T1,T2,T3,T4,T5,T6,T7,T8,T9>::vector<const U0>(const Sequence &)' being compiled 4> with 4> [ 4> T0=boost::phoenix::argument<0>, 4> T1=boost::phoenix::value<bool (__cdecl property_t::* )(void) const>, 4> T2=boost::fusion::void_, 4> T3=boost::fusion::void_, 4> T4=boost::fusion::void_, 4> T5=boost::fusion::void_, 4> T6=boost::fusion::void_, 4> T7=boost::fusion::void_, 4> T8=boost::fusion::void_, 4> T9=boost::fusion::void_, 4> U0=const boost::phoenix::composite<boost::phoenix::logical_not_eval,boost::fusion::ve ctor<boost::phoenix::composite<boost::phoenix::mem_fun_ptr_eval,boost::fusio n::vector<boost::phoenix::argument<0>,boost::phoenix::value<bool (__cdecl property_t::* )(void) const>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost: :fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void _,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fu sion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,b oost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>, 4> Sequence=const boost::phoenix::composite<boost::phoenix::logical_not_eval,boost::fusion::ve ctor<boost::phoenix::composite<boost::phoenix::mem_fun_ptr_eval,boost::fusio n::vector<boost::phoenix::argument<0>,boost::phoenix::value<bool (__cdecl property_t::* )(void) const>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost: :fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void _,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fu sion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,b oost::fusion::void_,boost::fusion::void_,boost::fusion::void_>> 4> ] 4> c:\boost_1_43_0_beta1\boost/fusion/container/vector/vector.hpp(58) : see reference to function template instantiation 'boost::phoenix::composite<EvalPolicy,EvalTuple>::composite<const boost::phoenix::composite<boost::phoenix::logical_not_eval,boost::fusion::ve ctor<T0,T1,T2,T3,T4,T5,T6,T7,T8,T9>>>(U0 &)' being compiled 4> with 4> [ 4> EvalPolicy=boost::phoenix::mem_fun_ptr_eval, 4> EvalTuple=boost::fusion::vector<boost::phoenix::argument<0>,boost::phoenix:: value<bool (__cdecl property_t::* )(void) const>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost: :fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void _,boost::fusion::void_>, 4> T0=boost::phoenix::composite<boost::phoenix::mem_fun_ptr_eval,boost::fusion: :vector<boost::phoenix::argument<0>,boost::phoenix::value<bool (__cdecl property_t::* )(void) const>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost: :fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void _,boost::fusion::void_>>, 4> T1=boost::fusion::void_, 4> T2=boost::fusion::void_, 4> T3=boost::fusion::void_, 4> T4=boost::fusion::void_, 4> T5=boost::fusion::void_, 4> T6=boost::fusion::void_, 4> T7=boost::fusion::void_, 4> T8=boost::fusion::void_, 4> T9=boost::fusion::void_, 4> U0=const boost::phoenix::composite<boost::phoenix::logical_not_eval,boost::fusion::ve ctor<boost::phoenix::composite<boost::phoenix::mem_fun_ptr_eval,boost::fusio n::vector<boost::phoenix::argument<0>,boost::phoenix::value<bool (__cdecl property_t::* )(void) const>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost: :fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void _,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fu sion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,b oost::fusion::void_,boost::fusion::void_,boost::fusion::void_>> 4> ] 4> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xlocnum(1081) : see reference to function template instantiation 'boost::fusion::vector<T0,T1,T2,T3,T4,T5,T6,T7,T8,T9>::vector<boost::phoenix ::composite<EvalPolicy,EvalTuple>>(const Sequence &)' being compiled 4> with 4> [ 4> T0=boost::phoenix::composite<boost::phoenix::mem_fun_ptr_eval,boost::fusion: :vector<boost::phoenix::argument<0>,boost::phoenix::value<bool (__cdecl property_t::* )(void) const>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost: :fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void _,boost::fusion::void_>>, 4> T1=boost::fusion::void_, 4> T2=boost::fusion::void_, 4> T3=boost::fusion::void_, 4> T4=boost::fusion::void_, 4> T5=boost::fusion::void_, 4> T6=boost::fusion::void_, 4> T7=boost::fusion::void_, 4> T8=boost::fusion::void_, 4> T9=boost::fusion::void_, 4> EvalPolicy=boost::phoenix::logical_not_eval, 4> EvalTuple=boost::fusion::vector<boost::phoenix::composite<boost::phoenix::me m_fun_ptr_eval,boost::fusion::vector<boost::phoenix::argument<0>,boost::phoe nix::value<bool (__cdecl property_t::* )(void) const>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost: :fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void _,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fu sion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,b oost::fusion::void_,boost::fusion::void_,boost::fusion::void_>, 4> Sequence=boost::phoenix::composite<boost::phoenix::logical_not_eval,boost::f usion::vector<boost::phoenix::composite<boost::phoenix::mem_fun_ptr_eval,boo st::fusion::vector<boost::phoenix::argument<0>,boost::phoenix::value<bool (__cdecl property_t::* )(void) const>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost: :fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void _,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fu sion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,b oost::fusion::void_,boost::fusion::void_,boost::fusion::void_>> 4> ]

2 3

[interprocess][move] enum template argument fails to be a valid base class
by vicente.botet 22 Apr '10

22 Apr '10

I have find a possible bug on the move emulation on " Boost::Container::Vector with Enum Template Argument - Not Legal Base Class" http://stackoverflow.com/questions/2678476/boostcontainervector-with-enum-t… As rv inherits from the movable class template <class T> class rv : public T { rv(); ~rv(); rv(rv const&); void operator=(rv const&); }; it doesn't works for enum types. With gcc 3.4. I get ../../../boost/interprocess/detail/move.hpp:79: error: base type `Test::Types' fails to be a struct or class type. I don't know if this is a know issue with the move emulation. I have tried to add a specialization for is_movable namespace boost { namespace interprocess { // get inside boost template<> class is_movable<Test::Types> // add custom specialization of is_movable : public mpl::bool_<false> {}; }} but this doesn't works neither. I have tried to specialize the rv template with template <> class rv<Test::Types> { Test::Types v; rv(); ~rv(); rv(rv const&); void operator=(rv const&); operator Test::Types() const {return v;} }; and it compiles but the execution fails. Is there any workaround to this issue or better yet a generic solution? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 3

Re: [boost] [Bind] How do I get bind to deduce the return type of for_each?
by Thomas Jordan 21 Apr '10

21 Apr '10

On Mon, Apr 19, 2010 at 1:04 PM, Thomas Jordan <thomasjordan_at_[hidden]> wrote: > Thomas Jordan wrote: >> [snip] >> I was hoping I could accomplish the objective of passing an algorithm into an algorithm jgenerically, just doing everything at point of call using just >> Boost.bind, the std::algorithms (wrapped) and using if necessary some boost.function functors to help type deduction. Are we saying this isn't possible? > ----------------------------------------- > Roland Bock replied: > > ************************************ > > <snip> > Â for_each(vov.begin(), vov.end(), > Â Â Â Â bind(for_each< vocType::iterator, function<void (myClass&)> >, > Â Â Â Â Â Â bind<vocType::iterator>(&vocType::begin, _1), > Â Â Â Â Â Â bind<vocType::iterator>(&vocType::end, _1), > Â Â Â Â Â Â protect(bind(&myClass::func, _1)) > Â Â Â Â Â Â ) > Â Â Â Â ); > } > // ----------------------------------------------------------- OvermindDL1 responded: You should use Boost.Phoenix, it can do what Bind and Lambda and others can, plus more, including the above with no issues. _____________________________________ Thanks for the suggestion. I will take a look at Phoenix. I have been drawn to Boost::bind because it is small, self-contained, relatively easy to understand and surprise-free. I like the extra power of Lambda - it is beautiful for relatively simple operator expressions and function bindings, however, when I tried to do anything more complex, e.g., multiple Lambda sub-expressions separated by commas, it started to go wrong for me. I found it difficult to predict what would happen, esp. with regard argument binding, order of evaluation, side-effects, etc. Even when I saw the result, I wasn't sure how it had got there. This could just be due to my lack of experience, holes in the documentation, or even compiler issue. Also, the syntax what is bit prickly. I am not trying to start a 'which is best Boost functional library' thread, but such issues, if present, would (sadly) steer me away from Phoenix too. I just couldn't recommend it to your average C++ programmer at my workplace. Also, I got the impression Boost::bind is in TR1, therefore is likely to be in the next standard, whereas Lambda expressions would be best handled by core-language extensions (also mooted for the standard)? Finally, if Boost::Phoenix is so good (I don't doubt it that it is), why is is buried away under another library, and are there any plans to consolidate/deprecate any/all of these libraries? Best regards, Tom.

2 2

[GGL] [geometry] Inexplicable speed benefit when using Visual C++ 2010
by Christian Buchner 21 Apr '10

21 Apr '10

Hi everybody, my first attempt to post to this list bounced, so I am trying again. My employer is an early adopter of the Boost Generic Geometry Library [GGL] in an engineering application related to mobile radio communicatons. We use it to estimate and optimize the coverage of 4G radio networks. Our code uses a lot of multi-polygon unions to estimate the amount of ground covered (and not covered) by radio beams and iteratively improves the antenna parameters. We've been compiling and shipping our application with Visual C++ 2008 so far. We found that GCC 4.4 on Linux was about 100% faster than Visual C++ 2008 on Linux without modifying the code. This bothered us quite a bit as both compilers were allowed to use full optimization. We found that by optimizing (globaly overloading) the new and delete operators to re-use allocated memory fragments on Windows we were able to get nearly 50% speed benefit, so we attributed much of the performance difference to sub-optimal memory heap management of Visual C++ 2008. Then we tried recompiling the project with Visual C++ 2010 Ultimate Release Candidate (RC). The speed gain of the algorithm was 900% (not joking) and the results still appear to be correct. Now this is surreal and no one here in the office has found a reasonable explanation yet without going into the metaphysical domain. Would anyone with knowledge of compiler and runtime internals be able to make an educated guess as to how such a speed gain of factor 10 is possible? Is anyone else seeing similar speedups in boost or in the geometry library when compiling with Visual C++ 2010 RC (HINT: it's a free download, so anyone can try it out until end of June 2010). Christian

10 13

[circular_buffer] Patch to fix two-phase name lookup issue in space_optimized
by Doug Gregor 21 Apr '10

21 Apr '10

Hello Boosters, In the space_optimized circular buffer, the two calls to invalidate_iterators_except require a preceding "this->". The actual invalid_iterators_except() function is only accessible through a dependent base, so we need to make the invalid_iterators_except name dependent. The DEC compiler tried to tell us this at one point, but we ignored it. Patch is attached. - Doug

3 3

Volunteering to fix inspection issues
by Jeremiah Willcock 21 Apr '10

21 Apr '10

I am willing to do another sweep for tabs, files not ending in newlines, easy-to-fix broken links, etc. in the trunk and/or release branch. Should I do that? I did this before, but do not remember the procedure fully. I'm assuming that I do the fixes in the trunk then (maybe) merge them into the release branch using SVN. Is that the right procedure? Are there any limits on which libraries I should do fixes in (other than the inspection code itself which purposely has issues)? Should I pull changes over to the release branch for cosmetic things (after testing them on the trunk)? -- Jeremiah Willcock

4 7

Re: [boost] [utility/result_of] decltype-based implementation breaking valid code on msvc-10
by Christophe Henry 21 Apr '10

21 Apr '10

> Eric Niebler wrote: > >> I suspect the real problem is in a buggy implementation of decltype on >> msvc-10. For the upcoming boost release, I suggest that we stick with >> the non-decltype implementation of result_of on msvc-10, or risk >> massively breaking users' code, not to mention proto, spirit and >> xpressive on that compiler. > > MSVC10 isn't even released yet. > Why bother with a non-stable compiler? > I start having a bit of experience with decltype and VC compilers (sigh) through my eUML front-end for MSM and I can give you one reason: because it's probably not just VC10. I have here and there this problem (and others) with VC9 too. It might just happen in different conditions. Christophe

13 65

[move] Reason for BOOST_COPY_ASSIGN_REF?
by Chad Nelson 21 Apr '10

21 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been studying Boost.Move, with an eye toward using it to incorporate move semantics into the XInt library. Most of it looks pretty straightforward, but I don't understand the reason for the BOOST_COPY_ASSIGN_REF macro. If you already have a copy-constructor that takes a reference, what does it give you? Also, how close is it to being official? I'd like to use it, but if it's not going to be accepted any time soon, I can't justify it. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvOY7AACgkQp9x9jeZ9/wRK1gCgvukakBrO37sCmHKwdhf9ebsI rt8AmwYk3WwDZkUiUKKXb76Jeuh3n3w4 =8EHR -----END PGP SIGNATURE-----

4 8

[containers] flat_set/flat_map could add insert_sorted(begin, end)
by Thorsten Ottosen 21 Apr '10

21 Apr '10

Hi Ion, I think the above member could be useful (taking an already sorted sequence), especially if the container needs to reallocate, in which case we may merge the two sequences [begin,end) [lower_bound(*begin),upper_bound(*(end-1))] and copy the unaltered prefix and suffix. Furthermore, even when we don't have to reallocate, we can bulk copy the suffix and simulate merging for the infix range. Any comments? -Thorsten

3 5

[filesystem] forward declaration headers
by Alexander Arhipenko 21 Apr '10

21 Apr '10

Hi boosters, I think it would be nice for boost filesystem to maintain forward declarations headers, e.g. <boost/filesystem/fwd.hpp>. Regards

1 0

Re: [boost] [Bind] How do I get bind to deduce the return type of for_each?
by Thomas Jordan 21 Apr '10

21 Apr '10

Thomas Jordan wrote: > Hi, > I have been trying to use Boost.bind to create an 'STL algorithm function object' to pass into another, 'higher order,' STL algorithm (e.g., to pass a for_each into a for_each). However, I am struggling to get bind to deduce the correct return type of the for_each function object. I include the relevant bits of the code below. > > class myClass > { > public: > int func(){return mValue;} > private: > int mValue; > }; > > //wrapper for STL for_each > struct myForEach > { > template <typename II, typename F> > F operator()(II begin, II end, F function) const > { > return std::for_each(begin, end, function); > } > }; > > typedef vector<myClass> vocType; > typedef vector<vocType> vovType; > > //overloaded member functions vocType::begin & end > typedef vocType::iterator (vocType::*fnPtr)(); > typedef const vocType::iterator (vocType::*constFnPtr)() const; > > vovType vov(10, vocType(10, myClass())); > > main() > { > for_each(vov.begin(), vov.end(), > bind< ? >(myForEach(), > bind(static_cast<fnPtr>(&vocType::begin),_1), > bind(static_cast<fnPtr>(&vocType::end),_1), > protect(bind(&myClass::func, _1))) > } > > I tried various things for bind<?>, but was only able to get the code to compile (eventually) on my Unix box when I substituted > bind< boost::_bi::protected_bind_t<boost::_bi::bind_t<int, boost::_mfi::mf0<int, myClass>, boost::_bi::list1<boost::arg<1> (*)()> > > > for > the bind<?>. I had guessed this might work from studying the compiler error messages. Obviously, this is not an ideal solution! > > Also, I only used the myForEach wrapper after having first attempted - and similarly failed - to bind the raw STL for_each. > > Is there any way I can help bind to deduce the correct return type - for either myForEach or std::for_each, or both? > > > --Roland Bock wrote------------------------------------------------------------------ In my experience it is easier to use a named functor object. Such as function<void (const vocType&)> functor = bind(&myClass::func, _1); std::for_each(vov.begin(), vov.end(), functor); Untested, but I am pretty sure something along these lines will work. Regards, Roland ------------------------------------------------------------------------------------------------- Thanks for the suggestion, Roland, I am sure you could get something like this to work easily enough. However, if I understand correctly your suggestion involves defining a separate functor - myClass - to take the vocType's, and which I guess wraps the inner call to for_each. I had hoped for a more generic solution which doesn't involve the creation of new functors. I was hoping I could accomplish the objective of passing an algorithm into an algorithm jgenerically, just doing everything at point of call using just Boost.bind, the std::algorithms (wrapped) and using if necessary some boost.function functors to help type deduction. Are we saying this isn't possible?

5 9

[serialization] alternative with inter-thread and network messaging
by Scott Woods 21 Apr '10

21 Apr '10

Hi Boost, I've been developing a serialization library to prove a few concepts and this has recently started to bear fruit. It tackles the problem space in quite a distinct way resulting in features like runtime-selectable encodings and out-of-the-box network messaging. Feel free to poke around in the software at; http://groups.google.co.nz/group/pact-serialization/web Aspects of the design came from sources such as; * SDL (http://www.sdl-forum.org/SDL/index.htm) * Active Objects (http://www.cs.wustl.edu/~schmidt/PDF/Act-Obj.pdf<http://www.cs.wustl.edu/%7Eschmidt/PDF/Act-Obj.pdf> ) The work was motivated by years of battling with proprietary encodings, configuration files, data formats, telephony signaling systems and TCP application protocols. This is a framework to give all the related pieces a proper place and more importantly, to keep things like network APIs out of application code. I would be interested in submitting this for Boost review but suspect that the library is too big. It also overlaps with a long list of existing components including serialization, asio, MPI, threads, uuid, any, variant and statechart. Maybe the integration of all those facilities is interesting to Boost? Or if there was something that could be carved off for separate submission - perhaps the UTF templates? Advice from moderators would be appreciated. Cheers, Scott

1 0

[serialization] alternative with inter-thread and network messaging
by Scott Woods 21 Apr '10

21 Apr '10

Hi Boost, I've been developing a serialization library to prove a few concepts and this has recently started to bear fruit. It tackles the problem space in quite a distinct way resulting in features like runtime-selectable encodings and out-of-the-box network messaging. Feel free to poke around in the software at; http://groups.google.co.nz/group/pact-serialization/web Aspects of the design came from sources such as; * SDL (http://www.sdl-forum.org/SDL/index.htm) * Active Objects (http://www.cs.wustl.edu/~schmidt/PDF/Act-Obj.pdf) The work was motivated by years of battling with proprietary encodings, configuration files, data formats, telephony signaling systems and TCP application protocols. This is a framework to give all the related pieces a proper place and more importantly, to keep things like network APIs out of application code. I would be interested in submitting this for Boost review but suspect that the library is too big. It also overlaps with a long list of existing components including serialization, asio, MPI, threads, uuid, any, variant and statechart. Maybe the integration of all those facilities is interesting to Boost? Or if there was something that could be carved off for separate submission - perhaps the UTF templates? Cheers, Scott

1 0

[range] Request to merge minor small defect fixes
by Neil Groves 20 Apr '10

20 Apr '10

Please may I merge some very small defect fixes for Boost.Range, and an additional test? The defect fixes are to improve return types consistency. I would like to get the interface correct for the first release of the merged RangeEx code. I have also added a test case that checks the use of non-member functions as functors and explicitly tests chaining of Range Adaptors. I believe this provides appreciably better visibility of the state of the library on the various compilers. These changes have been passing tests on the trunk for several days. The changes are also extremely low impact as they are in the new Range code that is not yet used within the rest of the Boost libraries. Thanks, Neil Groves

3 5

Bug #2501: upgrade_to_unique_lock doesn't compile on C++0x mode
by Rodolfo Schulz de Lima 20 Apr '10

20 Apr '10

Hi, is there any chance that the patch attached to bug #2501 can/will be in 1.43? It works for me (with minor patch adjustments) and IMHO is safe to be merged into trunk. I've been patching my local copy of boost for the last 6 releases... I'm a little tired of doing that :) []s, rod

3 4

[release] Permission to merge fix for issue 2501 in boost.thread
by Anthony Williams 20 Apr '10

20 Apr '10

Hi, I just committed a fix for issue 2501 to trunk. Can I merge this to release once the tests have cycled? Thanks, Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

3 2

[GSoC] Requesting a review on my GSoC proposal
by Stefan 20 Apr '10

20 Apr '10

Hello. I apologize for being so persevering but I have posted a comment on my proposal and received no feedback yet. It would be greatly appreciated if you could let me know of your opinion in connection to my application as well as request any clarification if applicable. Proposal link: http://socghop.appspot.com/gsoc/student_proposal/private/google/gsoc2010/ms… (private, thus viewable only by mentors) Best wishes, Stefan

1 0

[mpl] aux_::template_arity subtly broken on gcc-4.5
by Eric Niebler 20 Apr '10

20 Apr '10

First, I freely acknowledge that I have been relying on an implementation detail of MPL, and I will spend an appropriate amount of time doing penance in programmer purgatory after I die. That said ... Xpressive is broken on gcc-4.5 because mpl::aux_::template_arity is causing instantiations on that compiler that it shouldn't. Consider the following program that compiles on gcc-4.4 but not gcc-4.5. #include <boost/mpl/aux_/template_arity.hpp> #include <boost/mpl/aux_/lambda_arity_param.hpp> template<class A> struct T : A::x {}; template< class T BOOST_MPL_AUX_LAMBDA_ARITY_PARAM( int Arity = boost::mpl::aux::template_arity<T>::value ) > struct S {}; template<template<class A> class P, class X> struct S<P<X> BOOST_MPL_AUX_LAMBDA_ARITY_PARAM(1)> {}; int main() { S<T<int> > s0; } The error I get is: bug4109.cpp: In instantiation of ‘T<int>’: ../../../boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:85:5: instantiated from ‘const int boost::mpl::aux::template_arity_impl<T<int>, 1>::value’ ../../../boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:93:5: instantiated from ‘const int boost::mpl::aux::template_arity<T<int> >::value’ ../../../boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:98:30: instantiated from ‘boost::mpl::aux::template_arity<T<int> >’ bug4109.cpp:23:14: instantiated from here bug4109.cpp:6:3: error: ‘int’ is not a class, struct, or union type Any chance of a fix? -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 3

Re: [boost] [Bind] How do I get bind to deduce the return type of for_each?
by Thomas Jordan 20 Apr '10

20 Apr '10

Thomas Jordan wrote: > [snip] > Thanks for the suggestion, Roland, I am sure you could get something like this to work easily enough. However, if I understand correctly your suggestion involves defining a separate functor - myClass - to take the vocType's, and which I guess wraps the inner call to for_each. I had hoped for a more generic solution which doesn't involve the creation of new functors. I was hoping I could accomplish the objective of passing an algorithm into an algorithm jgenerically, just doing everything at point of call using just Boost.bind, the std::algorithms (wrapped) and using if necessary some boost.function functors to help type deduction. Are we saying this isn't possible? > Roland Bock replied: ************************************ Hi Thomas, we don't say it isn't possible :-) Here you go: // ----------------------------------------------------------- #include <boost/bind.hpp> #include <boost/bind/protect.hpp> #include <boost/function.hpp> #include <vector> #include <iostream> using namespace std; using namespace boost; int initValue = 0; class myClass { public: myClass(): mValue(initValue) {} myClass(const myClass& rhs): mValue(initValue++) { } void func() { cout << mValue << endl; } private: int mValue; }; typedef vector<myClass> vocType; typedef vector<vocType> vovType; int main() { vovType vov(10, vocType(10, myClass())); for_each(vov.begin(), vov.end(), bind(for_each< vocType::iterator, function<void (myClass&)> >, bind<vocType::iterator>(&vocType::begin, _1), bind<vocType::iterator>(&vocType::end, _1), protect(bind(&myClass::func, _1)) ) ); } // ----------------------------------------------------------- Please let me know if this is working for you. Regards, Roland ************************************************************** Thanks a lot, Roland, this looks good. I felt there must be some way to do it, but it was just beyond my grasp. Always learning! Regards, Tom.

2 1

[config] Compiler defects value-initialization
by Niels Dekker - address until 2010-10-10 19 Apr '10

19 Apr '10

The Config/trunk regression page currently shows some detailed information of various compiler defects regarding value-initialization: http://www.boost.org/development/tests/trunk/developer/config_.html If anyone wants to have a look at these results, please do so quickly! The output is from boost_no_complete_value_initialization::test(), which tests whether a specific compiler should have a new defect macro defined, BOOST_NO_COMPLETE_VALUE_INITIALIZATION. In a few days, I'm planning to add this definition to the Boost Config files of those compilers [Boost #4080], and then the test output will disappear automatically. According to the current test results, two compilers do an excellent job w.r.t. value-initialization: Intel (10.1, 11.0, 11.1) on Mac OS X, and GCC 4.4.3 (both on Linux and Windows). Compilers that don't completely do value-initialization include Microsoft Visual C++ (including msvc-10.0), Borland (including CodeGear 2010), Sun 5.10, and IBM XL V10.1. The MSVC defect was reported back in 2005 [Visual Studio #100744]. I recently reported the value-initialization defects I encountered on Embarcadero CodeGear [Embarcadero #83751, #83851] and IBM XL. The Windows version of Intel 11.1 doesn't do so well either, according to results from Huang-Vista-x86_32_intel. I still wonder why, because on Mac OS X, Intel does so well. GCC also has regression failures w.r.t. value-initialization, but those are only on earlier GCC versions, like gcc-4.2.4 and gcc-4.3.4. The last GCC bug in this area, AFAIK, [GCC #30111] was fixed for GCC 4.4. As far as I have seen, any compiler supports value-initialization of integers, floating point numbers and pointers correctly. However, problems occur for structs, classes, and arrays. Objects of those types may be left partially or entirely uninitialized, when they should have been value-initialized, depending on the compiler. I hope to have the test and the defect macro included with Boost 1.44. Please let me know if you have any comment or question about them. https://svn.boost.org/svn/boost/trunk/libs/config/test/boost_no_com_value_i… Kind regards, Niels References: [Boost #4080] "Various compilers need BOOST_NO_COMPLETE_VALUE_INITIALIZATION", https://svn.boost.org/trac/boost/ticket/4080 [Visual Studio #100744] "Value-initialization in new-expression", reported by Pavel Kuznetsov: https://connect.microsoft.com/VisualStudio/feedback/details/100744 [Embarcadero #83751, #83851] Two value-initialization bugs I recently reported: http://qc.embarcadero.com/wc/qcmain.aspx?d=83751 http://qc.embarcadero.com/wc/qcmain.aspx?d=83851 [GCC #30111] "Value-initialization of POD base class doesn't initialize members", reported by Jason Merrill: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30111 -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

1 0

Re: [boost] [Bind] How do I get bind to deduce the return type offor_each?
by Thomas Jordan 19 Apr '10

19 Apr '10

Thomas Jordan wrote: > Thanks a lot for the suggestion, I did take a look at Lambda library, and > I saw that it used some extra type information in its STL > algorithm wrappers (the 'sig') to help it figure out the return types. > However, I am against using the Lambda library > for other reasons, I only want to use the bind library. I'd appreciate > some specific advice on how to get the type deduction > with the Boost.bind library. Or is this just not possible with > Boost.bind? Peter Dimov replied: ----------------- It's not. Boost.Bind only supports function objects with a specific, fixed type. There is no mechanism to tell it that the return type of struct myForEach { template <typename II, typename F> F operator()(II begin, II end, F function) const { return std::for_each(begin, end, function); } }; is the same as its third argument. In this specific case I'd just use struct myForEach { typedef void result_type; template <typename II, typename F> void operator()(II begin, II end, F function) const { std::for_each(begin, end, function); } }; -------------------- Thanks, Peter, and thanks to everyone else who replied, for their helpful suggestions. FWIW, I'm putting together a presentation for my colleagues, to show the facilities for higher-order programming in STL and Boost, and I wanted to show a couple of 'out-there' examples to illustrate their power. I'm a bit of an arriviste and my C++ is 'improving,' but I'm really impressed that you can do functional-style programming so nicely in C++. Regards, Tom.

2 1

libzeep
by Maarten L. Hekkelman 19 Apr '10

19 Apr '10

As I announced earlier, I've released a library that can be used to create SOAP servers. Since this code relies heavily on XML, I've implemented a full XML parser and XPath implementation as well. I've read a bit in the discussion on this forum regarding the implementation of XML parsers and I get the feeling some don't fully appreciate the amount of work that goes into writing a validating parser. There really is more to XML than the characters < and >. :-) If there's a DOCTYPE, the results of parsing a file can be surprising since the DTD can e.g. specify default attribute values. To test libzeep I'm using the 1808 test files provided by the w3c organisation. Of these I only test against 1490 since the others only check unicode characters that are allowed since XML version 1.1. Of the remaining 1490 only 14 produce dubious output, I'm not really sure if these tests are wrong or that my code is incorrect. Anyway, libzeep performs quite nicely. The code has not yet been profiled but I've been able to replace libxml2 in all my projects and see hardly any performance degradation and my code looks much better now. All in all, I think libzeep is quite feature complete, robust and performs nicely. I've released the code and minimal documentation at http://www.cmbi.ru.nl/libzeep Now suppose people here are interested in this library, I'm willing to spend some time to upgrade the code to boost quality standards and write more documentation. And if the boost community prefers another approach I'm willing to provide help based on my recent experience. I'm looking forward to your feedback. -maarten

9 15

[exception] [shared_ptr] ADL problem with msvc 10
by Steven Watanabe 19 Apr '10

19 Apr '10

AMDG I just tried to compile the following #include <boost/exception_ptr.hpp> void f() {} msvc 10 complains, 1>c:\boost\trunk\boost\smart_ptr\detail\sp_convertible.hpp(48): error C2660: 'f' : function does not take 1 arguments 1> c:\boost\trunk\boost\smart_ptr\detail\sp_convertible.hpp(66) : see reference to class template instantiation 'boost::detail::sp_convertible<Y,T>' being compiled 1> with 1> [ 1> Y=error_info_tag_t, 1> T=boost::exception_detail::error_info_base 1> ] 1> c:\boost\trunk\boost\exception\info.hpp(171) : see reference to class template instantiation 'boost::detail::sp_enable_if_convertible<Y,T>' being compiled 1> with 1> [ 1> Y=error_info_tag_t, 1> T=boost::exception_detail::error_info_base 1> ] 1> c:\boost\trunk\boost\exception\info.hpp(188) : see reference to function template instantiation 'const E &boost::exception_detail::set_info<E,boost::tag_original_exception_type,const type_info*>(const E &,const boost::error_info<Tag,T> &)' being compiled 1> with 1> [ 1> E=boost::unknown_exception, 1> Tag=boost::tag_original_exception_type, 1> T=const type_info * 1> ] 1> c:\boost\trunk\boost\exception\detail\exception_ptr.hpp(132) : see reference to function template instantiation 'const boost::unknown_exception &boost::operator <<<boost::unknown_exception,boost::tag_original_exception_type,const type_info*>(const E &,const boost::error_info<Tag,T> &)' being compiled 1> with 1> [ 1> E=boost::unknown_exception, 1> Tag=boost::tag_original_exception_type, 1> T=const type_info * 1> ] 1> c:\boost\trunk\boost\exception\detail\exception_ptr.hpp(111) : see reference to function template instantiation 'void boost::unknown_exception::add_original_type<std::exception>(const E &)' being compiled 1> with 1> [ 1> E=std::exception 1> ] This appears to be because type_info is defined in the global namespace, so ADL for boost::error_info<boost::tag_original_exception_type, const type_info *> picks up the global f. I don't have a fix for this yet. In Christ, Steven Watanabe

3 5

Fwd: [Boost-users] [Review] [ITL] ITL formal review results
by Joachim Faulhaber 19 Apr '10

19 Apr '10

---------- Forwarded message ---------- From: Joachim Faulhaber <afojgo(a)googlemail.com> Date: 2010/4/19 Subject: Re: [Boost-users] [Review] [ITL] ITL formal review results To: boost-users(a)lists.boost.org Hi Hartmut, list, 2010/4/18 Hartmut Kaiser <hartmut.kaiser(a)gmail.com>: > Hi all, > > The formal review of the Interval Template Library (ITL) written by Joachim > Faulhaber started February 18th and ended March 7th, 2010. We saw a lively > discussion resulting in 14 votes: 10 people voted unconditionally YES, 3 > voted conditionally YES, and 1 reviewer voted NO. > > The overwhelming majority of the votes was YES which reflects the overall > discussion and the general consensus of this library being worth to be > included into Boost. > > Based on this result and the discussions we saw the Interval Template > Library is now formally accepted into Boost. > > > Detailed results > ---------------- > > Pros: > > Almost all reviewers highlighted the general usefulness of the library. The > more experience the reviewers had with the library in real world > applications the more they emphasized its usefulness. Here are some quotes: > - "ITL solved this problem for me, in a way that honestly freed me from > having to think about a lot of the unsavory low-level details." > - " Until now, we only used the library for intervals of date-times (coded > as integers), but I'm sure, that its usefulness goes far beyond." > - " Very useful. I mentioned two projects where the library would have > helped me if it had been into Boost earlier, and I'm considering rewriting > them such that the problems make use of the library, and simplify them in > that way." > > The comments on the quality of the documentation are unanimous: "impressive > and quite complete", "I couldn't ask for more". It seemed to be generally > helpful to understand the concepts of the library and to get started. Some > people asked to add more simple quick-start examples to the documentation > and the distribution. > > Overall, the library is mature and easy to use. All reviewers actually > utilizing the ITL library for real world use cases reported they were able > to start quickly and without problems. > > All reviewers using ITL in real world applications stated that no > performance problems were encountered. This is important to note as the NO > vote was based on the current lack of a interval tree implementation, which > was considered to result in suboptimal performance for certain use cases. > > > Cons: > > Some aspects of the design have been criticized: "OO-type design decisions", > "fat 'one size fits all'-interval class template", and "incomplete > extraction of global functions" are the major points of critique. These > points have real merit. In order to make the design and interface more > flexible and more durable these have to be rectified before the final > inclusion of the library into Boost's code base. Joachim already agreed to a > list of things to change addressing those problems. > > For certain use cases, specifically for interval map of collections, the > current implementation has suboptimal complexity characteristics that leads > to O(n^2) space usage in the worst case. OTOH, for the majority of > applications of the library the worst case scenario seems to be (reportedly) > irrelevant. This issue has been discussed at length and Joachim plans to add > an implementation with a better worst case performance of the affected class > templates as later optimizations. This is not considered to be a > precondition to full inclusion into Boost's code base as it is not > anticipated to cause any interface changes. > > Last but not least people suggested to change the name of the library as > having the word template in the name does not carry any useful information. > Joachim already agreed to this. > > Regards Hartmut > Review Manager Thank you, Hartmut, for summarizing the review and declaring the results. I am of course happy to hear that my library of interval containers is now accepted. Concerning the review itself, I'd like to say that it was a very valuable experience for me. I definitely learned a lot during the process. So I'd like to thank all the reviewers and other participants in the discussion for taking so much time to examine my project and to share their knowledge and assessments. I'd like to emphasize two points: (1) For me as contributor is has been very rewarding to see, that my library has found quite a few users who not only use the ITL in real world applications but also confirm the usefulness of its concepts and patterns (e.g. aggregate on overlap), that simplify writing programs for problems that reoccur in a variety of problem domains. It was this basic feeling of usefulness that made me undertake the journey of boostifying, refactoring, documenting, polishing and submitting my code, which was much more work than I initially expected. But reading those reviews made me feel that it was worth the effort. So special thanks to my "real world"- users among the reviewers: Peter Wuttke, Eric Jonas, Michael Caisse and Jeff Flinn. (2) A review on the boost list is probably a challenge for most contributors. The important part is to encounter once own limitations and blind spots. Because these are the fields where one can learn most. We find these kinds of (at first) mostly unpleasant information within a boost review, when fellow developers examine the project closely and share their view on its flaws and problems. I have learned very much from that and I am currently really having fun applying those improvements to the library. So special thanks for sharing critique and objections to Phil Endecott, Luke Simonson, Jeff Flinn, John Reid and Barend Gehrels. And last but not least, I'd like to thank Rob Stewart who gave me feed back about some lingual pitfalls and oddities offlist. Very nice and helpful :) I have reworked the design on the interval concept already. I hope to be able to complete the discussed changes and improvements, as summarized by Hartmut above, within a few weeks after BoostCon2010. Cheers Joachim

1 0

[result_of] propose: change of maintainer
by Eric Niebler 19 Apr '10

19 Apr '10

Daniel Walker has volunteered to take over maintainer duties of utility/result_of from Doug Gregor, and Doug has agreed. Does anybody object? If not, I'll update the maintainers list. -- Eric Niebler BoostPro Computing http://www.boostpro.com

4 5

[RangeEx] Where is the current version?
by Mathias Gaunard 19 Apr '10

19 Apr '10

Where is the current version (or a fairly recent version) of RangeEx? I can't find anything on the trunk, the sandbox or the vault.

5 13

How to manage Graph Property ?
by nguyen vu tri 19 Apr '10

19 Apr '10

Hi everyone, I really need help to figure out the following problem. -------------------------------------------------------------------------------- First, I create a Vertex Property: typedef property < vertex_index_t, int> VertexProperties; Then, I create an adjacency graph type: typedef adjacency_list < vecS, vecS, directedS, VertexProperties > Graph; Now I can call: VertexProperties V1; --------------------------------------------------------------------------------- My question is: Is there anyway that I can access *VertexProperties *through * Graph* to create the same variable *V1* ?. Thanks, in advance, for your time. I appreciate all suggestions, Tri Nguyen.

3 5

Requesting permission to merge r61326 into release branch
by Jeremiah Willcock 18 Apr '10

18 Apr '10

This change is a one-line fix to a trivial bug where the wrong number of arguments was used in a function call. May I please merge it so it gets into 1.43.0? -- Jeremiah Willcock

3 12

Idea: Boost.Allocator
by joel falcou 18 Apr '10

18 Apr '10

I recently had to use Boost Iterator Facade and its relatives and found the idea great. It occured to me whiel lookign at my X different, hand written allocaotrs for various project that maybe such a system for writing std allocator could be great. Buildign a new allcoator will just be impelemnt some allocator_facade<> adn fill some small scale methods. Moreover, it could be the opportunity to add new allocator concept like allocator supporting resize calls, allcoator with state, allcoator with a allocated() method etc... and reality-check them in the boost framework. How does it sounds ? -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

4 5

Re: [boost] [GGL] [geometry] Inexplicable speed benefit when using Visual C++ 2010
by Stephan T. Lavavej 18 Apr '10

18 Apr '10

[Christian Buchner] > We found that GCC 4.4 on Linux was about 100% faster than Visual C++ > 2008 on Linux without modifying the code. Wow, I didn't know that VC9 could target that platform. ;-) > we attributed much of the performance difference to sub-optimal memory > heap management of Visual C++ 2008. VC's default implementation of ::operator new() calls malloc(), which calls HeapAlloc() from the Windows API. HeapAlloc()'s implementation is mostly a mystery to me, but there are a couple of things about it that you should probably be aware of. First, on WinXP and higher (note that VC9 supported targeting Win2K, but VC10 doesn't), Windows implements the Low Fragmentation Heap (LFH). The LFH services "small" allocations (definitely sub-KB; I'd have to ask around in order to figure out the precise limit) from buckets, so applications that allocate lots of small chunks of memory (like nodes) can benefit significantly from the LFH. I believe it performs other wizardry which I'm not aware of. However, on some platforms, the LFH is not enabled by default. You can request it by calling HeapSetInformation() on the CRT heap. There are two situations where the LFH is enabled by default. First, VC enables the LFH for its CRT heap when targeting x64. (For obscure reasons, we can't do this for x86.) Second, WinVista and higher automagically enable the LFH when they detect allocation patterns that would benefit from this. I've spoken to the LFH's maintainers, and they say that this automagic machinery is sufficiently smart, that enabling the LFH manually is no longer necessary (i.e. they have never seen that produce an observable benefit). > Then we tried recompiling the project with Visual C++ 2010 Ultimate > Release Candidate (RC). The speed gain of the algorithm was 900% (not > joking) and the results still appear to be correct. This greatly amuses me, as I talked about seeing order-of-magnitude performance improvements but never expected to actually see one in the real world. This is almost certainly due to rvalue references, as nothing else that we did could possibly have had so large of an effect. VC10 implemented rvalue references (v2, but not the stuff in the FCD that automatically generates move ctors/assigns), and we updated the Standard Library to take advantage of them (both by providing move ctors/assigns on Standard Library types like vector, and by taking advantage of move ctors/assigns during operations like vector reallocation). > Is anyone else seeing similar speedups in boost or in the geometry > library when compiling with Visual C++ 2010 RC (HINT: it's a free > download, so anyone can try it out until end of June 2010). Note that VC10 RC is perfectly representative of VC10 RTM. The compiler and linker are unchanged, and the Standard Library received exactly one bugfix (for obnoxious compiler errors in shared_ptr). Also note that while GCC 4.3 and higher support rvalue references (v1 in 4.3 and 4.4, v2 in 4.5), they are not enabled by default. You must compile with either -std=c++0x or -std=gnu++0x in order to activate their C++0x mode. I'd be interested to learn how VC10 fares against GCC in C++0x mode. (I'm unsure as to when and to what extent rvalue references were applied to GCC's Standard Library implementation libstdc++. As GCC 4.5 was released mere days after VC10, that would generate the most fair comparison.) About _SECURE_SCL, the worst performance penalty that I've ever seen it exact is 2x. It could have been responsible (along with allocator mumbo-jumbo) for the 100% difference you observed between GCC 4.4 and VC9, but not for the 900% difference between VC9 and VC10 (unless you have discovered a truly astounding pathological case). _SECURE_SCL (now combined with _HAS_ITERATOR_DEBUGGING into _ITERATOR_DEBUG_LEVEL) in VC10 is now disabled by default in release mode. (In debug mode, _HAS_ITERATOR_DEBUGGING, aka _ITERATOR_DEBUG_LEVEL=2, is still enabled by default - it can affect performance significantly, but provides exhaustive correctness checks, and debug performance isn't especially important unless it's 1000x slower and renders the program too slow to debug.) VC10's linker now deterministically detects when you're mixing translation units compiled with different settings of _ITERATOR_DEBUG_LEVEL, so that (combined with the new default of 0 in release mode) will put an end to the bad old days of incomprehensible ODR violations triggered by attempting to disable this machinery in some but not all libraries. Do note that mixing major compiler versions (e.g. VC9 and VC10) is still completely forbidden when you're using the C++ Standard Library, as we break binary compatibility between every major version and will continue to do so for the foreseeable future. Unfortunately, the linker's new feature (#pragma detect_mismatch) is unable to detect VC9 and VC10 mixing, so you'll just have to be careful. (The machinery is in place for us to detect VC10 and VC11 mixing.) [Barend Gehrels] > I've asked last year during BoostCon to Microsoft, present there, if > they knew this issue, but apparently they didn't, and told me it would > surprise him because the compiler basically was the same. (That was me.) > When I used after that once the VC 2008 command line compiler (so not > from Visual Studio) the problem disappeared. So it was fast. So it was > not the compiler itself, it was some setting in the IDE or VPROJ. I've > never managed to find which setting, though I studied it carefully. According to my understanding, the VS 2008 IDE had a bug when upgrading VS 2005 projects, where optimization settings would be lost. I'm unsure of what the exact symptoms of the bug looked like (I thought it was just the /O options), but your experience (that it disappeared when you used the command line) perfectly fits with this hypothesis. Alternatively, you could create a VS 2008 project from scratch. I believe that VS 2010's project system (which underwent a massive overhaul) does not suffer from this bug when upgrading either VS 2005 or VS 2008 projects, but I don't know what happens when you take a project that was damaged by the VS 2005 to VS 2008 upgrade, and then upgrade it to VS 2010. I suspect that in that case, the damage persists. My understanding of this is vague because I don't use IDE build systems. Stephan T. Lavavej Visual C++ Libraries Developer

2 1

[call-traits][param_type] why is sizeof(void*) chosen as the limit for passing by value?
by Thorsten Ottosen 17 Apr '10

17 Apr '10

Hi Boosters, It seems to me that many other slightly larger types could benefit from pass by value. For example, I rarely write foo( const double& ); but always foo( double ); So param_type<T>::type don't even follow this guideline. I tried a simple example program for the auto_buffer (vector like) class I'm implementing: #include <boost/auto_buffer/auto_buffer.hpp> int main() { boost::auto_buffer<double> buf( 2001u ); buf.push_back(42.); } When I pass by value in push_back(), the assembler is somewhat different, and as far as I can tell, better. Basically my compiler (vc9) can inline the load of 42. into push_back() whereas in the call by reference, the parameter is passes by a pointer (in a register). In the by-value version the compiler is able to optimize away completely the call to alllocate and delete memory whereas this is not so for the by-reference version. This makes me wonder why we shouldn't expect e.g. std::pair<int,int> and std::bitset<64> to be easily passable in registers. With this in mind, I think we should consider changing the limit for param_type to sizeof(long double) or even 2*sizeof(int). Of course, we should only pass types with a trivial assignment operator by value. Any thoughts? -Thorsten

4 4

Re: [boost] [Bind] How do I get bind to deduce the return type of for_each?
by Thomas Jordan 17 Apr '10

17 Apr '10

> Message: 8 > Date: Thu, 15 Apr 2010 10:51:27 +0100 > From: "Sylvester-Bradley, Gareth" > <Gareth.Sylvester-Bradley(a)eu.sony.com> > To: <boost(a)lists.boost.org> > Subject: Re: [boost] [Bind] How do I get bind to deduce the return > type offor_each? > Message-ID: > <84883B934769D3428C4AE2E403B188800A1A0F9A(a)GBISE0BASMSX02.eu.sony.com> > Content-Type: text/plain; charset="us-ascii" > >> I have been trying to use Boost.bind to create an 'STL algorithm > function >> object' to pass into another, 'higher order,' STL algorithm (e.g., to > pass >> a for_each into a for_each). However, I am struggling to get bind to >> deduce the correct return type of the for_each function object. > > The following might help: > > http://www.boost.org/doc/libs/1_42_0/doc/html/lambda/le_in_details.html# > lambda.nested_stl_algorithms > > > Best regards, > Gareth > Thanks a lot for the suggestion, I did take a look at Lambda library, and I saw that it used some extra type information in its STL algorithm wrappers (the 'sig') to help it figure out the return types. However, I am against using the Lambda library for other reasons, I only want to use the bind library. I'd appreciate some specific advice on how to get the type deduction with the Boost.bind library. Or is this just not possible with Boost.bind?

4 3

(no subject)
by Dan Jiang 16 Apr '10

16 Apr '10

Hi All, I have a question regarding CSR graph. Does anyone know if a CSR graph can be used as input to push_relabel_max_flow or edmonds_karp_max_flow algorithm in BOOST? The existing examples only use adjacency_list with the maximum flow algorithms. I need to use CSR graph with the max flow implementations, but do not know how and if it is feasible at all. If answer is yes, can anyone give a simple example? I am having trouble in setting capacity map and reverse_edge map in CSR before passing it to the max flow algorithms. -Thanks a lot for your time. Dan Jiang _________________________________________________________________ Live connected. Get Hotmail & Messenger on your phone. http://go.microsoft.com/?linkid=9724462

2 10

[xint] Question about suitability, portability, and "Boostiness"
by Chad Nelson 16 Apr '10

16 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Right now, the XInt library uses a pointer to a (privately defined) struct. The struct has several items, including a small array of "quick digits" and a pointer to a dynamically allocated array of digit_t types, both for containing the magnitude of the integer. While trying to find a more efficient way to store things, I came up with this: struct new_data_t { size_t used, allocated; // (other data items) digit_t digits[1]; // Last item in the struct }; It's an old C trick, apparently legitimized in the C99 standard as the "struct hack". For those not familiar with it, the idea is that I'd allocate a single array of digit_t types, of the required size plus sizeof(new_data_t), then just typecast it as a pointer of type new_data_t. Does anyone know if there's any reason not to do this? Maybe some portability or alignment problem with it? - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvD3ZQACgkQp9x9jeZ9/wQLdQCgklN2Xcs0mDAGhsy4n3TX/Bgw JVoAoK+/YEoawXT7Yd0R3++eWLPYZhjr =Jx8O -----END PGP SIGNATURE-----

4 15

Re: [boost] How to construct a reverse_edge_map from CSR
by Dan Jiang 16 Apr '10

16 Apr '10

Hi Jeremiah, Here is the code for this error. Hope it is more readable. typedef compressed_sparse_row_graph<directedS> Traits; struct EdgeProp{ float capacity; float residual_capacity; Traits::edge_descriptor reverse_edge; }; typedef compressed_sparse_row_graph<directedS, property<vertex_index_t, DWORD32>, EdgeProp, // bundled property no_property, // Graph Property DWORD32, // Vertex Type DWORD32> // EdgeIndex Type BOOST_Graph; Errors: C:\Program Files (x86)\boost\boost_1_42\boost/graph/compressed_sparse_row_graph.hpp(1321) : error C2780: 'V boost::target(const incidence_graph_archetype<Vertex,Directed,ParallelCategory,Base>::edge_descriptor &,const boost::incidence_graph_archetype<Vertex,Directed,ParallelCategory,Base> &)' : expects 2 arguments - 1 provided C:\Program Files (x86)\boost\boost_1_42\boost/graph/graph_archetypes.hpp(64) : see declaration of 'boost::target' .\NetFlow.cpp(209) : see reference to function template instantiation 'std::pair<_Ty1,_Ty2> boost::edge<boost::directedS,boost::property<Tag,T>,EdgeProp,boost::no_property,unsigned int,DWORD32>(Vertex,Vertex,const boost::compressed_sparse_row_graph<Directed,VertexProperty,EdgeProperty,GraphProperty,Vertex,EdgeIndex> &)' being compiled with [ _Ty1=boost::detail::csr_edge_descriptor<size_t,size_t>, _Ty2=bool, Tag=boost::vertex_index_t, T=DWORD32, Vertex=unsigned int, Directed=boost::directedS, VertexProperty=boost::property<boost::vertex_index_t,DWORD32>, EdgeProperty=EdgeProp, GraphProperty=boost::no_property, EdgeIndex=DWORD32 ] C:\Program Files (x86)\boost\boost_1_42\boost/graph/compressed_sparse_row_graph.hpp(1321) : error C2780: 'Vertex boost::target(compressed_sparse_row_graph<Directed,VertexProperty,EdgeProperty,GraphProperty,Vertex,EdgeIndex>::edge_descriptor,const boost::compressed_sparse_row_graph<Directed,VertexProperty,EdgeProperty,GraphProperty,Vertex,EdgeIndex> &)' : expects 2 arguments - 1 provided Error line is: if (target(*range.first) == j) C:\Program Files (x86)\boost\boost_1_42\boost/graph/compressed_sparse_row_graph.hpp(1241) : see declaration of 'boost::target' C:\Program Files (x86)\boost\boost_1_42\boost/graph/compressed_sparse_row_graph.hpp(1321) : error C2780: 'Vertex boost::target(const boost::detail::edge_base<Directed,Vertex> &,const boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,EdgeProperty,GraphProperty,EdgeListS> &)' : expects 2 arguments - 1 provided C:\Program Files (x86)\boost\boost_1_42\boost/graph/adjacency_list.hpp(530) : see declaration of 'boost::target' C:\Program Files (x86)\boost\boost_1_42\boost/graph/compressed_sparse_row_graph.hpp(1321) : error C2780: 'filtered_graph_base<G>::vertex_descriptor boost::target(filtered_graph_base<G>::edge_descriptor,const boost::filtered_graph_base<G> &)' : expects 2 arguments - 1 provided: Error line is: if (target(*range.first) == j) > > Could you please reformat your code to be more readable? What is the > exact type of your graph, and what are the definitions of the vertex and > edge bundled property classes? > > -- Jeremiah Willcock > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _________________________________________________________________ Live connected. Get Hotmail & Messenger on your phone. http://go.microsoft.com/?linkid=9724462

2 1

How to construct a reverse_edge_map from CSR
by Dan Jiang 16 Apr '10

16 Apr '10

Hi All, I am having difficulty in constructing a reverse_edge_map from an existing CSR. My CSR was created as "edges_are_unsorted", I need to create a reverse_edge_map out of it? Here is my attempt:1 BGL_FORALL_EDGES(e, g, BOOST_Graph)2 {3 // Get source and target of the edge4 BOOST_Graph::vertex_descriptor src = boost::source(e, g);5 BOOST_Graph::vertex_descriptor dst = boost::target(e, g);678 // Get reverse edge9 graph_traits<BOOST_Graph>::out_edge_iterator ei, ei_end;10 for (tie(ei, ei_end) = edge_range(dst, src, g); ei != ei_end; ++ei) 11 {12 rev[*e] = *ei;13 break; // I know there is only one reverse edge in my graph14 } 15 } I got compile error on line 10: error C2784: 'std::pair<Config::out_edge_iterator,Config::out_edge_iterator> boost::edge_range(Config::vertex_descriptor,Config::vertex_descriptor,const boost::adj_list_helper<Config,Base> &)' : could not deduce template argument for 'const boost::adj_list_helper<Config,Base> &' from 'BOOST_Graph' where BOOST_Graph is a CSR graph that has been instantiated as "edges_are_unsorted" prior to the loop. Any help is appreciated. -Thanks, Dan _________________________________________________________________ Got a phone? Get Hotmail & Messenger for mobile! http://go.microsoft.com/?linkid=9724464

2 1

Re: [boost] Crypto Proposal
by Chad Seibert 16 Apr '10

16 Apr '10

Hello, > Does this mean you will be converting the source-code of Botan to Boost > standards or you are going to wrap it? > 1. If it is conversions two issues may rise: > a) License Botan is licensed under BSD license with is different from > Boost and all the code you will write for boost would not have > correct license. > b) Conversion to Boost means fork... How do you expect to synchronize > changes in two libraries and most important security updates. > This means lots of work in the live cycle of Boost.Botan I'll fork it, as stated in my proposal (which I sent sometime after the abstract). It'll be relicensed under BSL. As for synchronization, this will have to be done by hand (which I will do for some time). > Additional points: > - Botan uses GNU gmp library licensed under LGPL... Does it fit to > Boost licensing guidelines? It doesn't require gmp and is perfectly capable of working without it. It's available as a plugin, but a default implementation is already included. > - I think that you should be really specific what would be the advantage > of using Boost.Botan library over original Botan one or OpenSSL that > Boost.Asio uses. Here are some: * Tighter integration with Boost (ASIO, and possibly iostreams) * Some functions are considerable faster (such as RSA, which the maintainer purports to be several times faster than OpenSSL. SHA-1 is SSE2 optimized). * There is plugin support for OpenSSL, so ASIO would be modified to use the plugin system (which would use the default implementation or OpenSSL). > You might want to consider adding some discussion to your proposal about the > crypto library in the vault. What features are in the vault Crypto that > might be useful? That aren't useful? Why do you feel that Botan is a better > starting point. The crypto library in the vault contains mostly hash algorithms, which Botan already contains (and some of them e.g. SHA-1 have a SSE optimized version). And Botan contains better documentation and testing. Also, Botan was engineered mostly by a security expert, meaning it is likely to be more secure. It is also being maintained, so security and feature patches will be made. > Your proposal is very ambitious! IMHO, that's not doable in full over the > summer. If you trimmed it down into a more focused feature set (for instance > replacing SSL in ASIO, or adding TLS to ASIO) it would give you a more > realistic chance to finish what you are suggesting. It is very ambitious! But as I say in my draft, it'll be done in two parts. I don't think that porting is unrealistic for the summer part of the project. Many thanks for the feedback, Chad Seibert _________________________________________________________________ The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28…

3 6

Re: [boost] Crypto Proposal
by Chad Seibert 16 Apr '10

16 Apr '10

Here's a response to a question asked on the private review system: The design and architecture is based on dynamic polymorphism, for better or worse. In the process of porting it to Boost.Botan, it would be made static. On the mailing list, someone created a simple project that creates a certificate and the exe grew from 40kb to 1mb. Having static polymorphism would solve this problem. Also, we won't have to pay the runtime penalties for dp (especially since it's not needed - something that Boost libraries have shown time and time again). Looking at other libraries under similar licenses yielded similar results. Crypto++ also uses DP (and has even larger hierarchies) and for simple uses, the entire library get's built and included with project. For example, http://www.cryptopp.com/docs/ref/class_s_h_a1.html. SP will solve this problem, and Botan uses less DP which should make it easier to convert. I couldn't find a valid libtomcrypt homepage, so I don't know how it's structured. The interface of Botan is simple and intuitive. Looking at their sample programs (and other samples), there doesn't seem to be a simpler method to implement the various techniques and still remain flexible. Crypto++ samples seem to be a bit difficult to digest, requiring manual creation of secure memory blocks and ugly dynamic casting. More can be seen here: http://www.cryptopp.com/wiki/Diffie-Hellman. All in all, Botan has a simpler interface and a DP hierarchy that shouldn't be (as) difficult to convert to SP. I wanted to compare against libtomcrypt, but couldn't find a valid implementation. An example of how something might get ported would be the following. Botan.AES_128 has the inheritance hierarchy Botan->SymmetricAlgorithm->BlockCipher->AES->AES_128. Writing this as SP would look like the following (if I understand SP correctly): Before: class SymmetricAlgorithm { void set_key(...) } class BlockCipher: SymmetricAlgorithm { virtual void encrypt(...) virtual void decrypt(...) } class AES: BlockCipher { void encrypt(...); void decrypt(...); } class AES_128: AES { } There is no reason for AES. I'd first remove that class and have AES_128 derive from BlockCipher directly. Converting this to SP yields (sorry, I don't have a compiler to test this atm): template<class BlockCipher> struct SymmetricAlgorithm { void set_key_impl() { static_cast<*BlockCipher>(this)->set_key(); } } template <class AES_128> struct BlockCipher: SymmetricAlgorithm<BlockCipher>{ void set_key(); //More stuff } However, there is one concern. SymmetricAlgorithm is the base class of three major hierarchies: BlockCipher, MessageAuthenticationCode, and StreamCipher. If this inheritance hierarchy stays, it will mean lot's of template metaprogramming (some of which I don't know how to do). In any case, it's easier to work with than Crypto++. For example, SHA1 in Crypto++ has a hierarchy depth of 9; Botan 5. Hope this answers some questions! Glad you are interested in my work! Chad Seibert _________________________________________________________________ The New Busy is not the old busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…

4 3

space complexity of push_relabel_max_flow
by Dan Jiang 16 Apr '10

16 Apr '10

Hi All, I am a new BOOST user and like it very much. I have a question regarding space complexity of push_relabel_max_flow. The push_relabel_max_flow is very efficient compared to Edmond's and Karp. In my application, I need to deal with half a million nodes and half a billion arcs. It requires lots of ram (>= 6gb). Two questions: 1) How do I find out space used per node and per arc? 2) My network does not need any reverse edge (currently I set the capacity of reverse edge to 0), is there anyway to not supply reverse edges to save space? 3) Does push_relabel_algorithm dynamically allocates lots of memory (besides the ram required by the input graph, i.e., adjacency_list)? 4) Is it possible to implement custom file-based edge lists so that I could explicitly page to disk when not enough ram is available? How slower would it be? Thanks, Dan Jiang _________________________________________________________________ Hotmail & Messenger. Get them on your phone now. http://go.microsoft.com/?linkid=9724463

3 17

[Bind] How do I get bind to deduce the return type of for_each?
by Thomas Jordan 15 Apr '10

15 Apr '10

Hi, I have been trying to use Boost.bind to create an 'STL algorithm function object' to pass into another, 'higher order,' STL algorithm (e.g., to pass a for_each into a for_each). However, I am struggling to get bind to deduce the correct return type of the for_each function object. I include the relevant bits of the code below. class myClass { public: int func(){return mValue;} private: int mValue; }; //wrapper for STL for_each struct myForEach { template <typename II, typename F> F operator()(II begin, II end, F function) const { return std::for_each(begin, end, function); } }; typedef vector<myClass> vocType; typedef vector<vocType> vovType; //overloaded member functions vocType::begin & end typedef vocType::iterator (vocType::*fnPtr)(); typedef const vocType::iterator (vocType::*constFnPtr)() const; vovType vov(10, vocType(10, myClass())); main() { for_each(vov.begin(), vov.end(), bind< ? >(myForEach(), bind(static_cast<fnPtr>(&vocType::begin),_1), bind(static_cast<fnPtr>(&vocType::end),_1), protect(bind(&myClass::func, _1))) } I tried various things for bind<?>, but was only able to get the code to compile (eventually) on my Unix box when I substituted bind< boost::_bi::protected_bind_t<boost::_bi::bind_t<int, boost::_mfi::mf0<int, myClass>, boost::_bi::list1<boost::arg<1> (*)()> > > > for the bind<?>. I had guessed this might work from studying the compiler error messages. Obviously, this is not an ideal solution! Also, I only used the myForEach wrapper after having first attempted - and similarly failed - to bind the raw STL for_each. Is there any way I can help bind to deduce the correct return type - for either myForEach or std::for_each, or both? WIth Best Regards, Tom Jordan (Software Engineer)

3 2

Permission to merge Interprocess/Intrusive bugfixes for 1.43 in release branch?
by Ion Gaztañaga 15 Apr '10

15 Apr '10

Hi, I know it's a bit late, but I would like to ask if it's possible to merge Interprocess/Intrusive bug-fixes from trunk to release. They've been in trunk for some weeks and tests are ok. Best, Ion

5 8

[contract] with Boost.Parameter (was "Contract Programming Library")
by Lorenzo Caminiti 15 Apr '10

15 Apr '10

On Wed, Feb 17, 2010 at 4:05 AM, Andrzej Krzemienski <akrzemi1(a)gmail.com> wrote: >> > it is inevitable, etc., but.. read on. I know at least one library in >> > Boost that also spoils function declarations in order to provide >> > additional functionality: Concept Check library; they may be others >> > too (MPL?). >> > My suggestion is that if there are (or will be) libraries that require >> > spoiling function declarations, they should all provide the same >> > "spoiled" syntax. Otherwise I will be always asking "how do I declare >> > a function in this library?". It would be very convenient if Boost >> > provided one alternative function definition syntax that when used >> > would enable all its libraries to work. >> >> I agree. However, in the past I did look into harmonizing my library >> API with the ones of Boost.ConceptCheck and/or Boost.Parameter but it >> did not seem feasible... I will double check it. > > This is not only about clarity. As a super-correct programmer I may want to > apply both concept checking and pre-/post-conditions checking to my functions. > > Perhaps, if the 'compromise' syntax is possible, it requires changing > concept-checking library. I have verified that it is possible to use Boost.Parameter together with the current implementation of Boost.Contract. However, I have not yet verified compatibility with the entire set of Boost.Parameter features (template parameters, free-functions, etc). #include <boost/parameter.hpp> #include <boost/graph/depth_first_search.hpp> #include <contract.hpp> #include <iostream> namespace graphs { BOOST_PARAMETER_NAME(graph) BOOST_PARAMETER_NAME(visitor) BOOST_PARAMETER_NAME(root_vertex) BOOST_PARAMETER_NAME(index_map) BOOST_PARAMETER_NAME(color_map) struct g { CONTRACT_CLASS( (g) ) BOOST_PARAMETER_MEMBER_FUNCTION( (void), depth_first_search, tag, (required (graph, *) ) (optional (visitor, *, boost::dfs_visitor<>()) (root_vertex, *, *vertices(graph).first) (index_map, *, get(boost::vertex_index, graph)) (in_out(color_map), *, default_color_map(num_verticies(graph), index_map)) ) ) CONTRACT_FUNCTION( (public) (template)( (typename)(graph_type) (typename)(visitor_type) (typename)(root_vertex_type) (typename)(index_map_type) (typename)(color_map_type) ) (void) (depth_firt_search)( (graph_type&)(graph) (visitor_type&)(visitor) (root_vertex_type&)(root_vertex) (index_map_type&)(index_map) (copyable)(color_map_type&)(color_map) ) (postcondition) ({ CONTRACT_ASSERT( color_map == CONTRACT_OLDOF(color_map) + 10 ); }) (body) ({ color_map += 10; std::cout << "graph=" << graph << std::endl; std::cout << "visitor=" << visitor << std::endl; std::cout << "root_vertex=" << root_vertex << std::endl; std::cout << "index_map=" << index_map << std::endl; std::cout << "color_map=" << color_map << std::endl; }) ) }; } // namespace int main() { using namespace graphs; g gg; int cm = 0; gg.depth_first_search(1, 2, 3, 4, cm); std::cout << std::endl; gg.depth_first_search("1", '2', _color_map = cm, _index_map = "4", _root_vertex = "3"); return 0; } This function declaration syntax is terrible as it mixes the syntactic complexity of both Boost.Parameter and Boost.Contract... I will try to provide the following syntax instead: CONTRACT_FUNCTION( (public) (void) (depth_first_search)( // No (tag)(namespace-id) so use `tag`. // (auto) for no type requirements (preprocessor can't use `*`). (auto) (graph) // (default) for optional param. (auto) (visitor) (default)(boost::dfs_visitor<>()) (auto) (root_vertex) (vertices(graph).first) (auto) (index_map) (default)(get(boost::vertex_index, graph)) // (inout) for in-out type. (copyable)(inout)(auto) (color_map) (default) (default_color_map(num_verticies(graph), index_map)) // Plus, (deduced)( parameter-sequence ) for deduced params. ) (postcondition) ( (color_map == CONTRACT_OLDOF(color_map) + 10) ) ({ color_map += 10; std::cout << "graph=" << graph << std::endl; ... }) (IMO, this syntax looks cleaner that the original Boost.Parameter one.) -- Lorenzo

1 0

[intrusive.set] Accessing the last (largest) element.
by Andy Venikov 15 Apr '10

15 Apr '10

Since there is no "back" method for intrusive set, what's the best way to access the last (greatest) element? Is this OK:? IntrusiveSet set1; IntrusiveSet::iterator itEnd = set1.end(); //Make sure that set isn't empty. Value v = *--itEnd; ++itEnd; //will itEnd point to set1.end() after this? In general, is there anything sinister about this construct? (provided that the set isn't empty) Thanks, Andy.

2 2

[asio] read_until -- possibly misleading documentation?
by Richard Smith 15 Apr '10

15 Apr '10

The documentation for Boost.ASIO (which is otherwise very comprehensive) says of the boost::asio::read_until set of overloads: | Read data into a streambuf until a delimiter is | encountered. <http://www.boost.org/doc/libs/1_35_0/doc/html/boost_asio/reference/read_unt…> What the function actually does is to read blocks of data into the streambuf, and stop when the delimiter is found. This means that frequently data beyond the delimiter will be read into the streambuf. (And this is elaborated in more detail on the individual function's pages, if a reader looks there.) I appreciate that this behaviour is compatible with the documentation, but someone less familiar with ASIO could easily assume that the function will read as far as the delimiter and no further. (And I have just spent a fair amount of time debugging a piece of code where the author had made this assumption.) Could we change the summary documentation to read something like: | Read data into a streambuf at least until a delimiter is | encountered. The implementation may read beyond the | delimiter, but will not block when doing so. While I'm on the subject of ASIO documentation, I can't see any documentation on whether the service_name parameters to the basic_resolver_query constructors are allowed to be port numbers (e.g. "80") or whether they have to be symbolic names (e.g. "http"). Port numbers work, at least on Linux, but it's not clear whether this is something that I should be relying on. Similarly for IPv4 and IPv6 addresses in the host_name parameter. Richard Smith

3 2

[contract] concepts (was "Contract Programming Library")
by Lorenzo Caminiti 15 Apr '10

15 Apr '10

On Wed, Feb 17, 2010 at 4:05 AM, Andrzej Krzemienski <akrzemi1(a)gmail.com> wrote: >> > it is inevitable, etc., but.. read on. I know at least one library in >> > Boost that also spoils function declarations in order to provide >> > additional functionality: Concept Check library; they may be others >> > too (MPL?). >> > My suggestion is that if there are (or will be) libraries that require >> > spoiling function declarations, they should all provide the same >> > "spoiled" syntax. Otherwise I will be always asking "how do I declare >> > a function in this library?". It would be very convenient if Boost >> > provided one alternative function definition syntax that when used >> > would enable all its libraries to work. >> >> I agree. However, in the past I did look into harmonizing my library >> API with the ones of Boost.ConceptCheck and/or Boost.Parameter but it >> did not seem feasible... I will double check it. > > This is not only about clarity. As a super-correct programmer I may want to > apply both concept checking and pre-/post-conditions checking to my functions. > > Perhaps, if the 'compromise' syntax is possible, it requires changing > concept-checking library. I have verified that it is possible to use Boost.ConceptCheck together with the current implementation of Boost.Contract as shown below. I will look into doing something similar also for Boost.Parameter. #include <boost/concept_check.hpp> #include <boost/concept/requires.hpp> #include <contract.hpp> #include <iostream> struct x { CONTRACT_CLASS( (x) ) template<typename T> BOOST_CONCEPT_REQUIRES( ((boost::Integer<T>)), (int)) f(const T& x) CONTRACT_FUNCTION( (public) (template)( (typename)(T) ) (int) (f)( (const T&)(x) ) (precondition) ({ CONTRACT_ASSERT( x >= 0 ); }) (postcondition) (result) ({ CONTRACT_ASSERT( result == x ); }) (body) ({ return x; }) ) }; int main() { x xx; std::cout << xx.f(123) << std::endl; // OK: Passes both concept and contract checks. // std::cout << xx.f(1.23) << std::endl; // Error: Fails concept check (compile-time). // std::cout << xx.f(-123) << std::endl; // Error: Fails contract precondition check (run-time). return 0; } This works because CONTRACT_FUNCTION() follows the function declaration which can be spoiled by BOOST_CONCEPT_REQUIRES() as usual to support concepts. However, I am planning to change CONTRACT_FUNCTION() so the function declaration tokens do not need to be repeated and I will add concept support following ConceptC++ syntax: CONTRACT_FUNCTION( (public) (template)( (typename)(T) ) (requires)( (boost::Integer<T>) ) (int) (f)( (const T&)(x) ) (precondition)( (x >= 0) ) (postcondition)(result)( (result == x) ) ({ return x; }) ) This will call Boost.ConceptCheck behind the scenes. Even after this change to CONTRACT_FUNCTION(), Boost.Contract will still provide a CONTRACT_FUNCTION_DEF() that will follow the function declaration (as the current implementation of CONTRACT_FUNCTION() does). Therefore, the example above where Boost.ConceptCheck is used directly can still be programmed using the DEF() macro. Lorenzo

1 0

[date_time][patch] #2757: Warning C4244: conversion from 'int' to 'unsigned short' in microsec_time_clock.hpp line 103
by Sylvester-Bradley, Gareth 15 Apr '10

15 Apr '10

Ticket #2757 describes a simple patch for Boost.Date_Time to get rid of some annoying compiler warnings. Is anyone actively maintaining Boost.Date_Time? This patch has been sitting there for 6 releases already... https://svn.boost.org/trac/boost/ticket/2757 Thanks. ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards

2 1

[contract] importance ordering (was "diff n1962")
by Lorenzo Caminiti 14 Apr '10

14 Apr '10

Hello all, On Thu, Apr 8, 2010 at 7:26 PM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> wrote: > Below is a summary of the differences between Boost.Contract and the > Contract Programming C++ standard proposal n1962. I know some of the > authors of n1962, and also of its previous revisions, are on this > mailing list -- I hope that they can provide comments at least. > > [n1962] Crowl and T. Ottosen, Proposal to add Contract Programming to > C++ (revision 4), The C++ Standards Committee, 2006. All previous > revisions of this proposal are also relevant (and related authors > comments encouraged). I would like to ask: Should Boost.Contract support assertion importance ordering? Importance ordering was introduced in revision 3 of the CP C++ standard proposal but then removed in revision 4: * From n1866 (n1962 revision 3) section 2.1.2 << default assertions syntax: 1. runtime-assertion : boolean-expression importance-ordering opt ; 2. importance-ordering : : integer-constant 8. Importance ordering allows users to specify multiple levels of assertions. The higher an integer, the more crucial it is to keep an assertion in the object code. 9. The default importance ordering is 0 and is in effect when no integer is specified.>> * From n1962 (revision 4) <<Removed the notion of "importance ordering" [10]. [10] (1, 2) In many contexts it is useful to inform the compiler of certain properties. This is true for efficient garbage collection as well as Contract Programming. The same mechanism may be reused to tag a piece of code with some property; in this case we would like to tag individual assertions.>> For example: void f(int x) precondition { x >= 0 : 100; // Importance ordering 100. find(v.begin(), v.end(), x) != v.end(); // Default importance ordering of 0. } ... And in Boost.Contract the syntax: CONTRACT_FUNCTION( (void) (f)( (int)(x) ) (precondition) ( ( x >= 0 )(importance)(100) // Importance ordering 100. ( find(v.begin(), v.end(), x) != v.end() ) // Default importance ordering of 0. ) ... ) Boost.Contract could then provide an API to say "compile and check only assertions with importance ordering within <user-specified-range>". One use case for this is to tag assertions that are expensive to check with a lower importance so they can be disabled selectively to achieve better performance trade off (this was suggested by Andrzej). [Mitchell2002] addresses this use case recommending to never program expensive assertions in preconditions because they will likely be part of production releases (while expensive assertions in postconditions and possibly invariants are acceptable because they, and their run-time overhead, will be removed from production releases). However, this is a binary approach whereas importance ordering would provide a more granular control tool to achieve better performance trade-offs. I would personally recommend for Boost.Contract to support importance ordering -- what do you think? Thank you. Lorenzo

2 1

Re: [boost] [range] iterator_range::operator[] broken
by Eric Niebler 14 Apr '10

14 Apr '10

Neil, let's keep this discussion on-list. It's important. On 4/14/2010 12:21 AM, Neil Groves wrote: > On Wed, Apr 14, 2010 at 7:13 AM, Eric Niebler <eric(a)boostpro.com> wrote: > >> On 4/13/2010 8:03 PM, Steven Watanabe wrote: >>> AMDG >>> >>> Eric Niebler wrote: >>>> Neil, I know you patched this a mere 5 hours ago, but it's still broken. >>>> The attached patch *really* fixes the problem, I think. >>> >>> Whoa. Why is this only returning a real reference for pointers? >> >> Yeah, I dunno. It's this way on the release branch, too. It's very, very >> seriously broken. I think we need to revert range on the release branch >> to the 1.42 version, and fast. >> > I would much prefer to revert just iterator_range.hpp as the change to > handle iterator proxies is orthogonal to the other changes. The change as > applied attempts to leverage the same mechanism as is used in the > iterator_facade to provide a real reference or a proxy where appropriate for > the index operator. It is a breaking interface change in a core library. What is the technical reason for it? >> Neil? >> > I need to take another look at the code and perhaps the operator[] of > iterator_range is broken, but I believe that this issue aside that the other > changes are working well. It would be extremely disappointing to revert all > of the adaptors, and algorithms just because of this issue. I'm more than > happy to fix the problem as soon as I can. I'm seeing massive breakages all over trunk and release, not all of which are related to the changed return type of iterator_range::operator[]. For instance, there seems to be some new ambiguity in the "detail" symbol. See for instance: http://beta.boost.org/development/tests/release/developer/output/RW_WinXP_V… I can't be certain at this point if RangeEx is responsible, but it's where I would start looking. Could you have a look and report back? == Volunteers Needed === If anybody else is reading this: please look at the regressions on the release branch here: http://beta.boost.org/development/tests/release/developer/summary.html. Pick a broken library that interests you and figure out why it's busted. Report back. -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 3

Re: [boost] Crypto Proposal
by Chad Seibert 14 Apr '10

14 Apr '10

Straight from the maintainer. Hi Chad, I don't think I would be comfortable with this; past conversations on the list have suggested a sizeable population of the users is avoiding boost for one reason or another and there was some pushback in terms of even using boost in the library in a way that would require it for basic functionality. This change would leave these users high and dry. I'll admit I perhaps didn't read your proposal as carefully as I should have; I had been under the impression that you would be creating more or less a boost.crypto that provided crypto functionality that happened to use botan internally but did not expose much or any of botan's API directly. Sorry for the miscommunication/mess. :( -Jack I don't know what this means in terms of the project - whether we'll go with a different project or just borrow bits from Botan. I am truly sorry I didn't look into this earlier; it was entirely my fault and I apologize for not looking into this issue earlier. Chad Seibert _________________________________________________________________ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…

3 2

Re: [boost] Crypto Proposal
by Chad Seibert 14 Apr '10

14 Apr '10

Thanks for all the feedback! > On 11/04/2010 7:25 PM, Rob Riggs wrote: > On 04/11/2010 10:53 AM, Chad Seibert wrote: >> Here's an example of boostified code, from one of the examples on the >> site. It's not too different from the original code (it's just >> commented out); this is because I don't want it to be a chore to port >> from Botan to Boost.Botan. Also, it is intuitively designed and I see >> no reason to change it. Of course, if it needs redesigning, we can >> discuss that afterwards > ... >> //std::auto_ptr<PKCS8_PrivateKey> >> privkey(PKCS8::load_key(arg_ca_key, rng, arg_passphrase)); >> std::auto_ptr<boost::botan::pkcs8::private_key> >> privkey(pkcs8::load_key(arg_ca_key, rng, arg_passphrase)); > Hi Chad, > > Would it make sense to have privkey() return the private key by value? > Is it non-copyable? > I think the reason is because a PKCS#8 key can be RSA/DSA or whatever else. > I'd like to be able to hold keys by value but I'm not sure whether that > is useful. I can't really see a need to copy keys around, but then again > who knows? > A Boostified Botan should consider this problem as Botan requires the > use of lots of yucky pointers in places because of the polymorphism. It's returned by pointer, since private keys are memory locked by SecureVector (see http://files.randombit.net/botan/doxygen/html/namespaceBotan_1_1PKCS8.html) to prevent flushing to disk (and other potential bugs noted here: http://files.randombit.net/botan/doxygen/html/secmem_8h-source.html) A bigger issue I see is AlgorithmIdentifier/OID mess I see in http://files.randombit.net/botan/doxygen/html/namespaceBotan.html#378aea09f…. Definitely needs to get replaced with something else. There is some rational reasoning with this, though. For example, when we load a pksc#8 key, we get an algo id, which leads to a huge if/else if statement (http://files.randombit.net/botan/doxygen/html/namespaceBotan.html#378aea09f…) It's also dependent on which libraries get build (the BOTAN_HAS_* defines). In any case, it's still far from perfect and needs to be thoughtout. I'll think about it, and get back to you. > On 12/04/2010 7:52 AM, Domagoj Saric wrote: > IMNHO that's a failed test by any standard (worse than OpenSSL and Crypto++)... > (must I really pay for e.g. virtual inheritance, dynamic_casts, > by-std::string-runtime-algorithm-lookups etc. etc... for such a simple use > case?)... > 1) If you write such simple applications, you are very lucky > 2) I think one "issue" on Botan for Windows is the entropy gatherer. > It's slow and takes a lot of memory if.. memory serves. For applications > where entropy is not THAT important, I replace it. For applications > where it IS important, I would take out life insurance. That's because you built Botan in whole; it has the ability to build only parts of itself. If we don't like the inheritance structure, I can certainly remove it when porting. For example, despite public keys being very similar in structure, they should NOT inherit from a common base simply because they are entirely different objects. Also, I certainly agree that the runtime lookup of algos is REALLY BAD and doesn't take advantage of the IH, as noted above. I agree it needs to be replaced. As for the RNG's they are easily swapped, so maybe a less expensive one should be created in the process? >> From this I gather that the original author plans to continue to develop and > maintain the original library, in which case I wonder what would be the purpose > of having a library that is nothing more but a 'parallel' 'boostified' version > of the original that in itself offers nothing new and is updated only after the > original one is updated? > I also think it is useless if Jack does not intend to treat the Boost > version as *the* version. > However, in the transition period, I think it is only sensible that the > student manually merges changes. Will take some planning... I agree that this version should become *the* version, but I was completely absent-minded and didn't bring that up when discussing this with him. I'll ask him ASAP. Hopefully this alleviates some issues, Chad Seibert _________________________________________________________________ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…

3 2

FW: deadline_timer and a crash at ~io_service -> timer_base::destroy()
by Vance Grkov 14 Apr '10

14 Apr '10

Hi, I am getting a crash at the scope end (before the "catch") below in the code. This is the stack trace and the source. Does anyone know what is the problem with this code? Appreciate your help! 000801c7() > BoostThreadPoolTest.exe!boost::asio::detail::timer_queue<boost::asio::time_traits<boost::posix_time::ptime> >::timer_base::destroy() Line 211 + 0xe bytes C++ BoostThreadPoolTest.exe!boost::asio::detail::timer_queue<boost::asio::time_traits<boost::posix_time::ptime> >::destroy_timer_list(boost::asio::detail::timer_queue<boost::asio::time_traits<boost::posix_time::ptime> >::timer_base * & t=0x00338da0) Line 415 C++ BoostThreadPoolTest.exe!boost::asio::detail::timer_queue<boost::asio::time_traits<boost::posix_time::ptime> >::destroy_timers() Line 189 C++ BoostThreadPoolTest.exe!boost::asio::detail::win_iocp_io_service::shutdown_service() Line 148 + 0x2c bytes C++ BoostThreadPoolTest.exe!boost::asio::detail::service_registry::~service_registry() Line 75 + 0xf bytes C++ BoostThreadPoolTest.exe!boost::asio::detail::service_registry::`scalar deleting destructor'() + 0x2b bytes C++ BoostThreadPoolTest.exe!boost::asio::io_service::~io_service() Line 52 + 0x2e bytes C++ BoostThreadPoolTest.exe!wmain(int argc=1, wchar_t * * argv=0x003371d8) Line 152 + 0x27 bytes C++ BoostThreadPoolTest.exe!__tmainCRTStartup() Line 583 + 0x19 bytes C BoostThreadPoolTest.exe!wmainCRTStartup() Line 403 C kernel32.dll!_BaseProcessStart@4() + 0x23 bytes #include "stdafx.h" #include <iostream> #include <boost/thread.hpp> #include <boost/bind.hpp> #include <boost/shared_ptr.hpp> #include <boost/asio.hpp> #define THREAD_POOL_SIZE 10 void TimerCallback(boost::system::error_code ec, std::size_t i, std::size_t retry) { std::stringstream tmp; tmp << "Timer(" << ec.value() << ":" << ec.message() << "-" << retry << "-" << i << ")\n"; } // // MAIN // int _tmain(int argc, _TCHAR* argv[]) { try { boost::asio::io_service io(THREAD_POOL_SIZE); boost::asio::io_service::work *moreWorkToCome = new boost::asio::io_service::work(io); // Create a pool of worker threads. std::vector<boost::shared_ptr<boost::thread> > threads; for (std::size_t i = 0; i < THREAD_POOL_SIZE; ++i) { boost::shared_ptr<boost::thread> thread(new boost::thread( boost::bind(&boost::asio::io_service::run, &io) )); threads.push_back(thread); } // Lets enqueue more tasks to run after a given time std::vector<boost::asio::deadline_timer *> timers; for (std::size_t i = 1; i<50; i++) { boost::asio::deadline_timer *timer = new boost::asio::deadline_timer(io); timer->expires_from_now(boost::posix_time::seconds(3)); timer->async_wait(boost::bind(&TimerCallback, boost::asio::placeholders::error, i, 0)); timers.push_back(timer); } std::cout << "\nALL TASKS QUEUED\n"; // Now that all tasks have been queued we don't want to hold on any of the worker threads delete moreWorkToCome; std::cout << "\nRELEASE THE THREAD POOL\n"; // Wait for all tasks to be processes which also means all threads in the pool will exit. for (std::size_t i = 0; i < threads.size(); ++i) threads[i]->join(); // Cancel all timers (just in case) for (std::size_t i = 0; i < timers.size(); ++i) timers[i]->cancel(); io.stop(); std::cout << "\nPOOL DOWN\n"; } <-------------------------------------------- CRASH catch(...) { std::cout << "ERROR"; } std::cout << "\nEXIT\n"; return 0; } Hotmail: Trusted email with powerful SPAM protection. Sign up now. _________________________________________________________________ Hotmail: Free, trusted and rich email service. https://signup.live.com/signup.aspx?id=60969

2 1

[range] iterator_range::operator[] broken
by Eric Niebler 14 Apr '10

14 Apr '10

Neil, I know you patched this a mere 5 hours ago, but it's still broken. The attached patch *really* fixes the problem, I think. -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 4

[GSoC] Boost.Matrix RFC
by Kornel Kisielewicz 14 Apr '10

14 Apr '10

Hello all, Last year I submitted a proposal for Boost.Matrix as a GSoC project, that provoked quite a bit discussion. Considering the fact that it wasn't unanimously rejected, and that a few things have changed since then (Boost.Geometry acceptance) as did my skills, I'd like to take the liberty of resubmitting my proposal to the list, with a request for comments. The proposal follows: == Boost.Matrix == uBLAS is Boost's general linear algebra library, and it is a fine library indeed. However, in some cases it's design decisions, while quite rational for the general use case, are restrictive. This proposal is about a new library that would address some of these issues in the specific situation of vector and matrix operations on fixed sized structures. Suggested is a new library boost::matrix. The library would introduce a single container class that allows representation of fixed size vectors and matrices, and their respective standard operations. The library would define the following template template<typename T, std::size_t Rows, std::size_t Cols, class Traits> matrix and standard operations on it. The class would make heavy use of template specialization to allow efficient vector operations (matrices with size 1xN ), and provide efficient operations for the common sizes (2-4). The class will provide the interface of STL containers with the exact concept depending on the Traits used. Care will be taken to allow transparent usage within STL and other boost libraries. In general, this library would be similary scoped as Boost.Quaternion. Recently a new library has been accepted into boost -- Geometry. As the library is deeply about matrices and vectors, and has much in common with this proposal, I'd like to take a deep focus on providing maximum interopeability between Geometry and Matrix. == Rationale == Boost.Matrix aims to be for uBLAS, what Boost.Array is for vectors - a fixed size version to remove the overhead. The need is however greater, because while uBLAS provides a template for a fixed-sized version of it's arrays, the template is just a cover for the original uBLAS matrices. While the performance is comparable, the size includes a unnecessary field size. In cases that make heavy use of fixed sized matrices and vectors ( like real-time computer graphics ), such a tradeoff is unacceptable - due to increased memory consumption as well as effective vectorized math operations, and alignment of structures passed ( a single 4D vector should effectively fit a 128 bit register, and a single 128 bit move operation ). Also, knowing the dimensions of a matrix/vector at compile time, allows for a more efficient operation implementation, both from the programmers side ( better algorithms ), as well as from the compilers side (optimization). Finally, the uBLAS introduces a lot of unneccessary bloat for users wanting only a 2,3,4 vector and 3,4 matrix classes. == Primary deliverables == Boost.Matrix library, with the following features: * a boost::matrix base container class for 2-dimensional matrices, with the proper behavious and semantics of a container, written following the boost coding guidelines, and with full portability in mind * specializations for efficient vector (1xN matrix) handling * operators for readable but efficient vector/matrix math * operator specializations for matrices and vectors of the most common size (2-4) for most efficient implementation * efficient implementation of interoperability of Boost.Matrix with other boost libraries (uBLAS, Quaternion and upcoming Boost.Geometry in particular) == Secondary deliverables == * performance test suite, for testing optimizations * unit tests for the whole library providing full operation coverage and code-coverage * documentation for the whole library in the BoostBook format, as well as doxygen markup for all the code == Bonus deliverables == ( if time allows these will be delivered during program timeline, if not, they will be implemented afterwards ) * performance tests on different compilers/architectures, further optimizations * support for further boost libraries ( Boost.Assign, sandbox libraries, etc. ) == Design issues == * compile-time concept checking to only generare functions that make sense for the given type ( no floating point operations for integral types ) * usage of template expressions to unroll the operations at compile-time to allow the compiler to optimize them ( needs to be tested case by case with the performance test suite ) and elimination temporaries * care to keep most useful memory alignment ( to provide ease of use with direct usage in architecture dependent pipelines ) -- possibly an alignment trait * design with architecture-dependent optimizations in mind ( ease of expansion ) * keeping all the standard boost practices, including workarounds for non-conformant compilers == Research == Several existing implementations were studied and evaluated before the repeated submission of this idea. I intend to encompass most of the good things I found in the following implementations into a small but very useful library: * Boost.uBLAS (obviously) * Eigen - http://eigen.tuxfamily.org/ (heavyweight) * CGAL - http://www.cgal.org/ (license issues) * Matrix Template Library - http://osl.iu.edu/research/mtl/ (similar issues to uBLAS) * VCGLib - http://vcg.sourceforge.net/ (GPL) * nVidia's vector and matrix classes (found in nVidia examples) -- regards, Kornel Kisielewicz http://chaosforge.org/

9 16

Re: [boost] [iterator] reverse_iterator<counting_iterator<T>>
by Arno Schödl 13 Apr '10

13 Apr '10

"Stewart, Robert" <Robert.Stewart(a)sig.com <mailto:Robert.Stewart@sig.com> > wrote in message news:DF2E67F3D097004694C8428C70A3FD690470B26B7F@msgbal516.ds.susq.com <news:DF2E67F3D097004694C8428C70A3FD690470B26B7F@msgbal516.ds.susq.com> ... > this->base() calls iterator_adaptor<>::base(), which returns a reference to the underlying iterator it holds. Passing that reference to boost::prior() means that prior() pre-decrements the iterator within the iterator_adaptor. It would be odd for that >decrement operator to return anything but a reference to the decremented object, so boost::prior() returns a reference to its decremented argument, a reference to the decremented iterator within the iterator_adaptor. > I see no problem. boost::prior(...) internally makes a copy of its iterator argument, decrements it and returns it by value, so far so good. counting_iterator::operator* then returns a reference into this (temporary) iterator. Returning from reverse_iterator::dereference() destroys the temporary iterator, but still returns the reference pointing into it. I overlooked that I already filed a defect a while ago for it: https://svn.boost.org/trac/boost/ticket/2640 <https://svn.boost.org/trac/boost/ticket/2640> It would be great to have it fixed, because the bug is quite subtle and may go undetected for a while. Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Chausseestr. 8/E · 10115 Berlin, Germany http://www.think-cell.com · phone +49 30 666473-10 · toll-free (US) +1 800 891 8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Berlin-Charlottenburg, HRB 85229

3 4

[serialization] serialization lib not thread safe?
by Jean-Marie Auffray 13 Apr '10

13 Apr '10

I use boost serialization in multi threaded application. Sometimes application crashed. I manage to avoid bug if I recompile boost serialization with BOOST_SPIRIT_THREADSAFE defined in jam file : http://archive.netbsd.se/?ml=boost-build&a=2008-07&t=8023861 But I would like keep boost default installation. I read multi thread limitations here : http://www.boost.org/doc/libs/1_42_0/libs/serialization/doc/special.html But I don't find how to use singleton to avoid crash, I attach test files to reproduct crash. I use 1.36 in test files, but same bug seems to occure in next release. How can I add singleton from serialization to avoid crash? I try some solutions but failed to find a good implementation. Thanks for help.

2 1

release managers: permission to merge?
by Frank Mori Hess 13 Apr '10

13 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to the calendar, the release branch went into "closed except by permission" yesterday. Is it all right for me to merge to release the fix for this ticket: https://svn.boost.org/trac/boost/ticket/4089 The changeset in question is https://svn.boost.org/trac/boost/changeset/61243 I've tested it locally, but have just comitted it to trunk so the tests there haven't cycled yet. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkvEbewACgkQ5vihyNWuA4XawACg1jS8IZun6NJ52GkCa2V3i4nc PAIAoJlaXBs4NqY5mfGiHMoVAYJsTSVp =NiyZ -----END PGP SIGNATURE-----

2 1

Guidelines on wiki
by Daniel James 13 Apr '10

13 Apr '10

Hello, I've copied the guidelines onto the wiki now, you can see them at: https://svn.boost.org/trac/boost/wiki/Guidelines/ Any comments? I've changed the beta site to redirect to them. I haven't linked to them from the front page of the wiki as they aren't 'official' yet. I'll be moving more pages over soon-ish. Any ideas about how the wiki should be structured? Daniel

5 10

[iterator] reverse_iterator<counting_iterator<T>>
by Arno Schödl 13 Apr '10

13 Apr '10

Hello, boost::reverse_iterator::dereference() is typename super_t::reference dereference() const { return *boost::prior(this->base()); } boost::constant_iterator<T>::reference_type is T const&. So reverse_iterator< constant_iterator<T> >::dereference returns a reference to a temporary variable. Not good. I suggest removing the reference from boost::constant_iterator::reference_type, making it T. The rule would be that reference_type must only be a reference if the reference is pointing to some underlying container, not to the iterator itself. Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Chausseestr. 8/E · 10115 Berlin, Germany http://www.think-cell.com · phone +49 30 666473-10 · toll-free (US) +1 800 891 8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Berlin-Charlottenburg, HRB 85229

2 1

[iterator] Re: counting_iterator<int>::difference_type
by Arno Schödl 13 Apr '10

13 Apr '10

> > counting_iterator<int>::difference_type is __int64 by default. I understand the underlying rationale, but I am not sure whether it is the right choice given the existing practice of C/C++. The problem of int minus int overflowing is not restricted to counting_iterator. Still, C/C++ chose to make int minus int -> int, probably for performance reasons. So why shouldn't counting_iterator by default behave the same way? If someone needs something else, she can still override the default. > You are able to override the difference_type by providing your own type. > See: > boost::counting_iterator<int,boost::use_default,int>::difference_type I know and I did it already. I just want to question whether the default is sensible, given the rest of the language. Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Chausseestr. 8/E · 10115 Berlin, Germany http://www.think-cell.com · phone +49 30 666473-10 · toll-free (US) +1 800 891 8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Berlin-Charlottenburg, HRB 85229

1 0

counting_iterator<int>::difference_type
by Arno Schödl 13 Apr '10

13 Apr '10

Hello, I am sure this has come up a few times, but I could not find the answer in the archive. counting_iterator<int>::difference_type is __int64 by default. I understand the underlying rationale, but I am not sure whether it is the right choice given the existing practice of C/C++. The problem of int minus int overflowing is not restricted to counting_iterator. Still, C/C++ chose to make int minus int -> int, probably for performance reasons. So why shouldn't counting_iterator by default behave the same way? If someone needs something else, she can still override the default. Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Chausseestr. 8/E · 10115 Berlin, Germany http://www.think-cell.com · phone +49 30 666473-10 · toll-free (US) +1 800 891 8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Berlin-Charlottenburg, HRB 85229

2 1

[svn] request for commit permission
by Daniel Walker 13 Apr '10

13 Apr '10

Hello, I recently became the maintainer for Boost result_of. May I have commit permission on svn? Also, if I need to make an account, where do I register? Thanks! Daniel Walker

3 2

[iostreams] Cannot compile against zlib 1.2.4
by Lars Viklund 13 Apr '10

13 Apr '10

Hi list. zlib 1.2.4 was released in mid-March, reorganzing the sources a bit. They removed gzio.c and added in a bunch of new source files, something the Jamfile for iostreams does not particularly appreciate. I submitted a ticket [1] with a somewhat tested solution (remove gzio from the list of sources), but I have no idea whether it's the right way to solve it as I'm not aware of how the guts of zlib_compressor and friends work. How does one go forward with something like this, as I don't think I've seen much activity from the iostreams camp at all lately? It would be awfully nice to get some kind of fix into 1.43.0, as it currently prevents anyone interested in building zlib automagically via bjam from doing so. One thing I guess might get in the way is whether this should support older versions of zlib sources. In my opinon no, as this only applies to people who want to build from their own freshly unpacked zlib source tree, not affecting people who use prebuilt binaries from their distro or downloads. [1] https://svn.boost.org/trac/boost/ticket/4091 -- Lars Viklund | zao(a)acc.umu.se

2 1

VS2005 SP1 Hard Debugger Crash in Class Destructor with Boost.Filesystem
by Jack Yee 13 Apr '10

13 Apr '10

Hello, I have a very strange crash involving the use of auto-linking of the boost::filesystem (1.38/1.42) and putting breakpoints in a unmanaged class destructor. It crashes hard enough that the task must be stopped through the Task Manager. Below is the test case that causes the crash: #include "stdafx.h" #include <vcclr.h> #include "boost/filesystem.hpp" // Note 1 public ref class ClassOne { public: ClassOne() {} ~ClassOne() {} }; class ClassTwo { public: ClassTwo(ClassOne^ p) {one = p;} ~ClassTwo() {one = nullptr;} // Note 2 gcroot<ClassOne^> one; }; int _tmain(int argc, _TCHAR* argv[]) { ClassOne ^one = gcnew ClassOne(); ClassTwo *two = new ClassTwo(one); delete two; // Note 3 return 0; } Note 1 -- Commenting out this header and setting breakpoint at Note 2 will be OK Note 2 -- Putting a breakpoint here with "boost/filesystem.hpp" will cause VS2005 to crash Note 3 -- Putting a breakpoint here with "boost/filesystem.hpp" will be OK BUILD CONFIGURATION: * Common Language Runtime Support (/clr) enable * Preprocessor defines: WIN32;_DEBUG;_CONSOLE; * Standard include and library search paths to your Boost installation. Other Useful information: * Running the program without breakpoints doesn't indicate any errors or non-zero exit codes. * Tried both 1.38 and 1.42 boost libraries * Debugger crash does not happen under VS2008 * Same crash results on Windows XP Professional, Vista Business and Windows 7 machines. Event Viewer Output: Faulting application devenv.exe 8.050727.867, time stamp 0x45d2c842, faulting module OLEAUT32.dll, version 6.0.6001.18000, time stamp 0x4791a74f, exception code 0xc0000005, fault offset 0x00003e56, process id 0x8ec, application start time 0x01cadab2a1430262. Hopefully the example is concise enough that I can get some other willing people to try it out and see if they get the same results. Apologies in advance if there is a typo in the source code as the work machines are isolated from connecting from the Internet. Thanks! Jack

1 0

GSOC 2010 - BGL Graph Connectives.
by Tri Nguyen 12 Apr '10

12 Apr '10

Hi, I am Tri Nguyen from South Plains College. I am interested in Graph Connectives Project of BGL. In this writing, I would like to ask two questions, and then propose my idea of doing four Connectives: union, join, intersection, and difference. My first question is: How big is the graph? Or students will try to do as big as possible. My second question is: What type of data-structures (matrix or list) will be used? I attached my ideas in the PDF file below. Please have a look. I appreciate all responses, Thank you, Tri Nguyen.

4 15

GSoC2010 Sweepline Algorithm
by Andriy Sydorchuk 12 Apr '10

12 Apr '10

Hi, Boost Community! I am interested in participation in GSoC 2010. The project I liked the most is the generic implementation of Sweepline Algorithm. Basically fast and robust Sweepline Algorithm requires implementation of next data structure: 1) Event Queue (priority queue). 2) Sweep Line (self-balancing binary search tree). 3) Output datastructures (voronoi vertices, triangulation edges, etc.). Based on that I got next questions: - Which kind of self-balancing binary trees is better for that kind of approach? I am thinking about Red-Black Trees in prefer to AVL trees, as sweepline algorithm requires more adding and deletion operations. And AVL trees are better for look up operations. - STL library includes two generic implementations of self-balancing binary trees (red-black): map, set. I am quite new with Boost library, but probably there are some more specific self-balancing binary tree implementations there? - For Voronoi diagram and delaunay triangulation input data is set of points. What about input of the Medial Axis problem? -- Best, Andrii Sydorchuk

4 33

[BGL] Revisiting Parallel BGL
by Sandeep Gupta 12 Apr '10

12 Apr '10

Hi, I raised the issue of parallel BFS not working correctly here http://lists.boost.org/boost-build/2009/10/22631.php. The issue remained unresolved. I revisited it for last two days and the incorrectness in likelihood is probably due to initialization of distance property map for all non-start vertex to be infinity. Hope this helps. Thanks Sandeep

3 17

How to use mutable_queue with non basic types
by Emili Hernàndez 12 Apr '10

12 Apr '10

Hi all, I've used mutable_queue with basic types (double and int) with no problem. Now I trying to do it with my own type: typedef MyObject entry_t; typedef vector<entry_t> storage_t; typedef MySortingCriterion comp_t; typedef boost::identity_property_map prop_map_t; typedef boost::mutable_queue<entry_t, storage_t, comp_t, prop_map_t> queue_t; queue_t Q(100, comp_t(), prop_map_t()); The definition compiles ok but when I perform an operation such Q.push(obj) //MyObject obj The following errors appear: C:\boost\boost_1_42_0/boost/property_map/property_map.hpp: In function 'Reference boost::get(const boost::put_get_helper<Reference, PropertyMap>&, const K&) [with PropertyMap = boost::typed_identity_property_map<unsigned int>, Reference = unsigned int, K = boost::shared_ptr<CAStarNode>]': C:\boost\boost_1_42_0/boost/pending/mutable_queue.hpp:94: instantiated from 'void boost::mutable_queue<IndexedType, RandomAccessContainer, Comp, ID>::push(const IndexedType&) [with IndexedType = boost::shared_ptr<CAStarNode>, RandomAccessContainer = std::vector<boost::shared_ptr<CAStarNode>, std::allocator<boost::shared_ptr<CAStarNode> > >, Comp = astarnode::SGreater, ID = boost::typed_identity_property_map<unsigned int>]' ..\CAStar.cpp:62: instantiated from here C:\boost\boost_1_42_0/boost/property_map/property_map.hpp:318: error: no match for 'operator[]' in '(const boost::typed_identity_property_map<unsigned int>&)((const boost::typed_identity_property_map<unsigned int>*)(& pa))[k]' C:\boost\boost_1_42_0/boost/property_map/property_map.hpp:553: note: candidates are: T boost::typed_identity_property_map<T>::operator[](const T&) const [with T = unsigned int] It seems the problem is with property_map. Anyone knows how to solve it?? Thank you very much, Cheers, Emili

2 4

[GSOC] summary of .BigInt library details.
by Ankit Malpani 12 Apr '10

12 Apr '10

hi all, thank you Scott McMurray, Vicente and Bruno for the prompt feedback regarding my proposed BigInt library ideas .(Sorry for the delayed reply as was busy with mid-semester exams.) In general this is what i have gathered from your responses regarding what exactly is being expected by the community from a BigInt library for Boost. 1. frontend based off Boost.Proto 2. backend implemented with the help of Boost libraries like Boost.Math. 3. probably provide two levels of implementations. ( although it would really help if you could weigh the pros and cons of both and eliminate one the the two) 3a. looking at bit-level implementation(less space and probably more execution time) 3b.) digit level manipulation (more space - and probably less execution time). i.e. for an n-digit number is it ok to use up [n/2 to n] bytes of space or necessary to stick to log n amount of space for a BigInt object. my questions are :- 1. Please give your feedback/concerns regarding the above design. 2. Any other libraries like Boost.Math which would help with the backend. -- Ankit Malpani 3rd Year Undergraduate | BE. (Hons) Computer Science BITS Pilani Goa Campus

5 5

[Bind] Function arithmetic (sample impl inside)
by ivan.lelann＠free.fr 12 Apr '10

12 Apr '10

Hi, It's my first message here, so please excuse possible mistakes. I found that Boost.Bind offers logical operators but no arithmetical operators. Looking into boost/bind/bind.hpp, and using "logical_not" impl, I wrote the following naive patch against version 1.40. It is certainly not as robust as Boost exspects, it is quickly tested, but it seems to do the job, as you can see in the test. Please use attached documents as you see fit. Regards, Ivan. PS: attached main.cpp is compiled with g++ 4.4.1, -std=c++0x, "my" bind.hpp in same directory, and boost 1.40 in include path.

2 1

Re: [boost] Crypto Proposal
by Chad Seibert 12 Apr '10

12 Apr '10

> Hi, > > Perhaps this link will work: > > http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/chads… > Yep, it worked, thanks. > Thanks to all who gave advice, please ask if you have any questions! > It all sounds very good. Can you give an example of what porting some > Botan functionality would look like? Would it be as simple as replacing > the namespace Botan with boost::crypto/whatever in the source code? > An example of what one of the Botan tutorial examples would look like in > the new world would be nice. > Honestly, I think there is no point if you can't commit to part 2. > However, splitting it up into GSoC/non-GSoC is smart on your part. How > do you plan to commit to part 2? > Thanks and good luck :) Here's an example of boostified code, from one of the examples on the site. It's not too different from the original code (it's just commented out); this is because I don't want it to be a chore to port from Botan to Boost.Botan. Also, it is intuitively designed and I see no reason to change it. Of course, if it needs redesigning, we can discuss that afterwards. Also, there are at least 600 files to move that total 2 mb's of source, so it'll take a while, even if it is just changing namespaces and the like. But I'll get started on part 2 if part 1 finishes early. As for committing to part 2, I have some (rough) guidelines for the work to be done afterwards. I'm also taking a lighter courseload so I can spend more time working. I don't know how else to convince you. Anyways, thank you for considering my proposal! Chad Seibert #include <boost/botan.h> #include <iostream> #include <memory> int main(int argc, char* argv[]) { if(argc != 5) { std::cout << "Usage: " << argv[0] << " <passphrase> " << "<ca cert> <ca key> <pkcs10>" << std::endl; return 1; } try { const std::string arg_passphrase = argv[1]; const std::string arg_ca_cert = argv[2]; const std::string arg_ca_key = argv[3]; const std::string arg_req_file = argv[4]; //AutoSeeded_RNG rng; boost::botan::rng::auto_seeded rng; //X509_Certificate ca_cert(arg_ca_cert); boost::botan::x509::certificate ca_cert(arg_ca_cert); //std::auto_ptr<PKCS8_PrivateKey> privkey(PKCS8::load_key(arg_ca_key, rng, arg_passphrase)); std::auto_ptr<boost::botan::pkcs8::private_key> privkey(pkcs8::load_key(arg_ca_key, rng, arg_passphrase)); //X509_CA ca(ca_cert, *privkey); boost::botan::x509::ca ca(ca_cert, *privkey); // got a request //PKCS10_Request req(arg_req_file); boost::botan::pkcs10::request req(arg_req_file); // you would insert checks here, and perhaps modify the request // (this example should be extended to show how) // now sign the request //X509_Time start_time(system_time()); //X509_Time end_time(system_time() + 365 * 60 * 60 * 24); //X509_Certificate new_cert = ca.sign_request(req, rng,start_time, end_time); boost::botan::x509::time start_time(system_time()); boost::botan::x509::time end_time(system_time() + 365*60*60*24); boost::botan::x509::certificate new_cert = ca.sign_request(req, rng, start_time, end_time); // send the new cert back to the requestor //std::cout << new_cert.PEM_encode(); std::cout << new_cert.pem_encode(); } catch(std::exception& e) { std::cout << e.what() << std::endl; return 1; } return 0; } _________________________________________________________________ The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28…

4 3

[preprocessor] BOOST_PP_IS_UNARY()
by Lorenzo Caminiti 11 Apr '10

11 Apr '10

Hello all, Do you know what are the drawbacks of using BOOST_PP_IS_UNARY()? If you have used it, what is your experience with its portability? BOOST_PP_IS_UNARY() is *not* part of the Boost.Preprocessor public API as it is #defined in boost/preprocessor/detail/is_unary.hpp. However, Boost.Preprocessor, Boost.Typeof, and Boost.Spirit seem to use BOOST_PP_IS_UNARY() at least internally: $ find /usr/include/boost/ -name "*.[hc]pp" -exec grep -Hn "BOOST_PP_IS_UNARY" {} \; /usr/include/boost/preprocessor/facilities/apply.hpp:24:# define BOOST_PP_APPLY_I(x) BOOST_PP_EXPR_IIF(BOOST_PP_IS_UNARY(x), BOOST_PP_TUPLE_REM_1 x) /usr/include/boost/typeof/template_encoding.hpp:61: BOOST_PP_IS_UNARY(x),\ /usr/include/boost/spirit/utility/rule_parser.hpp:826: BOOST_PP_EXPR_IIF(BOOST_PP_COMPL(BOOST_PP_IS_UNARY(elem)),elem) In addition, Paul Mensonides mentioned the following in http://lists.boost.org/Archives/boost/2004/08/70238.php > Paul Mensonides wrote: > I know. They (and other types of detection macros) are very useful. Right now, > the Borland configuration is used by the IBM preprocessor and the Sun > preprocessor also. I'd like to know whether or not those macro definitions work > correctly on those preprocessors before I add it. Though those macros aren't > part of the public interface, they are part of the internal interface. I.e. > they are used internally as if they were a public interface (though they are > used carefully on some preprocessors). They are stable, and the worst thing > that might happen in the future is that they will be moved to a different > directory. Thus, you can use them, but beware of VC and versions of MWCW prior > to v9. They in particular have severe problems with expansion order. E.g. VC > will even fail this test: My Boost.Contract code internally uses BOOST_PP_IS_UNARY() and it works fine on GCC 4.2.4 (Ubuntu Linux), MSVC 8.0 (Windows XP), and GCC 3.4.4 (Cygwin) but I have not tried other compilers (including Borland's). Thank you. Lorenzo

1 1

[Locale] Static locale initialisation
by Alexander Lamaison 11 Apr '10

11 Apr '10

I'm encountering a crash with Boost.Locale as the process terminates I initialise the global Boost.Locale in the contructor of a class with a single static instance (the ATL module to be exact) as I don't have access to the code of my main method (it comes from the Boost.Test runner). A static object seems to be the only logical place to put this code: #include <boost/locale.hpp> // boost::locale::generator class CModule : public ATL::CAtlModule { public : CModule() : ATL::CAtlModule() { try { // Initialise Boost.Locale translation mechanism generator gen; gen.add_messages_path("C:/My/Path"); gen.add_messages_domain("swish"); std::locale::global(gen("")); // default locale } catch (std::exception) {} } HRESULT AddCommonRGSReplacements(IRegistrarBase*) { return S_OK; } }; CModule _AtlModule; // Global module instance However, when I run my EXE, it crashes as it terminates with: Unhandled exception at 0x5ba43d93 (msvcp80d.dll) in test-shell_folder.exe: 0xC0000005: Access violation reading location 0x0321f4e4. and the following stack trace: msvcp80d.dll!std::_DebugHeapDelete<std::locale::facet>(std::locale::facet * _Ptr=0x023af590) msvcp80d.dll!_Deletegloballocale(void * ptr=0x5bb25258) msvcp80d.dll!tidy_global() msvcp80d.dll!_Init_atexit::~_Init_atexit() msvcp80d.dll!`dynamic atexit destructor for 'init_atexit''() msvcp80d.dll!_CRT_INIT(void * hDllHandle=0x5ba30000, unsigned long dwReason=0x00000000, void * lpreserved=0x00000001) msvcp80d.dll!__DllMainCRTStartup(void * hDllHandle=0x5ba30000, unsigned long dwReason=0x00000000, void * lpreserved=0x00000001) msvcp80d.dll!_DllMainCRTStartup(void * hDllHandle=0x5ba30000, unsigned long dwReason=0x00000000, void * lpreserved=0x00000001) ntdll.dll!_LdrpCallInitRoutine@16() ntdll.dll!_LdrShutdownProcess@0() ntdll.dll!_RtlExitUserProcess@4() kernel32.dll!76843b69() msvcr80d.dll!__crtExitProcess(int status=0x00000000) msvcr80d.dll!doexit(int code=0x00000000, int quick=0x00000000, int retcaller=0x00000000) msvcr80d.dll!exit(int code=0x00000000) test-shell_folder.exe!__tmainCRTStartup() test-shell_folder.exe!mainCRTStartup() If I move the initialisation code to run just before each point I need to use translate() then it works fine. So maybe this has something to do with the way static data is destroyed. This is on Windows - not sure about other platforms. Any ideas? Many thanks. Alex Lamaison P.S. I realise Boost.Locale isn't in Boost yet but previous discussions have been here so it seems a reasonable place to ask.

2 19

Re: [boost] [GSoC]Bits and Ints
by shiyang yang 10 Apr '10

10 Apr '10

Hi Thanks for the help. But I am still not very sure about the meaning of dynamic_bitfields. Does it mean the size of the bitfield is dynamic? Shiyang

3 2

[GSoC]Bits and Ints
by shiyang yang 10 Apr '10

10 Apr '10

Hi I have been working on the proposal of this project, but still have some questions, could anyone please give me some help? For the bits part, what does the 'compressed' mean, what is the main difference between the array, vector and the normal ones? Is there any other existing integral special functions that mentioned in the second part? Where can I find them? Thanks a lot Shiyang Yang

3 2

Re: [boost] Boost.Botan final proposal
by Chad Seibert 10 Apr '10

10 Apr '10

Hi, Perhaps this link will work: http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/chads… Thanks to all who gave advice, please ask if you have any questions! Chad Seibert _________________________________________________________________ The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multicalendar&ocid=PID2…

3 2

Message Hashing Interface (SHA-1/256/384/512, MD4/5)
by Scott McMurray 10 Apr '10

10 Apr '10

I wrote up some SHA message hashers recently, which came out rather nicely using templates to handle the commonalities between SHA-1/256/384/512. The one issue that came up is how to handle retrieving the hash from the accumulator. When working with just the raw SHA compressor it's not a problem, but when hashing messages, getting the hash of the message requires appending padding and a length. That means that SHA and MD[45] hashing cannot use the same simple interface of Boost.CRC that, in essence, consists of calling process_byte() and inspecting the cheap, const member function hash() as needed. Here are a couple of options: 1) The hash() function is non-const, and it appends the passing and length, calculates the hash, and resets the accumulator to be ready for the next message. This is perhaps the most efficient interface. 2) The hash() function is const, and copies the accumulator, then pads and length-appends the copied version, getting the hash from there instead. That gives perhaps the nicest interface, but the extra copying would be somewhat expensive. That said, it's overhead per message, not dependant on the length of the message, so it may be acceptable. Also, the hash function would still be quite expensive, contrary to usual expectations for const member functions. 3) The hash() function is just a cheap const that returns the current state of the compressor. This would require an additional end_of_message() function that would apply the padding and probably things up such that the next process_byte function would start a new message by resetting the compressor. That would allow the hash() function to be cheaply called as many times as desired between calling end_of_message() and providing the data for the next message. One big problem with this one is that hash() can be called after providing data but before calling end_of_message(), at which point is return value is essentially useless. I think I like (1) best, because it allows the user to copy it and get (2) if they'd rather, and doesn't have the potential call sequencing problem of (3). Any opinions, suggestions, alternatives, or comments? ~ Scott McMurray P.S. Yes, the point here is to create Boost.MD and Boost.SHA libraries. The first client would be Boost.UUID to allow it to offer the MD5 name-based UUIDs it currently cannot. It needs a hashing concept so that it can parametrise name_generator similarly to how it currently parametrises basic_random_generator [1]. [1] http://www.boost.org/doc/libs/1_42_0/libs/uuid/uuid.html#Random%20Generator

5 13

Log/tropical semiring for boost math
by Alex Graves 10 Apr '10

10 Apr '10

Hi, I work in machine learning, and often need to do probability computations in the log scale to avoid underflows. A nice way to do this is to use a class where the add, divide etc. operators are overloaded by their log scale equivalents (e.g. log(a*b) = log(a) + log(b)). In other words a class implementing the log semiring <http://en.wikipedia.org/wiki/Semiring>. Also useful in this context is the tropical semiring, where adding is replaced by taking the maximum (or minimum) of the arguments. I looked for these in the boost math library, but couldn't find anything. So I wrote my own. Did I miss something? And if not, is anyone interested in adding my implementation to boost math? Alex

2 1

Phoenix.bind VS Lambda.bind
by Alexey Tkachenko 10 Apr '10

10 Apr '10

Hi, Now I'm looking at Phoenix and Lambda libraries. Could somebody explain why Lambda allows to use the following expression: void foo(int) { ... } ... bind(foo, _1)(10); yet Phoenix does not. Phoenix requires to use helper variable: void foo(int) { ... } ... int i = 0; bind(foo, _1)(i); I've read document about "Forwarding Function Problem" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm) I understand the core issue, but how does Lambda.bind solve it? Thank you, Alexey.

4 4

[serialization][1_42_0] basic_binary_oarchive - warning: comparison is always true due to limited range of data type
by Jeff Flinn 09 Apr '10

09 Apr '10

basic_binary_oarchive.hpp has this member: void save_override(const class_id_type & t, int){ // upto 32K classes assert(t.t <= boost::integer_traits<boost::int_least16_t>::const_max); const boost::int_least16_t x = static_cast<const boost::int_least16_t>(t.t); * this->This() << x; } It doesn't seem that there is a need for this runtime assert at all given the definition: BOOST_ARCHIVE_STRONG_TYPEDEF(int_least16_t, class_id_type) Can't the assert be removed to quiet the gcc warning? Jeff

3 4

[utility/value_init] boost::value_initialized<T> direct-initialized?
by Niels Dekker - address until 2010-10-10 09 Apr '10

09 Apr '10

Can anybody please have a look at the following feature request by Edward Diener? https://svn.boost.org/trac/boost/ticket/3472 He proposed to add an explicit constructor, value_initialized(T const&), to boost::value_initialized<T>. This constructor would copy the value of its argument to the object held by value_initialized<T>. When such a constructor would be added, an object held by value_initialized<T> might no longer be value-initialized. Instead it might be direct-initialized. Does anybody have any moral (?) objections against the idea that value_initialized<T> might hold a non-value-initialized object? Personally I think it would be useful to allow the wrapped object to be direct-initialized. But I do think there's a small risk that the new explicit constructor might cause ambiguities in legacy user code. Therefor I suggested adding an extra "tag" parameter to the new constructor, of a new type, boost::direct_initialized_t: struct direct_initialized_t { }; value_initialized(T const&, direct_initialized_t) Does anyone else also think that's a good idea? Or does anyone prefer the explicit value_initialized(T const&) constructor originally proposed by Edward? See also the thread starting at: "Re: [boost] Transfer of Maintenance Rights (utility/value_init)" http://lists.boost.org/Archives/boost/2010/03/164125.php Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

6 32

xml?
by Maarten L. Hekkelman 09 Apr '10

09 Apr '10

Hi, I saw there was some discussion on this list regarding an XML library. I wrote a C++ based XML library recently as part of the work I do on e.g. MRS, a full-text retrieval system for biological databanks. (See http://mrs.cmbi.ru.nl/ ) I extracted the XML and SOAP code from the MRS project and wrapped it into a new library. This library is called libzeep and I've put the code on Berlios (http://libzeep.berlios.de/) License is Boost. The library currently consists of: - a SAX parser with validation support based on DTD. - a simple XML library for nodes, elements, etc. - an XML writing utility/wrapper. - an xpath implementation And then the code contains a full high-performance SOAP server implementation. This code generated all SOAP related code and WSDL generator code based on the signature of exported server methods. No need to run a separate code generating tool. Network code is based on asio and I've implemented an optional pre-forked mode of operation. A previous version of libzeep is in production use for over a year now and I recently added the parser and xpath stuff to be able to drop libxml2 from the requirements for MRS. Code comes with quite a few test sets. Documentation is not updated yet for the parser and xpath but there is some for the SOAP part. I need to do a bit more testing before I can release a new version. My question now is, would this library be of interest to Boost? Perhaps it can be used, or parts of it can be recycled. And if there is interest, I'm sure there must be suggestions for improvement. You can browse the code at https://svn.cmbi.ru.nl/libzeep/trunk/ (There's also a copy at Berlios, but that may be out-of-date) The application zeep-test is a simple SOAP server, in ./tests/ you can find two simple test drivers, one for the parser and one for xpaths. Best regards, -maarten hekkelman

11 22

[GSoC] Students; Please note..
by Rene Rivera 09 Apr '10

09 Apr '10

GSoC students, Now that the GSoC submission deadline has passed it is vitally important that you pay attention to your proposals and the comments the mentors add to them. Please address questions and suggestions we put on the comments ASAP. As it will both make our lives easier, and hence more likely to make accurate assesments of proposals. And it will increase the chances that we consider your proposals serious enough to want to move forward, if we get our feedback resolved. Good luck to all :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[config] New defect macro: BOOST_NO_COMPLETE_VALUE_INITIALIZATION
by Niels Dekker - address until 2010-10-10 09 Apr '10

09 Apr '10

FYI, John Maddock has just added the tests to trunk/libs/config that I wrote for a new defect macro: BOOST_NO_COMPLETE_VALUE_INITIALIZATION https://svn.boost.org/trac/boost/changeset/61153 And some documentation: https://svn.boost.org/trac/boost/changeset/61154 A test failure indicates that the specific compiler doesn't have completely implemented value-initialization. In the coming few days, the test is likely to cause regression failures, because I still need to define the defect macro for those specific compilers (at boost/config/compiler). Although I already expect certain compilers to fail (MSVC <= 2010, CodeGear/Borland <= 2010, GCC < 4.4, and various versions of Sun) I chose not to define the defect macro /beforehand/, because the test output provides some extra information about the particular compiler issue. Moreover, once the defect macro is defined, the test framework no longer indicates whether the compiler defect is really there. I'll keep an eye on the regression page, http://www.boost.org/development/tests/trunk/developer/config_.html and fix them one by one, but please don't hesitate to remind me if there's a regression failure regarding the new defect macro that I overlooked. The defect macro will allow fixing ticket #3869, "Unconditional call to memset in value_initialized()", reported by Aleksey Gurtovoy: https://svn.boost.org/trac/boost/ticket/3869 by adding an #ifdef to utility/value_init.hpp: #ifdef BOOST_NO_COMPLETE_VALUE_INITIALIZATION std::memset(&x, 0, sizeof(x)); #endif Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

1 1

Re: [boost] [msm] new version available
by Christophe Henry 09 Apr '10

09 Apr '10

> The new package on Vault is missing boost/msm/back/default_compile_policy.hpp. > Everything seems to compile fine once I grabbed it from the sandbox, so I assume > the other files in the package are the proper versions. I found the problem. SVN refuses to correctly update the directory I used to build the zip. Even cleanup has no effect, so I will delete the whole stuff and checkout again. There are actually 2 important files missing, so I had no other choice than to upload the correct version again. For all who downloaded from the vault, sorry about it, you will need to download again (the sandbox is ok though). > Also, I very much dislike that metafunctions.hpp does 'namespace mpl = > boost::mpl;' in global scope. Isn't putting anything in global scope against the > boost guidelines? Even if not, I find it quite inappropriate to inject another > library's namespace into global scope. This line is not even needed as all mpl types are qualified inside the library with ::boost::mpl so I just removed the line. This problem is there since at least the 1.20 and went unnoticed. Sadly, some of the tutorials fail to fully qualify the mpl types, so I updated them too. Both versions, sandbox and vault should now be up to date and with these 2 problems solved. Thanks, Christophe

1 0

GSoC 2010: Heaps and Queues
by Dan Larkin 09 Apr '10

09 Apr '10

I'm another potential student throwing my hat in the ring for the heap project. I'll save most of my personal details for my proposal, but for right now I thought I'd try to get a bit of a dialogue going with the community to help me understand what it is you guys are looking for and what it is I can work towards. So I'll start with my current understanding of the situation. The way I see it, the current heap implementations in boost/pending are rather fractured. They just have simple push/pop interfaces with no mutability (well, there's mutable_heap.hpp, but that's separate and not fleshed out). All in all, what seems to be needed is a standardized heap concept/API along with a few fully-implemented models. Standard heap functionality begs the following functions: - findMin - deleteMin - insert - changeKey - merge These can all be implemented quite efficiently (either worst case or amortized O(logn) time or better) for any heap model. I would be looking to implement the d-ary, binomial, and Fibonacci heaps for sure, with relaxed and Brodal heaps as a possibility, should time allow it. These heap models would be built as extensions of a base Heap class, which could be easily wrapped in a PriorityQueue class which takes the heap-type as a construction parameter (and defaults to a d-ary heap for instance). I know that a stable priority queue was mentioned in earlier discussion, but I'm not sure what to do about that just yet. It'll take a little more thinking before I could say whether I think it'd fall under the scope of the summer project, or if it should be put on the back-burner for later addition to the library. I guess that's basically how I see the problem so far. Please let me know what you think, or what other sort of information/planning/etc. you would like to hear from me prior to my proposal/draft. Dan Larkin

7 34

Boost.Botan final proposal
by Chad Seibert 09 Apr '10

09 Apr '10

Hi, Pending any other revisions, here's my final proposal: http://socghop.appspot.com/gsoc/student_proposal/edit/google/gsoc2010/chads… Thanks to all who gave advice, please ask if you have any questions! Chad Seibert _________________________________________________________________ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…

2 2

[GSoC] Bits & Ints proposal
by Murilo Adriano Vasconcelos 09 Apr '10

09 Apr '10

Here is my proposal for Bits & Ints idea: http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/muril… Any comments? -- Murilo Adriano Vasconcelos

1 0

boost::interprocess
by Rohit Goel 09 Apr '10

09 Apr '10

Hi, How can I synchronize mutlipe read/single write on a file available on a shared folder ? The multiple read/write need to be synchronized b/w different processes running on different machine. -Rohit

2 1

[msm] new version available
by Christophe Henry 09 Apr '10

09 Apr '10

Hi all, I just finished the newest MSM version. Unfortunately, I'm afraid I'm a bit late to get it shipped with boost v1.43 but at least it will give us time to have a look at it. What is new: - the doc was rewritten almost from the ground up. - internal transitions: for all front-ends, and both ways: either in the transition table or inside state's internal transition tables - more row types (yes, even more) allowing actions to be defined in state machines or in states The last 2 points aim at making states more useful - some performance gain - new eUML syntax to get rid of parens and to better support attributes - policy for better compile-time at cost of dispatch speed. And a few minor improvements. It was not possible to implement every wish and excellent idea offered during the review at this point, but they are in no way forgotten and I do not intend to stop development now. I'm interested in any comments, especially about the doc, which, like everything new, probably is not perfect but I hope, still an improvement. You can find the new version, like always: - in the Vault (http://www.boostpro.com/vault/index.php?directory=Msm) - in the sandbox (http://svn.boost.org/svn/boost/sandbox/msm/) Regards, Christophe

5 4

GSoC Generic Sweep Algorithm
by Sweta Yamini 09 Apr '10

09 Apr '10

Hi, I am writing my proposal for GSoC and I'm interested in writing a generic sweep algorithm. I want to write a generic algorithm which takes in functions to determine the priority of the elements to be considered in the sweep line, and a function to perform necessary computations at each such point. And supplement it with inbuilt functions for line sweep, angular sweep about a point for 2 dimensions and plane sweep for 3 dimensions. Also, implement some algorithms like Voronoi diagrams, Delaunay triangulations, visibility problems using the generic sweep algorithm. I have looked through the documentation and could not find anything related to this. Is there something I have missed? Also, could I contact anyone to discuss? Sweta Yamini Fourth Year Student Department of Computer Science And Engineering Indian Institute of Technology, Kharagpur

3 5

[GSoC] Some new ideas for this year's GSoC
by Stefan 09 Apr '10

09 Apr '10

Hello, I am Stefan and this is my first year at GSoC as it's the first time I'm eligible to participate as a student. Since I have been using C++ and the Boost libraries for quite some time, I would be thrilled to be able to code for Boost. I have quite a few ideas, and I was wondering which ones you consider to benefit the most, therefore I'm awaiting for your feedback. Also, please let me know if any of these ideas are already implemented in any of the libraries. Here we go: * Selection algorithm (find the kth smallest element in a container, O(n) worst-case, very easy to implement) * Optimize Boost String Algorithm finders to use an efficient substring matching algorithm as opposed to the naive algorithm. Most likely because of the fact that boost has implemented the finders for strings as generic algorithms, they haven't used efficient algorithms such as KMP, Boyer-Moore, Rabin-Karp etc. \see boost/algorithm/string/detail/finder.hpp The idea is to implement efficient algorithms such as the ones mentioned above to replace the current naive implementation. Note: it may be difficult to find nth matching substring position using some of these algorithms. Difficulty: easy-medium * Implement a string algorithm for generating the suffix array. The suffix array, after being precomputed on a certain string, allows for very efficient substring searches in the future. This is useful when the string doesn't change too often but there are plenty of substring to search against. * Yet another efficient associative data structure, skip lists? * Space partitioning data structures? kd-trees? quadtrees? octtrees? collision detectors? closest neighbors? * A parser capable of evaluating mathematical expressions which contains operands,operators,function calls,variable names and constant names (also considering priority of operators): 1. a list of valid operators described by: a) number of operands (unary/binary/ternary?); b) allowed operand types; c) the precedence (priority of the operator) 2. a list of existent functions described by: a) function name; b) number of parameters; c) type of each parameter and return type; d) a callback (maybe just automatically deduce type based on the callback's type if possible) 3. a list of constants 4. a list of allowed variable names and types Here's a pseudo-C++ code sample on how it should look like: namespace m = boost::math_expressions_parser; m::parser p; p.add_operators() ('+', 1, ret<int32_t>(_1+_2)) // binary +, precedence 1 ('*', 2, ret<int32_t>(_1*_2)) // binary -, precedence 2 ('+', 3, ret<int32_t>(_1)) // unary +, precedence 3 ('-', 3, ret<int32_t>(-_1)); // unary - (also a funny face), precedence 3 p.add_functions() ("sin", ret<int32_t>(sin(_1))); p.add_constants() ("PI", 3); p.add_allowed_variables() (allowed_var<int32_t>("x")); m::expression E("1 + 3*sin(PI*x)", p); // evaluates mathematical expression E against parser p if (!E.valid()) { /* ... */ } else { std::cout << E.evaluate( ("x", 3) ); // evaluate this expression by letting x=3 E.let() ("x",4); std::cout << E.evaluate(); } //Maybe an optimization so only the parts that depend on the changed variable will be recalculated every time?. E.g.: for expression f(x)+y, f(x) is recomputed only when x is changed. This may cause problems for functions that do not always yield the same results for the same input. Maybe make this optimization optional, only if the user marks the function/operator as "volatile" or something Difficulty: hard-very hard * Someone suggested on this ml earlier that a crypto suite would be useful for boost. Maybe, but it would take a lot of time and dedication to implement. I believe that we should at least add some Cryptographic hash functions (such as md5, sha1, sha256 etc.). No one wants to install Crypto++ or something similar just to be able to compute the SHA1 sum of a file. It is a common necessity to want to compute a hash function of a string. Difficulty: very easy if you copy the implementation and just create a boost-ish interface * In-place radix sort? Radix sort is a very efficient algorithm which performs better than std::sort (my implementation) (also asymptotically better) for some particular types such as: uint8_t, uint16_t, uint32_t, unsigned char, unsigned char[2], unsigned char[4] etc. Radix sorting takes linear time, but unfortunately, linear memory. It is very useful for sorting very large amounts of numbers tho (or genetic codes and maybe some other stuff). I am able to implement some of these stuff and I'm waiting for your opinion in what would be most useful to be part of boost. Let me know if you believe that none will have any use. Yours sincerely, Stefan

8 15

[GSoC] - Graph.boost - Graph Connectives
by Davi Barbosa 09 Apr '10

09 Apr '10

Hi, I am interested in participation in GSoC 2010 in Boost.Graph. I liked the first two options, but between these two I am much more interested in the second (graph connectives) because it seems more useful and challenging. Unfortunately, I will be having classes until the end of June (some of them will end early), so I will have a restricted time at the beginning. Of course I am explaining this in my proposal and making the schedule work with this big restriction. Do you think this could be a big problem? I am having exams right now so I did not had the time to join the list, get in contact, etc. I already started writing a proposal, but I still have one exam in a 4 hours and only after that I will be able to really write it. After finishing a draft, I would like to know if I can send it in pvt to someone for a quick review. Is anyone able to do this big favor? I had some other questions, but I already asked them in the IRC channel (with the nick "recife"). Thanks for everyone who answered! Davi Barbosa.

2 1

[GSoC] Graph layout algorithms - proposal draft
by Milos Djuric 08 Apr '10

08 Apr '10

Hello everyone, I've put together a draft of my proposal for a GSoC project to work on graph layout algorithms. The proposal can be found here: http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/djura… I'd really appreciate if I could get some feedback (especially from possible mentors, and maybe someone from the Parallel BGL ?). All suggestions are more than welcome. Thanks, Milos

4 4

Re: [boost] [GSoC] Heaps & Queues (draft proposal)
by iaml 08 Apr '10

08 Apr '10

First of all, thank you, Andrew for your appreciation and Jeremiah for your information. I do not notice there exists d-ary in the BGL since I just focus on boost/pending and libs/pri_queue these days. But after a quick glance on the code in boost/graph/detail/d_ary_heap.hpp, I think that the container is supposed to have push_back() and pop()_back() because they are used directly in push() and pop(), This is something like the alias for vector type, not the parameter. Is that right or I just misunderstand the code in boost/graph/detail/d_ary_heap.hpp? As someone says: APIs design is main contributor to the Boost (I have read it today in somewhere in boost.org, but I can find it now :-( ). And I am lack of experience in APIs design for library. So I want to focus on my APIs design again. I know I am a bit annoying, but I want to do my best since it is my first time to join in GSoC. Feedback are welcome. It will be nice of you to do that. ==== description here ==== In order to be extendible, I would like to add iterator to the base class, which is more frequently used in programming, especially generic programming, than pointer. In some libraries, such as the STL, iterator is a bridge for container and algorithm. Since one of the goals of this project is to redevelop a new library for advance data structures and adaptors, I consider iterator to be necessary component to the library. Maybe it’ll take a little bit more memory, but in modern PCs, I think it acceptable.(*am I wrong about the usage of the iterator?*) template <class RandomAccessIterator, // iterator of the container class TreeNode, // key type class Comp = std::less<TreeNode>> class heap{ public: class iterator{ // implement iterator so that this class can be use as container // for other adaptors and algorithms public: TreeNode const& operator* () const; TreeNode const* operator->() const; iterator& operator++(); iterator operator++(int); bool operator== (iterator const& it); bool operator!= (iterator const& it); }; public: /* param: new_inserted points to the bottom of the container * where the new value has been inserted but not heapify. */ void insert(RandomAccessIterator new_inserted); void delete(RandomAccessIterator delete_node); void update(RandomAccessIterator update_node, TreeNode& new_node); // make the heap mutable RandomAccessIterator merge(RandomAccessIterator other_root); RandomAccessIterator getRoot(); RandomAccessIterator find(TreeNode& node); bool empty() const; size_type size() const; iterator begin() const; iterator end() const; void print() const; private: void print_recur() const; protected: RandomAccessIterator _root; }; NOTICE: operations print and print_recur is optional. But I prefer to include them because it'll be helpful when debugging the programs using this library. The class mentioned above is the base class for all the heap structures in the new library. The classes such as Fibonacci heap, relaxed heap, binomial heap and d-ary heap should inherit from this abstract class and add additional operations if needed. As the adaptor of heaps, the priority queue API may like: template< class RandomAccessIterator, class TreeNode, class Comp = std::less<TreeNode> class Container = fibonacci_heap<RandomAccessIterator, TreeNode, Comp>> class priority_queue{ public: /* param: new_inserted points to the place * where the new value has been inserted */ void push(RandomAccessIterator new_inserted); void pop(); // get the first value without popping it const TreeNode& front() const; TreeNode& front() ; RandomAccessIterator front() const; RandomAccessIterator find(TreeNode& node); void update(RandomAccessIterator update_node, TreeNode& new_node); // make the priority queue mutable RandomAccessIterator merge(RandomAccessIterator other_head); bool empty() const; size_type size() const; void print() const; private: void print_recur() const; protected: RandomAccessIterator _head; }; Thank you for your time. Yours sincerely, Tao Lin

2 3

Re: [boost] New Boost.XInt Library, request preliminary review
by Anders Dalvander 08 Apr '10

08 Apr '10

Chad Nelson wrote: > > > This disables the copy-on-write optimization that the library uses by > > > default [...] > > > > > I'm not convinced that integers should be COW. What situations do you > > forsee where COW would be helpful but move semantics wouldn't suffice? > > > As described on the rationale page of the documentation, the primary > reason I'm using copy-on-write is that move semantics aren't widely > available yet. Portability is one of my primary goals, and while I've > seen references to a move-semantics-emulator in Boost, I've also seen > suggestions that it relies on the compiler to somehow recognize it. That > doesn't sound fully portable to me. > No offense, but I'm not confident that COW semantics for the integer class is a wise design choice. I assume you have tested the performance with and without COW semantics, as well tested the performance for thread safe operations with and without COW semantics, before making that decision. Care to disclose the numbers? I guess that you have read the COW string article (http://www.gotw.ca/gotw/045.htm) by Herb Sutter, and his conclusions. Optimizations on other parts should perhaps have been made before converting to COW semantics. Using COW semantics could also complicate the complexity requirements for most functions, as they may be "amortized O(something)" instead of just "O(something)". Another concern I have is that NaN is "signaling" as most operations on a NaN integer will throw an exception. I think it would be more sound if operations on NaN integers would result in NaN integers, compare with float NaN. Don't take these comments the wrong way, I'm very glad to see development of an arbitrary precision integer boost licensed library. Best regards, Anders Dalvander

18 136

Crypto Library - Draft Proposal
by Chad Seibert 08 Apr '10

08 Apr '10

Hello, Here's a draft of my proposal. If you have any suggestions, I'd greatly appreciate that. Also, we can discuss any potential issues or concerns you may have. I have enabled "public" mode so it should be visible to all of you. http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/chads… Many thanks, Chad Seibert _________________________________________________________________ The New Busy is not the old busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…

3 2

Crypto Library Abstract
by Chad Seibert 08 Apr '10

08 Apr '10

Hi, Here's my abstract for the crypto library proposal. Any feedback would be greatly appreciated! "This proposal describes the porting of the cryptography library Botan and its integration with ASIO. Botan is released under the BSD license and the author has already agreed to porting it. The major reason for having a crypto library integrated with Boost is threefold: ASIO has SSL support that should be extracted out, adding TLS support for ASIO requires supporting many other block cipher types, and adding support for cryptography will add reasonable upgrades to Boost.Random and Boost.CRC as well. This is projected to take about 3-4 months to complete." Thank you, Chad Seibert _________________________________________________________________ The New Busy is not the old busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…

2 1

Status of Boost.Move(https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Move)
by Anton Potapov 08 Apr '10

08 Apr '10

Hi, That is the status of boost.move library(https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Bo… Regards

5 8

[contract] Macro syntax?
by Lorenzo Caminiti 08 Apr '10

08 Apr '10

Hello all, I would like you to vote between one of the two options below. Which option do you prefer? (-) OPTION 1 requires programmers to repeat the function signature tokens twice -- in the function declaration and in the CONTRACT_FUNCTION() macro. (+) However, OPTION 1 seems to make the code more readable -- users not familiar with Boost.Contract can "skip" the tokens in the CONTRACT_FUNCTION() signature-sequence and just read the usual C++ function declaration. OPTION 1: The function declaration is programmed using the usual C++ syntax just before the CONTRACT_FUNCTION() macro. template<typename T> class myvector { CONTRACT_INVARIANT( ({ ... }) ) public: void push_back(const T& element) // Usual C++ push_back() declaration. CONTRACT_FUNCTION( (class) (copyable)(myvector) (public) (void) (push_back)( (const T&)(element) ) (precondition)({ ... }) (postcondition)({ ... }) (body)({ ... }) ) ... }; OPTION 2: The CONTRACT_FUNCTION() macro automatically programs also the function declaration. template<typename T> class myvector { CONTRACT_INVARIANT( ({ ... }) ) public: // No usual C++ push_back() declaration here. CONTRACT_FUNCTION( (class) (copyable)(myvector) (public) (void) (push_back)( (const T&)(element) ) (precondition)({ ... }) (postcondition)({ ... }) (body)({ ... }) ) ... }; Thank you. Lorenzo

4 7

[Review Results] Boost.Polygon library accepted into boost
by Fernando Cacciola 07 Apr '10

07 Apr '10

Dear Boosters, [first of all allow me to apology for not doing this before. My small consulting bussines suddenly grew out of proportion and now is way over my head, keeping me working/managing 16 hours a day] I am pleased to announce that the Boost.Polygon library from Lucanus Simonson has been accepted into boost provided some of the most critical concerns, detailed below, are addressed first. First of all I would like to thank Lucanus and Intel Corporation for making this work available to all C++ developers around the world. I would also like to thank all the reviewers that participated (in no particular order nor degree of participation) Thomas Klimpel Frank Mori Hess Barend Gehrels Andreas Fabri Jeffrey Hellrung Tim Keitt Markus Werle Paul A. Bristow Robert Stewart Mathias Gaunard Michael Fawcett Steven Watanabe Joachim Faulhaber John Bytheway Sebastian Redl Mika Heiskanen John Phillips Kai Benndorf Hartmut Kaiser Arash Partow Maurizio Vitale Brandon Kohn David Abrahams Gordon Woodhull Daniel James John Maddock Tom Brinkman Bo Persson Mateusz Loskot Christian Henning Jean-Sebastien Stoezel The library had 6 yes votes and 4 no votes. Those who voted no made the following major complains and remarks (they are numbered as I will refer to them back later): Barend Gehrels: (1) According to his benchmarks, intersection algorithms are unnecesarily slow as if something where fundamentally wrong in the design and/or implementation. AFAICT the implication has not been proved or disproved so far, hence I consider it a red herring and cannot take it as a reason for rejecting the library, but it is important to look at it in detail. (2) As a major complain, the library is unusable in those domains where floating point support is a requirement (like GIS). (3) The library should contain some basic polygon geometry algorithms such as convex hull and centriod Phil Endecott: (4) There is no concept checking in the code so it is difficult to adapt. (5) There where too many warnings and build errors (but Luke fixed these) (6a) The documentation needs a better overview of operations supported by the concetps. (6b) It also needs the details on the algorithms complexities. (6c) It also misses the numerical requirements for the coordinate type. (6d) And tutorials. (7) Some operators are ambiguous and it would be better to keep just one of each "flavor". (8) The polygon_data template class is parameterized by a coordiante type rather than a point type. This makes it useless for integration with existing geometric data types Michael Fawcett: (5), (6a), (6d) (9) T9he API should provide versions using output iterators in addition to output container references. (10) Theoreticall the library would be usable with a user defined coordinate type (metting certain requirements now undocumented), for example a fixed point data type, but some details in the internal design and implementation prevents this. (11) As a major complain, the library is unusable in those domains where floating point support is a requirement (like GIS). Hartmut Kaiser: (11), (1) Fernando Cacciola: (12) The name of the library should change to better indicate that is restricted to Integral coordinates and two-dimensions. (13) The documentation must contain a "credits" section acknowledging all the people that participated in the review. For the library to be effectively accepted, points (5),(6a-d),(10), (12) and (13) should properly addressed ((5) is already done AFAICT) It would be quite significant if point (1) where looked into. Once again I thank Lucanus, Intel Corporation and all the reviwers. Best regards -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com

4 4

Re: [boost] [msm] new version available
by Christophe Henry 07 Apr '10

07 Apr '10

>>>> Hi all, >>>> >>>> I just finished the newest MSM version. Unfortunately, I'm afraid I'm >>>> a bit late to get it shipped with boost v1.43 but at least it will >>>> give us time to have a look at it. >>>> What is new: >>>> - the doc was rewritten almost from the ground up. >>> <snip> >>>> You can find the new version, like always: >>>> - in the Vault (http://www.boostpro.com/vault/index.php?directory=Msm) >>>> - in the sandbox (http://svn.boost.org/svn/boost/sandbox/msm/) >>>> >>>> Regards, >>>> >>>> Christophe >>> >>> Hi, >>> >>> Just a form remark. We use to see the code highlighted. Have you the possibility to highligth the code? >>> >>> Best, >>> Vicente >> >> >> Done and committed in the Sandbox. > > Hi, I see that you used <programlisting>. Shouldn't you use <programlisting language="c++"> or somthing like that? > > Best, > Vicente I could but as I didn't see any difference in the generated html, I suppose it is an unimportant attribute. Regards, Christophe

1 0

Crypto Library
by Chad Seibert 07 Apr '10

07 Apr '10

> Hi, > > I've just got confirmation from Jack Lloyd that I can port Botan to Boost. He only uses Boost.Python currently because he was having issues with shared_ptr when compiling for ARM. However, I think that most of these issues will be resolved (or have been) when the porting process takes place. Is there any protocol for porting an entire library to Boost? I know that ASIO took a while for approval. > So I'm going to ask a heretical question: why do you/he want to add it > to Boost? > Please don't make it header only in the process or I will be forced to > look at CryptoPP which is guaranteed to make babies cry. I was just getting a community response to porting a library, in this case Botan, vs constructing a library from scratch. Given that Botan is not heavily templatized, so there shouldn't be a reason this lib is headers only. However, any specializations will have to be. Tomorrow morning I'll have a draft proposal up for peer review. Many thanks for your input, Chad Seibert _________________________________________________________________ The New Busy is not the old busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…

1 0

Porting Botan to Boost
by Chad Seibert 07 Apr '10

07 Apr '10

Hi, I've just got confirmation from Jack Lloyd that I can port Botan to Boost. He only uses Boost.Python currently because he was having issues with shared_ptr when compiling for ARM. However, I think that most of these issues will be resolved (or have been) when the porting process takes place. Is there any protocol for porting an entire library to Boost? I know that ASIO took a while for approval. Thanks, Chad _________________________________________________________________ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…

4 3

[GSoC] Binomial and Fibonacci heap implementation project
by Суворов Дмитрий 07 Apr '10

07 Apr '10

Hello, My name is Dmitriy. I'd like to participate in GSoC2010 with the Boost project. I looked through you ideas list, and I think i could do Binomial heap and Fibonacci heap as a summer project. I've composed a draft of my proposal, could you comment on it? My name is Dmitriy Suvorov. I'm a student of Bauman Moscow State Technical University. I am a third course student of a Robotics department. My degree program is BS. My email is dmitriy_suvorov(a)inbox.ru. I don't have any homepage. I plan to spend 5-5.5 hours per day on coding in June and 8 hours per day in July and August. I plan to start coding on May 24th. And I am going to stop coding on 30th August. I can't spend more time in June because I have university's exams. I think I won't spend much time on coding in September because university courses will start. But I am going to continue my work on Boost library in autumn. My middle degree in university is 4.76 (maximum is 5.0). I've taken courses in mathematics, programming and electronics. I'm interested in coding with application of mathematical algorithms. Now I'm working on robotics computer vision to participate in international competitions "Eurobot 2010". I'm going to take part in open source project for the first time. I'm interested in contributing to the Boost C++ Libraries and I want to gain an experience in programming. I'd like to solve interesting problems. I have knowledge about data structures and want to apply my knowledge in practice. I'm going to read more information about data structures and Boost C++ Libraries in May. My rates, from 0 to 5 (0 being no experience, 5 being expert), of my knowledge of the following languages, technologies, or tools: C++ - 5 C++ Standard Library - 5 Boost C++ Libraries - 3 Subversion - 4 I like Visual Studio to write Windows programs and KDevelop to write Linux programs. The most familiar software documentation tool with me is Doxygen. I want to work on binomial heap. If I'll solve problem quickly I want to work on other data structure, for example, on Fibonacci heap. Binomial heap is implementation of the mergeable heap abstract data type which is a priority queue supporting merge operation. Binomial heap is a collection of binomial trees. A binomial tree is defined recursively: - A binominal tree of order 0 is a single node. - A binomial tree of order k has a root node whose children are roots of binomial trees of orders k-1, k-2, +, 1, 0. All operations work on O(log n) time on a binomial heap with n elements. Fibonacci heap is a heap data structure consisting of a forest of trees. It has a better amortized running time than a binomial heap. These heaps are used in to improve asymptotic time of important algorithms, such as Dijkstra's algorithm for computing shortest path in a graph, and Prim's algorithm for computing a minimum spanning tree of a graph. I have found implementations of binomial heap in C and Python at LITMUS project. The homepage of project is www.cs.unc.edu/~anderson/litmus-rt/ . I'm going to create a new class for the Binominal heap and polish current implementation of Fibonacci heap. I will use Introduction to algorithms by Cormen, Leiserson as a reference. Could you review this?

3 4

Re: [boost] [msm] new version available
by Christophe Henry 07 Apr '10

07 Apr '10

>> Hi all, >> >> I just finished the newest MSM version. Unfortunately, I'm afraid I'm >> a bit late to get it shipped with boost v1.43 but at least it will >> give us time to have a look at it. >> What is new: >> - the doc was rewritten almost from the ground up. > <snip> >> You can find the new version, like always: >> - in the Vault (http://www.boostpro.com/vault/index.php?directory=Msm) >> - in the sandbox (http://svn.boost.org/svn/boost/sandbox/msm/) >> >> Regards, >> >> Christophe > > Hi, > > Just a form remark. We use to see the code highlighted. Have you the possibility to highligth the code? > > Best, > Vicente Done and committed in the Sandbox. Thanks for your help, Christophe

2 1

Re: [boost] [GSoC] Heaps & Queues (draft proposal)
by iaml 07 Apr '10

07 Apr '10

First of all, thank you, Andrew and Luke, for pointing out my mistakes and misunderstanding in my draft project which I sent several days ago. After that, I have read some source code in the STL and do some more research on this topic. Now, I work out my draft proposal again. Please feel free to point out my stupidity. I will be very grateful for this. Besides, I still have some doubt on this project: What we need to do in this project is to build a new library as the result of decoupling boost/pending from the BGL. So the compatibility with the new library and the BGL need to be concerned. However, I have read the document in the BGL. It’s said that we can convert existing graphs to the BGL by implementing some functions. Dose it mean the APIs of the new library does not effect the compatibility of the new library and the BGL since we can change it properly. Is that right? ==== draft proposal v0.2 ==== Project Proposal * Please provide a description of your proposed work. ** Background There are a number of data structures in boost/pending that implement different kinds of heaps and queues that are used in a number of different Boost Graph (BGL) algorithms. These can be cleaned up, decoupled from the BGL and redeveloped into a useful library for advanced data structures. Why don’t we use them directly? We can’t use boost/pending or libs/pri_queue as the new library directly for several reasons: 1. Heaps don’t parameterize for container type. They use vector as default. In the STL, there is very clear abstraction between containers and algorithms (they use iterator to achieve this abstraction). Since abstraction is a goal of the project, it’s necessary to modify the data structure in boost/pending rather than use it directly. 2. The APIs designed in the boost/pending is not user-friendly. In my opinion, the heaps in boost/pending act as the container of the priority queue rather than as a data structure. So some operations are omitted since they are useless in priority queue, but useful in heap and maybe necessary for other adaptors. They lack some operations such as delete one key (not just pop the minimum or maximum key), update the key in heap. This leads to the necessity of redeveloping a new library. ** Benefit for Boost Heap is widely used in development such as heap sort, priority queue and other graph algorithm. It also can be the container for advanced data structures. But the heaps in boost/pending and libs/pri_queue is not extendable or highly abstract. This leads to the limited usage of this library. To redevelop a new library about heaps and priority queue more abstract and more user-friendly not only can broaden the user group of Boost, but also can fix the design deficiency in boost/pending and make it more conforms to the philosophy of Boost. ** Solution In my opinion, most of work is to rewrite and reuse the existing data structures in boost/pending and libs/pri_queue. The most important thing I should consider is the APIs design of the new library. It should be highly abstract and user-friendly. The compatibility with the new library and the BGL needs to be concerned. *In order to be extendible, I would like to add iterator to the base class, which is more frequently used in programming, especially generic programming, than pointer. In some libraries, such as the STL, iterator is a bridge for container and algorithm. Since one of the goals of this project is to redevelop a new library for advance data structures and adaptors, I consider iterator to be necessary component to the library. Maybe it’ll take a little bit more memory, but in modern PCs, I think it acceptable.(am I wrong about the usage of the iterator?)* * * Besides the heaps required, I would like to add d-ary heap into the new library. Because d-ary heap is a variation of binary heap (so I can use binary heap as a special case for d-ary) and has faster running time. If time permits, I want to add splay heap (because it has the attractive property that recently accessed elements are quick to access again. I think it will be very useful in application software programming) and other heaps mentioned in libs/pri_queue into the new library. Below is my design to the library APIs. template <class RandomAccessIterator, // iterator of the container class TreeNode, // key type class Comp = std::less<TreeNode>> class heap{ public: class iterator{ // implement iterator so that this class can be use as container // for other adaptors and algorithms public: TreeNode const& operator* () const; TreeNode const* operator->() const; iterator& operator++(); iterator operator++(int); bool operator== (iterator const& it); bool operator!= (iterator const& it); }; public: /* param: new_inserted points to the bottom of the container * where the new value has been inserted but not heapify. */ void insert(RandomAccessIterator new_inserted); void delete(RandomAccessIterator delete_node); void update(RandomAccessIterator update_node, TreeNode& new_node); // make the heap mutable RandomAccessIterator merge(RandomAccessIterator other_root); RandomAccessIterator getRoot(); RandomAccessIterator find(TreeNode& node); bool empty() const; size_type size() const; iterator begin() const; iterator end() const; void print() const; private: void print_recur() const; protected: RandomAccessIterator _root; }; NOTICE: operations print and print_recur is optional. But I prefer to include them because it'll be helpful when debugging the programs using this library. The class mentioned above is the base class for all the heap structures in the new library. The classes such as Fibonacci heap, relaxed heap, binomial heap and d-ary heap should inherit from this abstract class and add additional operations if needed. As the adaptor of heaps, the priority queue API may like: template< class RandomAccessIterator, class TreeNode, class Comp = std::less<TreeNode> class Container = fibonacci_heap<RandomAccessIterator, TreeNode, Comp>> class priority_queue{ public: /* param: new_inserted points to the place * where the new value has been inserted */ void push(RandomAccessIterator new_inserted); void pop(); // get the first value without popping it const TreeNode& front() const; TreeNode& front() ; RandomAccessIterator front() const; RandomAccessIterator find(TreeNode& node); void update(RandomAccessIterator update_node, TreeNode& new_node); // make the priority queue mutable RandomAccessIterator merge(RandomAccessIterator other_head); bool empty() const; size_type size() const; void print() const; private: void print_recur() const; protected: RandomAccessIterator _head; }; Thank you for reading

3 2

Gsoc Boost.Graph: implementing new algorithms
by Camillo Anania 07 Apr '10

07 Apr '10

Hi guys, I'm developing my thesis using BGL. Now it's some months I'm working on it and this is what I would like to see implemented on BGL and partially what I'm working on in those months: - check if graph have an euler tour(is eulerian) and find one and/or all possible euler tours - add the support for mixed graph - add the algorithm to find a minimum cost maximum matching I would like to know an opinion about that. Thanks Camillo

2 4

Crypto Suite
by Chad Seibert 07 Apr '10

07 Apr '10

> Hi, > > I was looking through previous GSoC ideas and I was interested in doing a crypto suite as described here: > > http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summe… > > I was wondering if this was still in high demand, as I've been tied between doing this and the BigInt library proposed on the ideas page. The only reason I ask is because I'd like to do the most good for this project and wonder which project that might be. > > Thank you for any input, > Chad Seibert > > _________________________________________________________________ > Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. > http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:… > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > > Sure you want to do this from scratch? Botan uses Boost - why not ask > Jack Lloyd if he'd let you pull bits of it down into Boost? Well, as I'm writing the proposal, I'm more emphasizing the structure of generic implementations of crypto-like stuff, not the actual implementations of MD5, AES, RSA, etc. The second half of my proposal was on actual implementation, where I discuss using either Crypto++ or Botan, with author permission. I'm in the midst of getting that permission. _________________________________________________________________ The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28…

3 2

License on Interprocess Containers
by Hal Finkel 07 Apr '10

07 Apr '10

Hello, boost/interprocess/containers/container/vector.hpp contains the following in the license header (directly underneath the BSL header): ////////////////////////////////////////////////////////////////////////////// // // This file comes from SGI's stl_vector.h file. Modified by Ion Gaztanaga. // Renaming, isolating and porting to generic algorithms. Pointer typedef // set to allocator::pointer to allow placing it in shared memory. // /////////////////////////////////////////////////////////////////////////////// // Copyright (c) 1994 // Hewlett-Packard Company // // Permission to use, copy, modify, distribute and sell this software // and its documentation for any purpose is hereby granted without fee, // provided that the above copyright notice appear in all copies and // that both that copyright notice and this permission notice appear // in supporting documentation. Hewlett-Packard Company makes no // representations about the suitability of this software for any // purpose. It is provided "as is" without express or implied warranty. [ With a similar license statement under the SGI copyright ] In my view, one of the strengths of the BSL is that it specifically does not require notice in "supporting documentation." It is possible that this portion of the license is no longer in effect, since the header on the STLport vector header now reads: * Copyright (c) 1994 * Hewlett-Packard Company * * Copyright (c) 1996,1997 * Silicon Graphics Computer Systems, Inc. * * Copyright (c) 1997 * Moscow Center for SPARC Technology * * Copyright (c) 1999 * Boris Fomitchev * * This material is provided "as is", with absolutely no warranty expressed * or implied. Any use is at your own risk. * * Permission to use or copy this software for any purpose is hereby granted * without fee, provided the above notices are retained on all copies. * Permission to modify the code and to distribute modified code is granted, * provided the above notices are retained, and a notice that the code was * modified is included with the above copyright notice. And in this case, perhaps the affected files can be updated to reflect the less-onerous STLport license. Otherwise, the files could be replaced with STLport-derived files, or HP and SGI could be asked to provide permission. Any opinions? Thanks again, Hal

2 3

Important: Server Upgrade Wednesday, April 7
by Doug Gregor 07 Apr '10

07 Apr '10

The main Boost server will be down for a Trac upgrade on Wednesday, April 7 from 8am-9am Eastern time. The following services will be affected: Web server (boost.org) Subversion Trac Mailing list archives Mailing lists should still function as normal. My apologies for the late notice. - Doug

1 0

[move] pre-review comments
by Jeffrey Lee Hellrung, Jr. 07 Apr '10

07 Apr '10

I have some (long overdue) comments concerning Ion Gaztanaga's proposed Boost.Move library. First, Ion, great job on the documentation and implementation. Both are very readable and usable. These comments stem from my own use and perceived deficiencies in the current state of affairs, but they might also lead to a more complex library. So take them however you want, and you (Ion) and others may respond at your own convenience. In below, when I refer to "C++03 compilers", I mean compilers without rvalue rferences; when I refer to "C++0x compilers", I mean compilers that do have rvalue references. Also, some details are lacking, as I'm writing this kind of haphazardly and over a couple hours while watching the Jazz-Lakers game... -------- boost::rv<T> ------------ The library should clearly define what requirements a class needs to satisfy to work with the library's facilities, specifically when rvalue references are not available. For C++03 compilers, this will involve defining boost::rv<T>, conversion operators to boost::rv<T>& and (if copyable) const boost::rv<T>&, and what constructors and assignment operators there should be and their semantics. I think this interface specification is of primary importance, and the remaining facilities are of secondary importance. boost::is_movable<T> -------------------- This should evaluate to a Boost.MPL integral constant, and it should still work for builtin types (and return false). BOOST_FWD_REF( T ) / boost::forward<T>(x) ----------------------------------------- I think there should be 2 forwarding mechanisms. One is BOOST_FWD_REF( T ) (paired with boost::forward<T>(x)), which expands to const T& on C++03 compilers and is able to capture rvalues. The other I've called BOOST_PERFECT_FWD_REF( T ) (paired with boost::perfect_forward<T>(x)), which expands to T& and will *not* capture rvalues, but will correctly forward lvalue references to non-const. I'm open to alternative names. The intent is that you can use BOOST_PERFECT_FWD_REF( T ) if you know you will never need to capture rvalues (e.g., it will only receive the result of a boost::forward or boost::perfect_forward). I think it might also be useful to provide metafunctions boost::forward_param<T> and boost::perfect_forward_param<T> that strips off any {const} boost::rv<T>&'s for use with Boost.ResultOf. BOOST_MOVABLE_BUT_NOT_COPYABLE / BOOST_COPYABLE_AND_MOVABLE ----------------------------------------------------------- I don't use these. Instead, I've created no fewer than 10 macros to enable move emulation, depending on the particular application: BOOST_BASIC_MOVABLE_COPYABLE( T ) BOOST_MOVABLE_NONCOPYABLE( T ) BOOST_MOVABLE_COPYABLE_DEFINE_COPY_ASSIGN_FROM_MOVE( T ) BOOST_MOVABLE_COPYABLE_DEFINE_COPY_ASSIGN_FROM_SWAP( T ) BOOST_OPTIMAL_MOVABLE_COPYABLE( T ) BOOST_FRIENDLY_MOVABLE_COPYABLE( T ) BOOST_OPTIMAL_MOVABLE_COPYABLE_IF( T, Cond ) BOOST_FRIENDLY_MOVABLE_COPYABLE_IF( T, Cond ) BOOST_OPTIMAL_MOVABLE_COPYABLE_IF_MOVABLE( T, U_seq ) BOOST_FRIENDLY_MOVABLE_COPYABLE_IF_MOVABLE( T, U_seq ) BOOST_BASIC_MOVABLE_COPYABLE provides a move constructor and a move assignment operator, but does not provide a mechanism to move assign automatically from rvalues. I typically use this in base classes. BOOST_MOVABLE_NONCOPYABLE should be self-explanatory. BOOST_MOVABLE_COPYABLE_DEFINE_COPY_ASSIGN_FROM_MOVE( T ) defines a by-value copy assignment via copy-and-move. Similarly, BOOST_MOVABLE_COPYABLE_DEFINE_COPY_ASSIGN_FROM_SWAP( T ) defines a by-value copy assignment via copy-and-swap. Implementing copy assignment to receive by value captures rvalues optimally via copy RVO. BOOST_OPTIMAL_MOVABLE_COPYABLE* and BOOST_FRIENDLY_MOVABLE_COPYABLE* differ in how rvalues are captured for assignment on C++03 compilers. OPTIMAL declares an operator=(T&) that forwards to the copy assignment operator, and an operator=(const rv<T>&) to move assign. As has been discussed previously, this has undesirable consequences if you rely on the compiler to generate the copy assignment operator in a class enclosing an "optimal movable" type. FRIENDLY declares an operator=(T) (on C++03 compilers) and implements it in terms of the move assignment operator. On C++0x compilers, both use an operator=(T&&) and operator(const &). BOOST_*_MOVABLE_COPYABLE_IF( T, Cond ) enables movability if Cond is true, and does not define a move constructor and move assignment operator if Cond is false. Similarly, BOOST_*_MOVABLE_COPYABLE_IF_MOVABLE( T, U_seq ) will enable movability if any type in the Boost.PP seq U_seq is movable (as determined by boost::is_movable). "The rest of the stuff" ----------------------- I'd consider iterator's and algorithm extensions to be of tertiary importance, and I haven't yet used them. - Jeff

2 6

[gsoc] heaps & queues
by Cezary Bartoszuk 06 Apr '10

06 Apr '10

Hi, I looked at APIs at https://svn.boost.org/svn/boost/sandbox/libs/pri_queue/ The interfaces are quite well designed, but I don't understand one point: Why are there function templates used in methods providing mutability (for example change_top, change, decrease, increase for the lazy Fibonacci heap: https://svn.boost.org/svn/boost/sandbox/libs/pri_queue/l_heap.html)? I think K stands there for "key", but there's already comparison functor (which defaults to std::less) provided, so we don't store key-value pairs (with key being the priority), do we? Why then K is used? The second key point I would like to ask about is the implementation. Are there any priority queues already implemented in BGL? If so, it would be nice for us to stay compatible with interfaces implemented already. Besides few doubts listed above I would like to propose implementing at least pri queues listed in https://svn.boost.org/svn/boost/sandbox/libs/pri_queue/, so: * D-ary Heap (with standard - binary - heap as a special case) * Fibonacci Heap (btw, I thought, the Fibonacci heap is already lazy - maybe there's an discrepancy in the names) * Pairing Heap (didn't ever hear about them, but there are lots of references in the net) * Splay Heap (think it's a gret idea - simple implementaion and quite nice performance) * Radix Heap (also didn't hear about them, but the intuition is, that's a dara structure implementing radix-sort?) Speaking about stable priority queues (FIFO- or LIFO- stable) i have no fresh ideas for now, but I think it's quite useful, and would be happy to implement it. I have read that there are lots of people submitting proposals for the project; could any partition of work or time estimation be a part of the proposal (because there will surely be at least few of us working on the Heaps & Queues)? Best regards, Cezary Bartoszuk P.S. As I read threads about heaps & queues, I think also that the interfaces are a little bit too complicated. Quite good idea is implementing methods push, min, pop, decrease_key. Personally I don't see any algorithms using both decrease_key and increase_key. Usually there is intention of pushing priority "to the front" rather than "to the back". And there is also thing with iterators: I haven't seen any implementation iterating through pri_queue. So are interfaces based on push, min, pop, decrease_key accurate?

2 1

GSoC 20010: Boost.Thread towards the C++0x standard proposal
by vicente.botet 06 Apr '10

06 Apr '10

Hi, Is someone interested in adapting the current Boost.Thread interface to the C++0x stardard proposal? Best, _____________________ Vicente Juan Botet Escribá

4 5

GSoc Proposal - Crypto Suite
by Chad Seibert 06 Apr '10

06 Apr '10

Hi, I was looking through previous GSoC ideas and I was interested in doing a crypto suite as described here: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summe… I was wondering if this was still in high demand, as I've been tied between doing this and the BigInt library proposed on the ideas page. The only reason I ask is because I'd like to do the most good for this project and wonder which project that might be. Thank you for any input, Chad Seibert _________________________________________________________________ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…

3 2

[GSoC] Patterns - interest check
by Kornel Kisielewicz 06 Apr '10

06 Apr '10

Hello all, I'm (obviously) interested in joining boost as part of GSoC 2010. Apart from a repeated try of generating interest in the Boost.Matrix library I proposed last year (I'll probably post about it later), I'll share an idea of mine that has been around in my head since I was introduced to boost several years ago. It all began with the singleton pattern -- we were writing a project, and needed a singleton base class quick, hence the first place we turned to was boost. There, two surprises awaited us -- not only wasn't there a singleton library easily available, but in the boost sources there were several singleton base class implementations, few of them even exact the same. True it is that singleton implementations differ - we want to be able to sometimes control the initialization time and initialization order, we sometimes need thread safety, and sometimes not, we'd like to control how to handle creation, and how to handle referencing to a dead singleton -- obviously a bloated master-class is not the solution -- a policy based singleton template however would be. Once that came into my mind, I couldn't shake the idea of a general Boost.Patterns library. While indulging in a discussion of whether Patterns are beneficial or not isn't my goal, we must admit that they are commonly used, and several of those are already present in Boost in one form or another (signals and flyweight comes up to mind as an obvious example). Boost.Patterns would serve as a library for collecting those patterns that aren't big enough for their own library, and encompass the smaller class traits (like boost::noncopyable) too. Apart from the singleton, one obvious candidate for such a library that I'd like to code are the factory patterns, including the abstract factory pattern. A policy based implementation of those might provide a nice benefit for boost users not wanting to reinvent the wheel. Further out, there are a few more commonly used patterns that would be beneficial for a boost::patterns user. The way I see it, for the more complex solutions, some framework of base classes to be used would have to be designed, and then used between the patterns. Mind you, I'm not trying to convince anyone to the creation of a new Boost.Patterns library (although I'd really like to do that if possible), instead I'd like to ask you if there's a viable GSoC proposal in this post, one that one day might turn into a useful part of boost. -- regards, Kornel Kisielewicz http://chaosforge.org/

2 2

Re: [boost] [msm] new version available
by Christophe Henry 06 Apr '10

06 Apr '10

> On Monday 05 April 2010 09:12:14 Christophe Henry wrote: >> I just finished the newest MSM version. Unfortunately, I'm afraid I'm >> a bit late to get it shipped with boost v1.43 but at least it will >> give us time to have a look at it. > > You are still within the merge window and given that your documentation seems > to be in excellent shape, there is no reason to delay it past 1.43. Here's the > calendar for 1.43.0: > http://www.boost.org/development/index.html > > Regards, > Ravi Really? I thought Monday was deadline. What I am missing are regression tests, but if the Release managers allow it, I could write them this week (I never wrote a jamfile but for the sake of the argument, let's suppose I get this right). Release managers, is it still possible to ship MSM with 1.43? Christophe

2 1

[utility/result_of] decltype-based implementation breaking valid code on msvc-10
by Eric Niebler 06 Apr '10

06 Apr '10

I recently looked into some proto failures on msvc-10 and traced them back to the use of decltype in the implementation of boost::result_of. The program below demonstrates the problem: // Uncomment the next line to make the problem go away //#define BOOST_NO_DECLTYPE #include <boost/utility/result_of.hpp> template<class X, class Y> struct pair {}; template<class Base> struct S; struct wrapper { template<class T> struct result; template<class This, typename That> struct result<This(That)> { typedef S<That> type; }; template<typename That> typename result<wrapper(That)>::type operator()(That) const { return 0; } }; template<class T> struct S { S(int = 0) {} typename boost::result_of<wrapper(pair<T, T>)>::type foo() { return 0; } }; int main() { S<int> s; } The use of decltype in result_of causes the compiler to recursively instantiate templates until it blows its stack. To make the problem go away, you must #define BOOST_NO_DECLTYPE. I suspect the real problem is in a buggy implementation of decltype on msvc-10. For the upcoming boost release, I suggest that we stick with the non-decltype implementation of result_of on msvc-10, or risk massively breaking users' code, not to mention proto, spirit and xpressive on that compiler. -- Eric Niebler BoostPro Computing http://www.boostpro.com

5 7

Re: [boost] [utility/result_of] decltype-based implementation breaking valid code on msvc-10
by Eric Niebler 06 Apr '10

06 Apr '10

On 4/5/2010 6:05 PM, Daniel Walker wrote: > On Mon, Apr 5, 2010 at 6:39 PM, Eric Niebler<eric(a)boostpro.com> wrote: >> https://svn.boost.org/trac/boost/ticket/4072 >> >> A patch is attached to the ticket. I've confirmed that it un-breaks proto on >> msvc-10, but have not tested it further. > > Good catch. Seems reasonable to me. In general, if some vendor > releases an inadequate std:result_of or decltype, it would be good to > have boost::result_of as a functional fallback, which is yet another > reason to resolve the lambda/result_of issue. Enabling lambda to > support boost::result_of's signature protocol, as in ticket 864, would > do the trick. That way msvc-10 users would be able to enjoy > lambda/result_of compatibility, even if msvc-10 still has some > wrinkles. Daniel, I don't necessarily disagree, but I'm not really interested in getting this small issue mixed up with the larger issue of lambda/result_of compatibility. I just want result_of to work on msvc-10. -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 4

Re: [boost] [msm] new version available
by Christophe Henry 06 Apr '10

06 Apr '10

> Christophe Henry wrote: >> Hi all, >> >> I just finished the newest MSM version. Unfortunately, I'm afraid I'm >> a bit late to get it shipped with boost v1.43 but at least it will >> give us time to have a look at it. >> What is new: >> - the doc was rewritten almost from the ground up. >> - internal transitions: for all front-ends, and both ways: either in >> the transition table or inside state's internal transition tables >> - more row types (yes, even more) allowing actions to be defined in >> state machines or in states >> The last 2 points aim at making states more useful >> > > Christophe - > > I'm looking forward to trying it out. > > michael I'm counting on your always very useful comments! Thanks, Christophe

1 0

python/test/Jamfile.v2 help needed
by Ralf W. Grosse-Kunstleve 06 Apr '10

06 Apr '10

I've merged the current boost/python and libs/python trunk into the release branch, followed by this patch: Index: libs/python/test/Jamfile.v2 =================================================================== --- libs/python/test/Jamfile.v2 (revision 61033) +++ libs/python/test/Jamfile.v2 (working copy) @@ -184,8 +184,10 @@ # bpl-test bienstman5 ; # } -[ bpl-test calling_conventions ] -[ bpl-test calling_conventions_mf ] +# XXX disabled on release branch only, +# XXX to avoid failures on platforms other than Windows +# [ bpl-test calling_conventions ] +# [ bpl-test calling_conventions_mf ] # --- unit tests of library components --- Is it possible to have those two tests built and run only under Windows? Thanks! Ralf

3 5

[GSOC2010] HEAPS & QUEUES draft proposal
by Alexandru Damian 06 Apr '10

06 Apr '10

Hello everyone, My name is Alexandru Damian. I am a second year student at the Polytechnic University of Bucharest, Romania. I am very interested in the Heaps & Queues idea, and with both a good programming and mathematical background, I believe that I can offer valuable ideas to this project. Below is a draft proposal for this. I didn't know what you would expect from such a proposal (talked to grafikrobot on freenode and he redirected me here), so the structures that are to be implemented are rather vague. If the proposal is on track, I will detail them. I have also talked so some guys on the irc channel about a more generic approach to trees and tries. What's your opinion on that (given that tree structures are already implemented in /intrusive)? I hope I'm not too annoying :). ***STUDENT PROPOSAL: HEAPS & QUEUES*** NOTE: My Student Proposal follows the template listed on: https://svn.boost.org/trac/boost/wiki/SoCSubmissionTemplate **PERSONAL DETAILS** NAME: Alexandru Damian UNIVERSITY: Polytechnic University of Bucharest MAJOR: Computer Science and Engineering DEGREE PROGRAM: B.Sc. EMAIL: alexdamian1989(a)gmail.com AVAILABILITY: According to the official timeline, there will be 11-12 weeks at my disposal: March 24 - August 9 (16). However, I plan to contract the "Community Bonding Period" to 2-3 weeks, so that I may have at least one week advance in coding. This will help me better organize my time during the summer, when I will be unavailable for about 2 weeks (in June) because of my exams. **BACKGROUND INFORMATION:** EDUCATIONAL & WORK BACKGROUND: I have been preparing in the fields of Computer Science and Mathematics since high-school when I have competed in numerous national and international competitions, gaining important experience and always finishing among the best. My interest in personal and professional growth has continued at university as well, with even better results at contests and scientific research. My work background and coursework have supplied me with many skills in theoretical computer science, data structures, algorithms and programming languages. In addition, I have broad experience in Mathematics and problem solving techniques. In the year 2009, I have worked at different projects for the Faculty of Automatic Control and Computers, including the research and development of a way to store and illustrate the temperature ratio in the University server room. The same year, I worked as a volunteer student consultant and I offered support in Mathematics for students taking the admission examinations. EXPRESSION OF INTEREST: Boost C++ Libraries has caught my attention in 2008, when I had my first important encounters with the Open Source Community. A library that offers more advanced data structures and algorithms than STL is needed on a daily basis when optimizing complex code. It is only natural for me to choose the "Heaps & Queues" project, as I have valuable experience in the algorithms that power these structures and their real-world applications. My plans for further support and development of the Boost C++ Libraries will extend even after the GSOC deadline, with plans to implement more algorithms supplementary to the work done during the summer and in other areas (such as the BigInt idea, or AI algorithms: neural networks, genetic algorithms, fuzzy systems etc.). PROGRAMMING SKILLS: Strong background in theoretical computer science, algorithms, data stuctures and optimization . Strong background in advanced mathematics. Programming Languages: C (4/5), Java (4/5), C++ (3/5), C# (3/5), Shell scripting (2/5), ASM (2/5). Other programming languages and their proficency levels are illustrated in the Resume. **PROJECT PROPOSAL** ABSTRACT The purporse of this project is to create a library that involves heap and queue creation and manipulation. This will be very useful in implementing more complex algorithms or data structures that take advantage of these structures (a basic example is Dijkstra's shortest path algorithm). The library will include basic implementations of heap structures (i.e. binary heap) and queues, as well as the more complex (and more relevant) structures. PROJECT CONTENTS The current version of the Libraries has little support for heaps and queues. Therefore, the following will be implemented, with a discussion on every structure's difficulty, speed and memory used. Firstly, a well-known table of complexities for the binary min(max)-heap: findMin(findMax) : O(1) | deleteMin(deleteMax) : O(log N) | insert : O(log N) | merge : O(N) * D-ARY HEAP : a more general implementation of the binary heap (2-ary heap). The main advantage a d-ary heap has is that insertion will be significantly faster, requiring a theoretical O(log_d N) operations. However, finding an element's parent is rather difficult if d is not a power of 2, since we can not use bitwise shifting operations. However, delete-min is slower, because of the d-1 comparisons to find the minimum value, using a standard algorithm (probable fix: use a min-heap). * BINOMIAL HEAP, BINOMIAL TREES : a mergeable heap; although the complexity for findMin(findMax) is O(log N), this heap, along with the ones below (also mergeable), offer a better complexity for merge : O(log N). Since binomial heaps use binomial trees, this data structure will also be implemented. * FIBONACCI HEAP : another mergeable heap, with better amortized time complexity than the binomial heap * RELAXED HEAP, RELAXED FIBONACCI HEAP (an idea at: http://www.google.ro/url?sa=t&source=web&ct=res&cd=1&ved=0CAYQFjAA&url=http…) * SKEW HEAP : a structure that is easier to merge than a binary heap, but is unbalanced. This could be considered optional, as it is a median option between d-ary heaps and mergeable heaps (binomial, fibonacci). * TREAP : although treaps are already implemented, they should be adapted to use the new heap library. * QUEUE : a basic implementation of the queue structure (possibly use the STL container) * DEQUEUE : although an implementation already exists /fusion/container, that has to be documented. A new implementation using the generic queue structure mentioned above. * PRIORITY QUEUE : implemented with the use of a heap. * BUFFER (CIRCULAR QUEUE) : fixed size, circular queue (if queue is full, the oldest data is overwritten). Such a queue could be used to implement a structure similar to RRDs. * (BONUS) SKIPLISTS : randomized search structure. * (BONUS) B-TREES : extended binary trees with excellent complexity when comparisons are not the most time-consuming operations. * (BONUS) INTERVAL TREES : extended complete binary trees supporting fast segment intersection queries. Some of these structures can use a fixed size array (use /boost/array). However, it would be good to eliminate the constraints of fixed size arrays. This will require using STL's <vector> or, should it be decided not to include a binary, a local implementation of it, i.e. ARRAY LIST. TIMELINE As stated above, I would like to start with an advance of one week (May 17). WEEKS -2, -1, 0 (April 26 - May 16) : Community Bonding Period These three weeks will offer me the possibility to accomodate with the code, the coding conventions and the community. During these 3 weeks, I will also discuss with the organization whether binary libraries should be included or proprietary structures should be implemented (variable sized arrays, basic queue, basic priority queue (heap)). Modifications in the timeline (reordering, additions, deletions) can also occur. Finally, I will decide if I clean up the implementations from /pending (i.e. queue, fibonacci_heap, relaxed_heap, etc.) or create new structures, based on the newly implemented structures. Implement some simple structures so as to better get used to the code (probably ARRAY LIST or BINARY HEAP). WEEK 1 (May 17 - May 23) : Implement D-ARY HEAP, BINARY HEAP (2-ARY HEAP). Decide whether to first implement the d-ary heap and then the binary heap as a particular case, or implement the binary heap first, and after that the d-ary heap, associating a binary min(max)-heap to each array of children; solve the excess memory. WEEKS 2, 3 (May 24 - June 6) : Implement BINOMIAL TREES, BINOMIAL HEAPS, FIBONACCI HEAPS (don't adapt, usage for relaxed fibonacci heaps), RELAXED HEAPS and RELAXED FIBONACCI HEAPS. Official start of the coding phase. All of these heaps follow the same basic ideas, therefore progress should be relatively easier after the binomial heaps are implemented. Initial algorithms will probably be those specified (and variations) in Cormen or Knuth, as well as the idea suggested in the above mentioned link. WEEKS 4, 5 (June 7 - June 20) : University Exams WEEKS 6, 7 (June 21 - July 4) : Fix any problems with previous heaps. Implement SKEW HEAPS. Adapt TREAPS. WEEKS 8, 9 (July 5 - July 18/16) : Add mutable behaviour to the heaps. Apply optimizations. Create some automated tests. Week 8 will mark the mid-term evaluation deadline. The objective is to complete HEAP structures. The timeline offers roughly 2 weeks for bug fixing, so that should be enough. WEEK 10 (July 19 - July 25) : Implement QUEUE, DEQUEUE. WEEK 11 (July 26 - August 1) : Implement CIRCULAR QUEUE, PRIORITY QUEUE. WEEK 12 (August 2 - August 8) : Fix bugs related to the QUEUE structures. Add mutable behaviour to the queues. Apply optimizations and custom algorithms for fixed-length data types. Create automated tests. WEEK 13 (August 9 - August 16): Finalize code and documentation. NOTES: 1. The Exams period is, actually, 4 weeks (June 7 - July 5), comprising 5 exams. However, I should be able to compress the total time to only 2 weeks by moving some of my studying in May. 2. Weeks 6 and 8 are reserved for fixing heap bugs. Should there be less problems than expected, I can gain one bonus week. 3. If we choose to implement the structures using STL binaries, I could gain one more bonus week from weeks 1, 10 and 11. 4. With (2) and (3) in mind, I could implement any of the bonuses written above (at the end, if everything else is complete). a) SKIPLISTS : a randomized search structure with very good practical complexity. b) INTERVAL TREES : given the already implemented Interval structure (/numeric/interval), it would be nice to have such a structure, for easy geometric intersection queries. c) B-TREES : adaptation of the Balanced Binary Trees, typically used in situations where the comparison operation is not the most time consuming one (disk seeking). WORK FLOW I plan to organize my time and coding in such a manner that I am able to post changes on a forum / blog every 4 days (except the period with exams). That means roughly 2 times per week, as I will have no problem working in weekends. TODO Cheers, -- Alexandru Damian Polytechnic University of Bucharest Faculty of Automatic Control and Computers

2 1

boost.graph
by Piyush Garg 06 Apr '10

06 Apr '10

What is the best representation of graph in memory that is compatible with other libraries used in the boost? Can we implement connectives in any way?

2 1

[mpl] is_macro_called
by Lorenzo Caminiti 06 Apr '10

06 Apr '10

Hello all: Is there a way I can check at compile-time and class-scope if a macro has been called and expanded (at least one time) from within a member function? For example: #define X(...) ... // Some macro definition -- the macro parameters could be anything needed to implement is_macro_called. struct is_macro_X_called { ... }; // Some implementation -- this could be a template or something else. So that: struct z { void f() { X(...); // Macro called from within a member function. } // Detect at class-scope and a compile-time that the macro was called. static const bool is_macro_X_called::value; // Evaluates to true. }; Instead: struct z { void f() { // X(...); // Macro not called. } static const bool is_macro_X_called::value; // Evaluates to false. }; I do not know how to program this. However, could for example the macro X() instantiate a template with some special template parameter that can then be inspected at compile-time by a is_macro_called metafunction? Thank you very much. Lorenzo

4 8

[Boost.process] GSoc proposal
by Kasra 05 Apr '10

05 Apr '10

Hi, I have decided to polish up the current boost.process this summer. It has been on the list far too many times without much further progress. After checking out the code I've begun working, so I need to start working on the new API which I intend to be similar to boost.thread. Are there any volunteering mentors? class process { class id; class status; class priority; typedef std::bitset<?> affinity_type; static process& this_process(); static std::vector<process> processes(); static std::vector<process> processes(const std::string& machine); static std::vector<process> processes_by_name(const std::string& name); static std::vector<process> processes_by_name(const std::string& name, const std::string& machine_name); static process start(const std::string& proc); static process start(const std::string& proc, const std::string& params); const id& get_id() const throw(); void terminate(bool kill = false ); status wait(); status idle_wait(); const boost::posix_time::ptime& start_time() const; affinity_type processor_affinity() const throw(); void processor_affinity(const affinity_type& affinity); const priority& priority() const throw(); void priority(const priority& new_priority) const throw(); postream& standard_input() const; pistream& standard_output() const; pistream& standard_error() const; boost::posix_time::time_duration kernel_time() const; boost::posix_time::time_duration user_time() const; boost::posix_time::time_duration total_time() const; const void* max_working_set() const; void max_working_set(const void* value); const void* min_working_set() const; void min_working_set(const void* value); uintmax_t peak_paged_memory() const; uintmax_t peak_private_memory() const; uintmax_t peak_virtual_memory() const; uintmax_t peak_working_memory() const; uintmax_t paged_system_memory() const; uintmax_t paged_memory() const; uintmax_t private_memory() const; uintmax_t virtual_memory() const; uintmax_t working_memory() const; }; With Best Regards Mr. Kasra Nassiri Department of Computer Science Imperial College London

3 2

Re: [boost] python/test/Jamfile.v2 help needed
by Ralf W. Grosse-Kunstleve 05 Apr '10

05 Apr '10

I think I figured it out: I moved the new "rule" block up in Jamefile.v2 . Now monitoring the build summaries again... Ralf ----- Original Message ---- From: Ralf W. Grosse-Kunstleve <rwgk(a)yahoo.com> To: boost(a)lists.boost.org Sent: Mon, April 5, 2010 1:05:20 PM Subject: Re: [boost] python/test/Jamfile.v2 help needed The recent build summaries for boost.python come up all blank. I'm guessing this is a bad sign. Are the log files somewhere from which I could tell what's wrong? Given boost svn trunk, I found out I can run bootstrap.sh to get a bjam executable. But I couldn't figure out how to build and run the python tests. Could some help with the commands I need? I have Fedora 6, 8, 11, 12. Ralf ----- Original Message ---- From: Vladimir Prus <ghost(a)cs.msu.su> To: boost(a)lists.boost.org Sent: Sat, April 3, 2010 11:21:04 PM Subject: Re: [boost] python/test/Jamfile.v2 help needed Ralf W. Grosse-Kunstleve wrote: > I've merged the current boost/python and libs/python trunk into the release branch, > followed by this patch: > > Index: libs/python/test/Jamfile.v2 > =================================================================== > --- libs/python/test/Jamfile.v2 (revision 61033) > +++ libs/python/test/Jamfile.v2 (working copy) > @@ -184,8 +184,10 @@ > # bpl-test bienstman5 ; > # } > > -[ bpl-test calling_conventions ] > -[ bpl-test calling_conventions_mf ] > +# XXX disabled on release branch only, > +# XXX to avoid failures on platforms other than Windows > +# [ bpl-test calling_conventions ] > +# [ bpl-test calling_conventions_mf ] > > # --- unit tests of library components --- > > > Is it possible to have those two tests built and run only under Windows? Yes. Create a function as follows (in your Jamfile): rule require-windows ( properties * ) { if ! <target-os>windows in $(properties) { return <build>no ; } } then, in requirements of your tests, use <conditional>@require-windows, e.g: [ bpl-test calling_conventions : : <condiitonal>@require-windows ] Note that cygwin is a different OS from windows, so if the test must be run on cygwin, you need to adjust conditional accordingly. Does this help? - Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] [msm] new version available
by Christophe Henry 05 Apr '10

05 Apr '10

>>> Hi, >>> >>> Just a form remark. We use to see the code highlighted. Have you the possibility to highligth the code? >>> >>> Best, >>> Vicente >>> >> >> Probably. I just need to find out if there is another DocBook tag for >> this. At the moment, I'm using <code>. >> I'm not a BocBook expert, but if one reads this, please help ;-) > > I have never used DocBook but I have found that http://www.sagehill.net/docbookxsl/SyntaxHighlighting.html. > > There are some uses of <programlisting> already in Boost.Function. > > Hoping this helps > Vicente Oh yes it does. And it looks much better, you're right. Great! Then it'll be done fast. Thanks a lot, Christophe

1 0

[Log] Problem with attributes + gcc -fvisibility=hidden
by Tony Astolfi 05 Apr '10

05 Apr '10

I'm evaluating boost::log for use in a project I'm working on, and I found a potential issue. If I compile my program using gcc with the '-fvisibility=hidden' option enabled, then some log event attributes don't show up in the output. For example: #include <boost/log/attributes/clock.hpp> #include <boost/log/common.hpp> #include <boost/log/utility/init/to_console.hpp> int main () { boost::log::init_log_to_console( std::cout, boost::log::keywords::format = "[%TimeStamp%] %_%" ); boost::log::core::get()->add_global_attribute( "TimeStamp", boost::make_shared< boost::log::attributes::local_clock >() ); boost::log::sources::logger l; BOOST_LOG( l ) << "Error!"; return 0; } Output: % g++ main.cpp -I../../../glnxa64/include -L../../../glnxa64/lib -lboost_log -lboost_system -lboost_log_setup && ./a.out [2010-Apr-05 12:39:14.872961] Error! % g++ main.cpp -I../../../glnxa64/include -L../../../glnxa64/lib -lboost_log -lboost_system -lboost_log_setup -fvisibility=hidden && ./a.out [] Error! I've found issues like this in the past caused by boost libraries not marking certain types as export-visibility, resulting in a failure later on to match two type-id objects that ought to be identical. Could something like this be happening in the recently accepted Boost.Log library? Is this something the author would be interested in fixing/supporting?

1 0

Re: [boost] [msm] new version available
by Christophe Henry 05 Apr '10

05 Apr '10

> Hi, > > Just a form remark. We use to see the code highlighted. Have you the possibility to highligth the code? > > Best, > Vicente > Probably. I just need to find out if there is another DocBook tag for this. At the moment, I'm using <code>. I'm not a BocBook expert, but if one reads this, please help ;-) Christophe

2 1

[test] How to have a simple unit test compile on Borland/CodeGear?
by Niels Dekker - address until 2010-10-10 05 Apr '10

05 Apr '10

Is the following still a proper way to write a unit test for a Boost library component? #define BOOST_INCLUDE_MAIN #include <boost/test/test_tools.hpp> int test_main(int, char*[]) { // TODO Some testing here... return 0; } I can't get the above code compiling on the latest Borland/CodeGear compiler (Embarcadero C++ 6.21), installed by c++builder_2010_3615_win_esd.zip, downloaded from www.embarcadero.com/downloads Even though I already patched boost/smart_ptr (ticket #4067) and boost/exception (ticket #4068). I just do: bjam toolset=borland Which tries to compile <boost/test/utils/runtime/cla/dual_name_parameter.hpp> apparently, and it yields an error at line 43: template<typename Modifier> void accept_modifier( Modifier const& m ) { if( m.has( prefix ) ) { set_prefix( m[prefix] ); // line 43, "Error E2094"! ... The complete error message is down here. Interestingly, the message says that operator+ is missing (while I don't see a need for operator+ in this context). Any help is appreciated! Kind regards, Niels ------------------------------------------------------------ CodeGear/Embarcadero C++ 6.21 output: Error E2094 ..\..\..\..\boost/test/utils/runtime/cla/dual_name_parameter.hpp 43: 'operator+' not implemented in type 'nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<const unit_test::const_string,description_t,const unit_test::const_string &>,nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<bool,optional_t,bool>,nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<bool,guess_name_t,bool>,nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<const unit_test::const_string,separator_t,const unit_test::const_string &>,nfp::named_parameter<const unit_test::const_string,prefix_t,const unit_test::const_string &> > > > >' for arguments of type 'nfp::typed_keyword<unit_test::const_string,prefix_t,0>' in function void dual_name_policy::accept_modifier<nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<const unit_test::const_string,description_t,const unit_test::const_string &>,nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<bool,optional_t,bool>,nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<bool,guess_name_t,bool>,nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<const unit_test::const_string,separator_t,const unit_test::const_string &>,nfp::named_parameter<const unit_test::const_string,prefix_t,const unit_test::const_string &> > > > > >(const nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<const unit_test::const_string,description_t,const unit_test::const_string &>,nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<bool,optional_t,bool>,nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<bool,guess_name_t,bool>,nfp::nfp_detail::named_parameter_combine<nfp::named_parameter<const unit_test::const_string,separator_t,const unit_test::const_string &>,nfp::named_parameter<const unit_test::const_string,prefix_t,const unit_test::const_string &> > > > > &)

1 0

[cpp0x] Macro to support some C++0x syntax and functionality
by Lorenzo Caminiti 05 Apr '10

05 Apr '10

Hello all, Consider the following C++0x-like example (inspired by ConceptC++ http://www.generic-programming.org/languages/conceptcpp/tutorial/ and C++ Contract Programming proposal n1962): // Example strangely uses pointers instead of iterators just to have preconditions. template<std::CopyConstructible T> requires Addable<T>, Assignable<T> // Concepts. precondition { first; last; } // Pointers not null. postcondition (total) { total == result; } // Returning result. T sum(T* first, T* last, T result) { for (; first != last; ++first) result = result + *first; return result; } What do you think of the following macro that implementes this in ISO standard C++ while keeping the above C++0x-like syntax by wrapping it within a preprocessor sequence? BOOST_CPP0X_FUNCTION( (template)( (std::CopyConstructible)(T) ) (requires)( (Addable<T>) (Assignable<T>) ) (precondition)( (first) (last) ) (postcondition)(total)( (total == result) ) (T) (sum)( (T*)(first) (T*)(last) (T)(result) ) ({ for (; first != last; ++first) result = result + *first; return result; }) ) The idea is that using the preprocessor I can parse the specified signature-sequence so I have all the tokens I need to declare/define the C++ function plus I can add the concepts (Boost.Concept), contracts (Boost.Contract), named parameters (Boost.Parameter), etc. Furthermore, the syntax of signature-sequence can be any valid preprocessor sequence that uses words (but not symbols) for keywords -- e.g., (requires) and (preconditions) are OK but (=) is not. This way I can define the signature-sequence syntax to closely match the syntax of C++0x (for concepts) and of other C++ standard proposals (like n1962 for contracts). DISCLAIMER: I think this is possible but I would need to try to implement it in order to be 100% sure and to identify possible limitations. Regards, Lorenzo P.S. I started considering this in reference to a previous email thread "Re: [boost] [contract] Contract Programming Library": On Sat, Feb 13, 2010 at 9:44 AM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> wrote: > On Fri, Feb 12, 2010 at 3:39 AM, Andrzej Krzemienski <akrzemi1(a)gmail.com> wrote: >> I would be very interested in trying such a library. I have one >> it is inevitable, etc., but.. read on. I know at least one library in >> Boost that also spoils function declarations in order to provide >> additional functionality: Concept Check library; they may be others >> too (MPL?). >> My suggestion is that if there are (or will be) libraries that require >> spoiling function declarations, they should all provide the same >> "spoiled" syntax. Otherwise I will be always asking "how do I declare >> a function in this library?". It would be very convenient if Boost >> provided one alternative function definition syntax that when used >> would enable all its libraries to work. > I agree. However, in the past I did look into harmonizing my library > API with the ones of Boost.ConceptCheck and/or Boost.Parameter but it > did not seem feasible... I will double check it.

2 1

[google summer of code] student
by Cezary Bartoszuk 05 Apr '10

05 Apr '10

Hello, I am a CS student and I would like to patricipate in developing Heaps & Queues in Boost during Google Summer Of Code '10. Where, besides the source code, should I search for information about what's already in Boost (in the meaning of heaps/queues)? Who should I talk to about participating in Boost? Best regards, Cezary Bartoszuk, --- Faculty of Mathematics Informatics and Mechanics, University of Warsaw, Poland

3 4

Interested in Boost.Graph
by Piyush Garg 05 Apr '10

05 Apr '10

hi I am interested in upgrading the boost graph library to parallel boost graph library. I want to ask that do i have to chose one of the projects in boost.graph or i have to make them all during summer. Can i make the project on that or i have to suggest my own idea? Thanks Piyush Garg.

3 7

[GSoC] data structures library for summer of code 2010
by Dan Fox 05 Apr '10

05 Apr '10

Hi everyone, My name is Daniel Fox. I'm interested in working on making the advanced data structures library project idea for this year's Google Summer of Code. I've spent some time looking at the current structures in boost/pending and I believe I have an idea of what I would like to do for it.

1 0

[string_algo] first_finderF hoist empty check out of loop
by Jeff Flinn 04 Apr '10

04 Apr '10

In trying to get string algorithm icontains to work with spirit's file_iterator (which I still haven't been successful with) I noticed that the check for an empty search string is in side the loop. As: // Outer loop for(input_iterator_type OuterIt=Begin; OuterIt!=End; ++OuterIt) { // Sanity check if( boost::empty(m_Search) ) return result_type( End, End ); Wouldn't it be better to hoist this check out of the loop and only do it once? Thanks, Jeff

2 1

Semantic graphs for GSOC 2010
by Alexander Golec 03 Apr '10

03 Apr '10

Hey all, My name is Alexander Golec, and I'm a student at Fordham University studying mathematics, transferring to Columbia University to study CS engineering. I would like to ask about some specifics of the heaps and queues project. Have the items to be added to the advanced data structures library already been decided? How are the structures coupled to the BGL? Also, I would like to implement the binomial heap structure. Would anyone have any pointers for getting to know Boost's internals? Thanks, Alex

2 1

GSOC Bigint Proposal.
by swagat konchada 03 Apr '10

03 Apr '10

I would like to receive comments on my proposal for Bigint this year. To design, implement, test and document an expression template system("a wrapper for swappable Bigint providers") for the Boost.bigint around NTL, GMP(Is there enough interest around Xint?) in view of the numeric_adaptor scheme developed by Barend Gehrels in providing as many possible operators as possible. My mid-term examinations are going on and It's being impossible for me to hang around the list and study about Xint. I hope you understand... :)() -- Problem is a phenomenon indicating lack of thought. Swagat Konchada

2 1

GSoC: Enforcing Code Feature Requirements
by vicente.botet 03 Apr '10

03 Apr '10

Hi, I have recently reread the article "Enforcing Code Feature Requirements in C++" by Scott Meyers <http://www.artima.com/cppsource/codefeaturesP.html> I have posted some ideas that could improve the design (<http://www.artima.com/forums/flat.jsp?forum=226&thread=238798&start=0#372622>) I wanted to know if this could be a good subject for GSoC, if the approach I purpose to solve some issues is acceptable and if there is some students interested. Of course any comments are welcome. Best, _____________________ Vicente Juan Botet Escribá

7 14

Re: [boost] [range] Permission to merge to the Release branch
by Beman Dawes 03 Apr '10

03 Apr '10

On Fri, Apr 2, 2010 at 12:27 PM, Neil Groves <neil(a)grovescomputing.com> wrote: > Beman, > > I am seeking permission to merge the trunk version of Boost.Range into the > release branch. The regression test results have not detected new > regressions, however there are a number of the new features that are not > passing unit tests on several compilers. Since the new features would not be > usable if I did not merge my opinion is that it is worth merging to allow > the use of the newer features on more compliant compilers. In the meantime I > can seek to improve the support of adaptors and algorithms on the less > capable compilers. Go ahead and merge. For the tests that are expected to fail (because of older compilers, or whatever), please mark them up as expected failures. Ask if you need help with the markup. > > Of course, I respect that being a newbie to the Boost development and > release process that I may not be making the most informed judgement and > hence I respectfully seek your guidance. It is best to ask such questions on the main list. That allows others to comment, and if I'm not available one of the other release managers can reply. Thanks, --Beman

3 2

Graph class, an idea
by Alexander Golec 03 Apr '10

03 Apr '10

Hey all, I have recently been working on a project that has led me to some interesting ideas for a graph class. Chief among them is the structure of the cycle matrix. This is a matrix representing the fundamental cycles of a graph. With this matrix, one can easily determine if, given an arbitrary set of vertices, if there is a cycle that passes through all of them. Whats more, it can easily provide that cycle if it exists. I'd like to ask if this sounds like something that would be useful in Boost's Graph class. Thanks, Alex

2 1

Re: [boost] [GSoC 2010]: BGL Graph Connectives ideas
by Yaroslav Vorontsov 03 Apr '10

03 Apr '10

>> > I have some ideas about implementing graph connectives. I think that the >> > best way to implement first four binary operations (union, join, >> > intersection and difference) is to use adjacency matrices. >> > >> > I think variants of these algorithms for non-adjacency matrices are just as > important. It would be best to focus on these problems and their generic > solution than to propose more solutions for a smaller set of graphs. > OK, let it be so. The implementation of graph connectives using the adjacency matrices isn't too difficult. Regarding adjacency lists or incidency matrices, it's more difficult and intererestring to perform such operations. I meant that it's more convenient to do the operations for adjacency matrices and then to convert them into another graph representation, but now I doubt that this will be more effective (it needs some time to convert a graph from one representation to another (and a lot of memory), and the algorithm needs time and memory, too).

1 0

Re: [boost] Boost Digest, Vol 2869, Issue 5
by Yaroslav Vorontsov 03 Apr '10

03 Apr '10

>> > I have some ideas about implementing graph connectives. I think that the >> > best way to implement first four binary operations (union, join, >> > intersection and difference) is to use adjacency matrices. >> > >> > I think variants of these algorithms for non-adjacency matrices are just as > important. It would be best to focus on these problems and their generic > solution than to propose more solutions for a smaller set of graphs. > OK, let it be so. The implementation of graph connectives using the adjacency matrices isn't too difficult. Regarding adjacency lists or incidency matrices, it's more difficult and intererestring to perform such operations. I meant that it's more convenient to do the operations for adjacency matrices and then to convert them into another graph representation, but now I doubt that this will be more effective (it needs some time to convert a graph from one representation to another (and a lot of memory), and the algorithm needs time and memory, too).

1 0

A Pimpl variant
by vicente.botet 03 Apr '10

03 Apr '10

Hi, I don't know if this is the correct ML to talk about this subject, but as there was recently a discussion about wether Boost should or not use Pimpl, I have decided to post this here. In http://www.gotw.ca/publications/mill05.htm H. Sutter states "There are four main alternative disciplines: 1. Put all private data (but not functions) into XImpl. 2. Put all private members into XImpl. 3. Put all private and protected members into XImpl. 4. Make XImpl entirely the class that X would have been, and write X as only the public interface made up entirely of simple forwarding functions (another handle/body variant)." My experience is that I add more private member functions than private member data. I have explored a different variant 5. Put all private funtion and static data (but not instance data) into XImpl. XImpl needs only to store the back pointer. While this approach doesn't encapsulates all the private members has some advantages: * The XImpl class has no inherent instance data, so no space overhead * The class doesn't needs to store any XImpl pointer as there is no data to maintain, so no need to allocate/deallocate it. * Reduce the performance overhead of the Pimpl idiom. The drawbacks are: * Need to include the headers needed for the private instance data. * There is yet a minimal performance overhead on the construction of the temporary XImpl class and the derreference of the back pointer. Next follows an implementation exaple. * Grant friend access to the private implementation class class C { public: void f(); void g(); protected: // ... private: struct impl; friend struct impl; // the private part contains only instance data and virtual functions int priv; }; * Identify the private functions and the private static data and put them on the implementation class struct C::impl { C::impl(C* thisC) : that(*thisC) {} void ifct() { that.priv = ... // use of private data that.g(); // call to a public function jfct(); // call another private function } C& that; static int icount; }; * Prefix all the ex private function calls by impl(this) impl(this).ifct(); * Access without constraints the impl static data impl::icount; There is a proposal from Francis Glassborow, N1742: Auxiliary class interfaces:<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1742.pdf> that address this problem in a general context. What do you think of this variant? Best, _____________________ Vicente Juan Botet Escribá

6 11

[lambda] [result_of] Lambda enhancements
by Adam Butcher 03 Apr '10

03 Apr '10

Hi Perhaps this would have been better as two separate mails but since it is all lambda related I have included it as one (despite one patch actually being to the result_of library). [lambda] I discovered recently that member-function-ptrs wrapped in boost::lambda objects do not apply directly if the subject is held in a smart-ptr (unless that smart-ptr has an implicit conversion to T*). There are a number of places in our code base where we have worked around this by using something like *free1 rather than simply free1 which ends up calling the 'apply member-function to object-by-reference' adaptor. This works providing the smart-ptr defines a type 'element_type' to be the underlying object type (as shared_ptr et al do). It does not work for third-party smart-ptrs that do not define this type. It struck me that since boost.bind uses boost.mem_fn's get_pointer template to handle this use case it would be reasonable to add an overload of 'apply' to lambda/detail/function_adaptors.hpp that deferred to that. I knocked up a perl script which adds the necessary overloads to each specialization in function_adaptors which I have attached (I have also attached the resulting diff). It may be that this yields some unpleasant side-effects that I haven't thought of or observed but so far it seems to work okay with our code base. The get_pointer overload is disabled if the argument is convertible to ref-to-const-object-type (e.g. if it is a derived type) since then the reference overload should be used. I would appreciate any feedback on the idea and implementation. [result_of] Whilst implementing a front-end template for a set of functions that accept boost.function objects with various return types, I discovered that boost.result_of does not implement support for the nested sig<tuple> template used by boost.lambda objects. My intent was to accept any user-supplied function at the front-end and, based on the given function's return type when applied to a specific set of arguments, forward to the appropriate implementation. This determination currently fails if the user supplies a lambda object. The attached result_of patch adds detection of the nested sig template in order to support determining the return type of lambda functions (providing the necessary arguments are given). This is done in a non-intrusive way; i.e. there is no physical dependency on boost.lambda or boost.tuple, though the boost.tuple classes 'cons' and 'null_type' are forward declared. Since they are only ever instantiated when a boost.lambda object is provided (which will have already brought in their definitions) I think it should be okay. In order to provide the sig template with its required tuple, a facility has been added (with implementation generated by some additional preprocessor code) that converts from function-type to tuple (i.e. F(A,B...) -> cons<F,cons<A, cons<B,...null_type>>>). Since only the type declarations are required this can be done without pulling in any tuple headers. One thing I am a little concerned about is that the determination mechanism for the existence of the sig template is probably not very portable (I have only tried it on GCC 4 and VC9). Is there an MPL/type_traits predicate generator for portable nested template detection? I am aware of BOOST_MPL_HAS_XXX_TRAIT_(NAMED_)DEF but I couldn't see any generator around that area that would do nested template detection. We have such a facility in our code base but it will have only been tried on GCC 4 and VC9 (maybe also VC7.1). Again I would appreciate any feedback on these diffs and whether or not they are suitable for inclusion into the respective libraries. Regards, Adam

4 4

Review results missing for boost.log
by Michael Caisse 03 Apr '10

03 Apr '10

In an attempt to reduce the FUD on IRC I pointed people to the review schedule page to find results on the Boost Log review. To my sheepish chagrin the results are not in the table. Not sure who has permissions to update the table. The following link is Volodya's posted review results. http://article.gmane.org/gmane.comp.lib.boost.devel/201541 thanks - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

1 0

[GSoC] Heaps & Queues (draft proposal)
by iaml 02 Apr '10

02 Apr '10

Hi everyone. I am Lintao from Sun Yat-sen University, China. This is my first time to send mail on mailing list. I'm a little nervous:-). I am interested in Heaps & Queues provided by Boost in 2010 GSoC. And I have finished my draft proposal after viewing the mailing list these days. Thank you for your comments and suggestions. ====== project proposal ====== In my opinion, most of work is to reuse and rearrange the existing data structure in boost/pending and other data structures which have already existed.[1] The most important thing I should consider is the APIs design of the new library. So for each data structure, it should not only agree to the formulation provided by the BGL, but also should be easy to remember and user-friendly. Besides, I would like to add d-ary heap and splay heap into the new library. Because d-ary heap is a variation of binary heap and has faster running time. As for splay heap, it has the attractive property that recently accessed elements are quick to access again. I think it will be very useful in application software programming. If time permits, I want to add others implementations of heap [2] into the new library. Below is my design to the library APIs. template <class T, class Compare = std::less<T>> class heap{ public: * void insert(T& key);* * void delete(T* key);* * void update(T* t, T& new_key);* T* getRoot(); T* find(T& key); bool empty() const; size_type size() const; void print() const; private: void print_recur() const; protected: T* _root; }; NOTICE: * operations in bold mean it should be implement by the subclass. * operations print and print_recur is optional. But I prefer to include them because it'll be helpful when debugging the programs using this library. The class mentioned above is the base class for all the heap structures in the new library. The classes such as Fibonacci heap, relaxed heap, binomial heap and splay heap should inherit from this abstract class and add additional operations if needed. And I would prefer to use lists rather than vectors (as shown in boost/pending/fibonacci_heap.hpp) to implement it for three reasons. 1. It will save memory since the later needs extra space to store the key to value mapping. 2. Vector requires continuous memory while list doesn’t. It does not matter when the amount of data is small. But when the amount of data becomes large, it will be a tough problem; 3. It takes time to resize and reallocate the memory for vectors. Of course, list implementation has its own drawback such as easy to leak memory and cost more time when searching the heap. From my point of view, it is acceptable comparing with the problems mentioned before. As the adaptor of heaps, the priority queue API may like: template<class T, class Compare = std::less<T>, class Container = fibonacci_heap<T, Compare>> class priority_queue{ public: void push(T& key); T pop(); const T& front() const; T& front(); T* find(T& key); void update(T* t, T& new_key); bool empty() const; size_type size() const; void print() const; private: void print_recur() const; }; [1][2] It means the data structure in this URL: https://svn.boost.org/svn/boost/sandbox/libs/pri_queue/ Thank you for reading.

3 3

[GSoC 2010]: BGL Graph Connectives ideas
by Yaroslav Vorontsov 02 Apr '10

02 Apr '10

> > I'm Yaroslav Vorontsov (or simply Jerry Lee :-)), a student of Computer > > Science Department of Voronezh State University, Russia. I'm interested in > > both generic programming and graph theory, and I also would like to > > participate in Google Summer of Code 2010. I had some experience of generic > > programming before when I tried to implement my own generic graph library in > > C# (of course, as a task on one of programming courses at the university). > > I've read that (quote) "The Boost.Graph library is missing connectives...". > > I'm quite familiar with C++ and the idea of generic programming and I'm > > working with some graph theory aspects at the moment, so I want to know: > > what particular skills (in programming, of course) are needed to develop > > graph connectives? > > > > Hi Simply Jerry Lee:), > > Good question. Working on the Boost graph library requires a sound > understanding of its organization and its construction. There are a lot of > techniques used in its construction that are atypical of most OO libraries > (even C# generic data structures). You should be able to identify aspects of > an algorithm that aren't "universally generic" and understand how to > abstract them using templates, types, metaprogramming, etc. > > Most of that can be learned on the job, so to speak, but having a good eye > for abstraction certainly helps. > > Andrew Sutton > andrew.n.sutton(a)gmail.com > > Mr Sutton, Many thanks for your exhaustive explanation! :-) I have some ideas about implementing graph connectives. I think that the best way to implement first four binary operations (union, join, intersection and difference) is to use adjacency matrices. Also I'd like to add an operation which wasn't mentioned in the task proposal. It's ring sum of two graphs. Here is a short description: let A(Va,Ea) and B(Vb,Eb) be two graphs, where Va and Vb are sets of vertices of these graphs and Ea and Eb are sets of edges. The ring sum of A and B is a new graph C=A(+)B which has no isolated vertices and which has edges included only in Ea or in Eb (but not in both sets). It's something like symmetric difference between two sets in the set theory. As for unary operations, adjacency matrices may be useful in the implementation of graph closure, removal of edge and shrinkage of graph. Yaroslav Vorontsov DarthYarius_0990(a)mail.ru

2 1

use case of [move] rvalue reference emulation
by DE 02 Apr '10

02 Apr '10

hi all once i needed to pass around an object of a reference-like type i.e. a class with reference semantics something as trivial as template<typename type> struct ref { typedef typename type::value_type value_type; type &reference; const size_t index; ref(ref &a) : reference(a.reference), index(a.index) {} ref(type &a, size_t i) : reference(a), index(i) {} ref &operator=(const value_type &a) { /*setting value, e.g. 'reference.set(index, a)'*/ return *this; } operator value_type() const {/*return appropriate value, e.g. 'reference.at(index)'*/} }; so an access function returned an object of that ref type by value and no function wanted to take it because eventually a rvalue could not be bound to a non-const reference then an idea of using a rvalue emulation proposed by boost move library came in my mind although it's not a move constructor it allows to construct objects of type 'ref' from rvalues: ref(rv_ref<ref> &a) : reference(a.reference), index(a.index) {} and also a conversion to rv_ref sholud be added: operator rv_ref<ref>&() { return *static_cast<rv_ref<ref>*>(this); } see fully working code example at http://codepad.org/rRM93AFo defining a reference type "rvalue copy assignable" makes it behave almost the same as ordinary c++ references also constness is preserved perfectly and it happend so that all limitations of the emulation only strengthen the design of such reference types (e.g. unavailability of 'type(const type&)' constructor) an example of the application of such reference types may be an advanced map class when you subscript an stl map object like map[key]; a record with the 'key' is created in the map if it's not there already so not to overpopulate our map we write something like value_type value; if (map.is_there(key)) value = map[key]; of course there is no such 'is_there()' member function in an stl map i'm just trying to make my intention clear so were that smart reference typedefed in the map like template</*...*/> class map { public: //... typedef map_ref<map> reference; //... }; it could have slightly better semantics: map[key]; //always does nothing map[key] = new_value; //if there is no record with 'key' -> creates it //assignes 'new_value' to the value of the record value = map[key]; //retrieves a value associated to 'key' in the last case if there is no such record in the map it may return an invalid value or throw an exception anyway i consider this semantics more natural than that of the current std::map not to mention that you may pass a reference to a function: void foo(map::reference a) { a = "42"; } //if there was no record -> creates it //... foo(map[key]); //does not create record at this point and it will work flawlessly -- Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out

1 1

[contract] Released Contract Programming Library on SourceForge
by Lorenzo Caminiti 02 Apr '10

02 Apr '10

Hi all, I have released on SourceForge a library that implements Contract Programming (a.k.a. Design by Contract(TM) ) for C++. I am considering to submit this library to Boost (as Boost.Contract). Contract++ Library * Download http://sourceforge.net/projects/dbcpp/ * Documentation http://dbcpp.sourceforge.net/ * Examples http://dbcpp.sourceforge.net/contract__/examples.html Comments? Regards, Lorenzo

2 9

[mpl] has_function
by Lorenzo Caminiti 02 Apr '10

02 Apr '10

Hello all, Is there a way I can check if a class has a given member function using metaprogramming? What I need is to check at compile-time if a function is overriding a virtual function or not. In the example below, z::f is overriding x::f but not y::f (which does not exist) and the compiler knows that -- is there a way I can extract that information from the compiler? struct has_function<class Base, ... /* other parameters */ > { ... /* some implementation */ }; struct x { virtual void f() {} }; struct y { virtual void g() {} }; struct z: x, y { void f() { cout << has_function<x, &z::f>::value << endl; // print 1 cout << has_function<y, &z::f>::value << endl; // print 0 } }; (This does not compile -- I do not know how to program it so it compiles -- but it should give the idea of what I am looking for.) Thank you very much. Lorenzo

16 27

Re: [boost] [GSOC] summary of BigInt library details
by Ankit Malpani 02 Apr '10

02 Apr '10

hello all, thanks for the prompt replies. here are some issues (some carry forwarded from previous mail) which need addressing. [Scott McMurray wrote] >For example, GMP has a function mpz_addmul(x,y,z) that we would rather >write as x += y*z; > >My idea for the use of Boost.Proto is for its expression template >transformation features to rewrite the easy-to-use syntax to take >advantage of such optimized backend features. thank you, that really clarified the issue rearding basing the frotend off Boost.Proto. My question is - boost already has done work for handling big_integral [boost/mpl/math/big_integral/] (saw it in archives dating back to 2005 refer [1] ) so which backend option is more advisable:- a) use these functions based off boost/mpl/math/big_integral/. if so can someone please give a link to its documentation. or b) use a backend developed by me .(probably with the help non boost.math but standard c++ libraries) [Bruno Lalande wrote:] >So to summarize, I can see 3 distinct actions: >1) implement your BigInt backend >2) provide a Boost.Math binding compliant interface for this backend >3) implement a frontend for Boost.Math binding based on Boost.Proto thanks for summing it up so precisely :) could u please elaborate more on point 2, does it mean that the interface being provided should be similar to those provided by Boost.Math ? here is my refined project idea once again:- 1. provide the frontend which takes care of expressions like z += y*z (using Boost.Proto) 2. implement backend using :- a) an implementation developed by me (using simple standard c++ library functions). or b) using boost/mpl/math/big_integral/ . (if so please give me a link to its documentation) moreover, is there any Boost specific format to be followed for submission of the project idea? i hope the community and gsoc mentors will help me out with these queries soon. [1] http://lists.boost.org/Archives/boost/2005/10/subject.php Cheers! Ankit Malpani 3rd Year Undergraduate | BE. Hons Computer Science BITS Pilani Goa Campus

2 1

[1.43.0] Change of release schedule
by Beman Dawes 02 Apr '10

02 Apr '10

To allow a large block of weekend time for last tweaks, from now on the release schedule is going to be changed to the first Monday of the second month of each quarter. Updated calendar 1.43.0: http://www.boost.org/development/index.html General date info: http://svn.boost.org/trac/boost/wiki/ReleaseSchedule --Release managers

1 0

[range][string_algo] Conflict between algorithm names
by Jeremiah Willcock 02 Apr '10

02 Apr '10

When I try to include both Boost.Range algorithms (in the current trunk version) and Boost.Algorithm, using a file such as the following: #include <boost/algorithm/string.hpp> #include <boost/range/algorithm.hpp> I receive several errors about duplicate definitions. I am using gcc 4.1.2 on Linux. ./boost/range/algorithm/find.hpp:28: error: ‘template<class SinglePassRange, class Value> typename boost::range_iterator::type boost::find(SinglePassRange&, const Value&)’ conflicts with previous using declaration ‘template<class RangeT, class FinderT> boost::iterator_range<typename boost::range_iterator<C>::type> boost::algorithm::find(RangeT&, const FinderT&)’ ./boost/range/algorithm/lexicographical_compare.hpp:28: error: ‘template<class SinglePassRange1, class SinglePassRange2> bool boost::lexicographical_compare(const SinglePassRange1&, const SinglePassRange2&)’ conflicts with previous using declaration ‘template<class Range1T, class Range2T> bool boost::algorithm::lexicographical_compare(const Range1T&, const Range2T&)’ ./boost/range/algorithm/lexicographical_compare.hpp:42: error: ‘template<class SinglePassRange1, class SinglePassRange2, class BinaryPredicate> bool boost::lexicographical_compare(const SinglePassRange1&, const SinglePassRange2&, BinaryPredicate)’ conflicts with previous using declaration ‘template<class Range1T, class Range2T, class PredicateT> bool boost::algorithm::lexicographical_compare(const Range1T&, const Range2T&, PredicateT)’ The using declarations mentioned in the error message are in files such as boost/algorithm/string/find.hpp. Is there a workaround or easy fix for this? -- Jeremiah Willcock

5 10

[range] Merging algorithms into release branch and <boost/detail/algorithm.hpp>
by Jeremiah Willcock 02 Apr '10

02 Apr '10

The release branch's version of <boost/detail/algorithm.hpp> contains several range versions of STL algorithms that duplicate those in the new version of Boost.Range. The trunk version has removed these duplicate algorithms (in r60919), using Boost.Range instead. This note is to inform whoever merges the algorithms in Boost.Range into the release branch to merge r60919 as well to avoid duplicate function errors. -- Jeremiah Willcock

1 0

GSOC 2010 :BOOST Heaps and Queues
by shivaraaj kotini 02 Apr '10

02 Apr '10

Hi all, Im Shivaraaj, Im from Birla Institute of Technology Science (B.I.T.S) pilani, India. I recently came across GSOC 2010 and Im very interested in it.Though Im late I dont want to give up and continue discussing ideas before submitting an application. Im very much interested in BOOST Heaps and Queues project. My idea was to create a replica of JSDL api in BOOST (not completely but the useful part related to our project) and providing more features by adding 'mutable' to the objects created and there by we can do updations to existing objects. I feel we can inherit and create a lot of standard data structures apart from heaps. And within heaps we can create all different types of heaps and pull under a common interface. Thank You, Shivaraaj Kotini.

2 1

Release 1.12 of the C++ Middleware Writer on line
by Brian Wood 01 Apr '10

01 Apr '10

B"H Release 1.12 of the C++ Middleware Writer is now on line. This release fixes several bugs and adds support for the following: 1. Multiple inheritance, but we don't support virtual inheritance yet. G-d willing, we'll add that later. 2. boost::scoped_ptr, auto_ptr/unique_ptr. 3. Accounts An account is now needed to use the command line interface of the C++ Middleware Writer. When an account is created, a directory will be associated with the account. That directory is reused with each request and only the input files that have changed since your last request are transmitted. The command line interface config file, direct.cfg, refers to an Account-Number. That file has to be updated after you set up an account. Use this page -- http://webEbenezer.net/cgi-bin/account.cgi -- to set up an account. Setting up an account is currently trivial -- no questions asked -- just click the button. There's an example of the multiple inheritance and scoped_ptr support here -- http://webEbenezer.net/release/112.example . Cheers, Brian Wood http://www.webEbenezer.net (651) 251-9384

1 0

Transfer of Maintenance Rights
by Stewart, Robert 01 Apr '10

01 Apr '10

Dave asked for a policy proposal for how Boost library maintenance rights may be transferred. Edward Diener declined, so I'll offer one and go a little further while I'm at it. Consider the following as a replacement for the text at <http://www.boost.org/community/reviews.html#Maintainer>. _____________________________ Library Author's Responsibilities By submitting a library to Boost, you agree to put the library and its documentation under a Boost-compatible license, if it is accepted. If your library is accepted, you are free to change it any way you wish. Indeed, we encourage you to make constant improvements. However, because peer review is an important part of the Boost process, please consider getting Boost community feedback before making substantial changes to the interface of your library. Furthermore, if your library is accepted, you agree to be the library maintainer or to find a qualified volunteer to serve in your stead. You may, of course, assemble a qualified group to act as maintainers of your library, regardless of whether you continue to be a maintainer. Library Maintainer's Rights and Responsibilities As a library maintainer, you agree to provide timely support to users of the library, and to fix bugs and release those fixes in a timely fashion. You also agree to consider making library enhancements and improvements. Note that others may offer and even commit patches to a library you maintain, provided the patch is posted to the Boost Developer's mailing list for approval and is not rejected by anyone within a reasonable time. If you find that you can no longer fulfill your responsibilities as maintainer of a library, you are responsible to advertise this to the Boost community. If you are the sole maintainer, you are responsible to find a replacement. If for some reason you fail to fulfill your responsibilities as maintainer of a library, as judged by the Boost community, whether through willful neglect or otherwise, you agree to allow the Boost community to provide a suitable replacement. _____ Rob Stewart robert.stewart(a)sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

25 51

GSOC Proposal :
by abhijith reddy 01 Apr '10

01 Apr '10

Hello I am Abhijith Reddy a 3rd year undergrad student from India and my idea for this year's GSOC is to implement an efficient prime factorization (large numbers) class that could be integrated into the Math and numerics library of Boost. I have been working on this since 2-3 months as i am currently doing a project on it, so i already have most of the code however its written in a different language(PIKE) since it supports bigint (uses GMP). So for this project I have to implement my own mini bigint class as well. This class will be relatively smaller compared to any full fledged bigint libraries since the numbers dealt here are relatively small (less than 50 digits) and always positive, so complex algorithms used in normal bigint libraries like (karatsuba,fft based multiplication) can be avoided. So i want to know the scope of this project and any other tips/suggestions would be helpful. Thank you

1 0

GSoC: Boost.Graph library - Graph Connectives
by Yaroslav Vorontsov 01 Apr '10

01 Apr '10

Hello everyone! I'm Yaroslav Vorontsov (or simply Jerry Lee :-)), a student of Computer Science Department of Voronezh State University, Russia. I'm interested in both generic programming and graph theory, and I also would like to participate in Google Summer of Code 2010. I had some experience of generic programming before when I tried to implement my own generic graph library in C# (of course, as a task on one of programming courses at the university). I've read that (quote) "The Boost.Graph library is missing connectives...". I'm quite familiar with C++ and the idea of generic programming and I'm working with some graph theory aspects at the moment, so I want to know: what particular skills (in programming, of course) are needed to develop graph connectives? Thanks in advance, Yaroslav

2 2

[bgl] Reconnecting an edge
by Matthias Walter 01 Apr '10

01 Apr '10

Hi! Is there any way to reconnect an edge in a graph? I'm interested in doing so while retaining a property map. Thus remove_edge and add_edge are not a solution, I think. If not, may it worth to add such a concept? best regards Matthias Walter

3 3

[GSoC 2010] Boost.Graph topology generators
by Omair Mohammed Abdullah 01 Apr '10

01 Apr '10

Hi, I am interested in implementing topology generators for Boost.Graph. I have a few questions: What is the scope of this project? Is it expeced to implement the common topologies with detection methods or more? For example, are generators like PLOD, Erdos-Renyi and small-world are already there. Are we supposed to extend them?

2 1

GSOC 2010 :BOOST Heaps and Queues
by shivaraaj kotini 01 Apr '10

01 Apr '10

Hi all, Im Shivaraaj, Im from Birla Institute of Technology Science (B.I.T.S) pilani, India. I recently came across GSOC 2010 and Im very interested in it.Though Im late I dont want to give up and continue discussing ideas before submitting an application. Im very much interested in BOOST Heaps and Queues project. My idea was to create a replica of JSDL api in BOOST

1 0

Second iteration of Boost.XInt library uploaded, requesting further comments
by Chad Nelson 01 Apr '10

01 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've just uploaded the second iteration of the Boost.XInt library to the Boost Vault. I very much appreciate all of the comments and suggestions everyone has offered on the first one, and I've incorporated a number of them. Maybe I'm just a masochist, but please take a look and let me know what you think. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuypFUACgkQp9x9jeZ9/wRD3wCeMKRKaeml9UzhMNTpl15RvBFE pw8AniN8kkXNEFelgY4VYtWNzaCi88cV =lHLU -----END PGP SIGNATURE-----

5 13

[lock-free] CDS -yet another lock-free library
by Khiszinsky, Maxim 01 Apr '10

01 Apr '10

Hi, I'd like to present to boost community the CDS (Concurrent Data Structure) C++ library at libcds.sourceforge.net. It is an attempt to generalize well-known lock-free (and a few lock-based) data structures discovered by famous researches (M.Michael, N.Shavit and others). The library is mostly header-based, only the kernel of light-weight memory managers is resided in small dynamic library. The CDS library supports a set of modern processor architectures: x86, amd64, ia64, sparc; compiler supported is GCC 4 and MS Visual C++ 2008. The last CDS release 0.6.0 is developed close to C++ Memory Model proposal. I need the recommendations from boost community about : 1. Are the atomic primitives implemented correct for each of supported processor?.. I'm not an expert in this area... 2. Is the memory order constraint (from C++1x proposal) choosed correctly for lock-free data structure implementation?.. I known it is very large and magic question. Maybe, somebody analyzes the library code and find the errors. And I be very glad if anybody joins to CDS project. It is very interesting area of computing science with nonstandard algorithms and crazy implementation (and debugging notably).

9 35

[GSoC] Boost.XML proposal: 1st draft
by Ilie Halip 01 Apr '10

01 Apr '10

Hi, I almost finished writing the first draft of my project proposal (boost.xml). It has about everything except the schedule, for which I need a bit more time. I expect it to be finished in 2-3 hours from now. You can find the draft here: http://docs.google.com/View?docID=0Aa-6sdK9e3RZZGQydHd2ODVfNGZmdmtoNmM2 Please provide feedback. Thanks, Ilie.

1 0

GSOC Application Dates.
by swagat konchada 31 Mar '10

31 Mar '10

Does Boost suggest submitting the proposals for GSOC'10 as early as possible? Or is it ok if I take time? -- Problem is a phenomenon indicating lack of thought. Swagat Konchada

2 1

GSOC BigInt Numeric_adaptor
by swagat konchada 31 Mar '10

31 Mar '10

> swagat konchada wrote: > > > If we consider performance issues based on design, planning the > > BigInt architecture could be designed in two ways > > > > 1. 3 layers to allow optional binding to Boost's own bigint, > > GMP, or anyother bigint library, for the user during compile > > time. > > > > 2. 2 layers if we plan to limit Boost.Bigint's options to only > > itself and GMP. > > [snip] >IMO you should look at the discussion on a numeric_adaptor by Barend Gehrels and some draft code mentioned in > http://archive.freebsd.se/?ml=freebsd-questions&a=2007-05&m=11343770<http://archive.freebsd.se/?ml=freebsd-questions&a=2007-05&m=11343770> >to get some idea of the problem and a plausible framework which might include 'BoostsOwnBigInt' as an alternative to GMP >etc. >Paul >PS But you should also be aware that another xInt project is being discussed on this group. I checked out the numeric_adaptor scheme. It has used the GMP library and the CLN library's API to optionally provide some basic arithmetic operators on arbitrary precision decimal numbers(it was surprising since i expected adaptation for integer operations first, though i realise that there'd be no much change in the code). The main idea of the numeric_adaptor scheme though is the to_traits struct, which would cast the library dependent types to Boost's types by using explicit templates(i hope this is the right term). In fact the scheme paves the way for a direct start of the implementation of Bigint since it provided the core design(the very expression template system which was called for) of an optional BigInt library. Making this expression template system exhaustive and make it work with any one of the libraries(GMP ofcourse), must be our priority. @Paul. A. Bristow : I am also following the discussion on Xint, and would comment on it asap. Suggestions and criticism please! -- Problem is a phenomenon indicating lack of thought. Swagat Konchada

1 0

[intrusive doc] slist says that both push_front and push_back are constant-time
by Andy Venikov 31 Mar '10

31 Mar '10

The doc for slist says that if using non-constant size semantics, the size of the slist is the size of a single pointer. That means that either push_front or push_back cannot be constant time since we first need to find it. Am I missing something? Thanks, Andy.

2 2

[1.43.0] Cutoff for major code changes approaching
by Beman Dawes 31 Mar '10

31 Mar '10

The cutoff date for major code changes is this weekend, so please complete any pending merges to the release branch. Also, now might be a good time to check the release regression tests and inspection reports to make sure your library is in good shape: http://beta.boost.org/development/tests/release/developer/summary.html http://boost.cowic.de/rc/inspect-snapshot.html PS: The beta is scheduled for April 17th, and the release for May 1. The calendar can be seen at: http://www.boost.org/development/index.html -- The Release Managers, Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

1 0