- Boost - lists.boost.org

Python port development
by Vladimir Prus 09 Jul '10

09 Jul '10

Hi, as many here probably know, the strategic direction for Boost.Build is the use of Python as implementation language, which should bring a lot of benefits. For more detailed rationale, see: https://trac.lvk.cs.msu.su/boost.build/wiki/PythonPort The port has got so far as to build "hello, world" with gcc, but then stalled. Fortunately, my employer, CodeSourcery, has a sabbatical program, and completing a Python port of Boost.Build was approved as the goal of my own sabbatical. I'll have 4 almost-full-time weeks, starting next Monday, Jule 12. Of course, I'll be asking for feedback, so don't be surprised when I start to post design questions. Thanks, -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2

3 2

Vault: `BGL` directory
by Daniel Trebbien 08 Jul '10

08 Jul '10

Would someone please delete the `BGL` directory on the Vault? I created it before I found the more-suitable `Algorithms/graph` directory.

1 0

[python] boost-1.44 apply patch br#3843
by Neal Becker 08 Jul '10

08 Jul '10

I'd like to see this patch applied for 1.44. Seems pretty harmless. The purpose is so that BOOST_PYTHON_MODULE macro will expand it's arguments, so that this code will work: #define MY_NAME BOOST_PP_CAT(ldpc_,SIMCASE) BOOST_PYTHON_MODULE(MY_NAME) {... https://svn.boost.org/trac/boost/attachment/ticket/3843/boost_python_module…

2 1

Re: [boost] Maintenance NOT suspended
by Christophe Henry 08 Jul '10

08 Jul '10

>I hereby apologize to the community for my earlier announcement and request that you accept a retraction Thanks for taking this courageous decision! >> So, concretely, what is the problem? Do you have no time handling the >> feature requests or is svn the problem? > >I'll prepare a proper response to these questions in a separate message, but I wanted to head off any damage immediately. As I made the suggestion, count me in. After you explain what you need, hopefully more will volunteer. Regards, Christophe

1 0

[thread][VS2010] shared_mutex woo's
by Hartmut Kaiser 08 Jul '10

08 Jul '10

This: #include <boost/thread.hpp> int main() { boost::shared_mutex mtx; boost::upgrade_lock<boost::shared_mutex> l(mtx); boost::upgrade_to_unique_lock<boost::shared_mutex> ul(l); return 0; } still fails on VC21010. Defining BOOST_NO_RVALUE_REFERENCES makes this compile, though. Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

3 3

[Fusion] Permission to update release branch and roll in dependencies
by Tobias Schwinger 08 Jul '10

08 Jul '10

Dear release team, we're about to freeze the next release. I'd like to kindly ask for your permission to address the issues discussed in this thread http://thread.gmane.org/gmane.comp.lib.boost.devel/198532/ before it's too late, again. Reportedly the outdated files do - other than hoped in that thread - NOT work anymore - and neither do the new and documented ones for the lack of dependencies. So, what I'd like to do is: o merge trunk changes into the Functional module of Fusion o add Forward o optionally add Factory Please check the new mini libraries for "release compliance" and give me a go on the fix. Would be too bad to go with a partially defunct Fusion in two releases for bureaucratic reasons. Please also note that rolling back to a proper previous version might involve more changes and will complicate future merges for us. Regards, Tobias

6 8

Name conflict: boost/range/adaptor/replaced.hpp and boost/algorithm/string/replace.hpp
by Jeremy Maitin-Shepard 08 Jul '10

08 Jul '10

I found that these two header files (the second one being required indirectly by including boost/exception/all.hpp) cannot be used together, because they both attempt to bring a definition of replace_range into the boost namespace. This is with boost-1.43.

1 0

boost.atomic library works on Linux but not on Windows -- please help
by Anqing Xu 07 Jul '10

07 Jul '10

Hi, In search of a std:atomic<T> implementation, I decided to give boost.atomic library a try. My initial investigation found it worked fine under linux. However it does not work on Windows. Here is a little test program to demonstrate: #include <iostream> #include <boost/atomic.hpp> #include <boost/lockfree/detail/tagged_ptr.hpp> #include <boost/lockfree/detail/freelist.hpp> int main() { boost::lockfree::caching_freelist<int> pool(3); int* pInt1 = pool.allocate(); *pInt1 = 1; int* pInt2 = pool.allocate(); *pInt2 = 2; int* pInt3 = pool.allocate(); *pInt3 = 3; pool.deallocate(pInt1); pool.deallocate(pInt2); pool.deallocate(pInt3); int* pInt4 = pool.allocate(); int* pInt5 = pool.allocate(); int* pInt6 = pool.allocate(); } The test uses boost.lockfree library, which you can download from http://tim.klingt.org/git?p=boost_lockfree.git If you set a break point, say in fallback.hpp, you will see that on Windows it falls back to spinlock. Can somebody please suggest how to fix this? I suspect the issue has something to do with intptr_t type. I looked into the code but quickly started to have headache. Atomic library uses template metaprogramming and is not easy to understand. -Anqing

1 0

[mpl] zero argument member template detection
by Daniel Walker 07 Jul '10

07 Jul '10

Hello, Following up on Steven's question from a few weeks ago (sorry for delay) about has_xxx_template, there is a bug in msvc 9 and 10 that causes ICE. I filed a bug against msvc here. https://connect.microsoft.com/VisualStudio/feedback/details/571720 Here is code to reproduce the bug. struct S { template<class T = int> struct X {}; }; template<class T> // The following line causes ICE void f(typename T::template X<>*) {} // The following alternative line compiles cleanly //void f(typename S::template X<>*) {} // The following line also compiles cleanly //void f(typename T::template X<int>*) {} int main() { f<S>(0); } Incidentally, the code above is accepted by msvc 8 and gcc... and clang! :) I do not know of a work around. Moreover, while looking for a work around, I found another bug in has_xxx_template that may render zero argument detection unreliable on any compiler. Rethinking some of my original design choices, I now believe that it is a bad idea to conflate member template detection and template arity detection. It would be better if BOOST_MPL_HAS_XXX_TEMPLATE_DEF defined a metafunction to detect member templates of any arity (up to some configurable limit). So I made the appropriate changes to effect this and updated the tests and documentation. The changes did not cause errors running the MPL test suite on gcc 3.4, 4.3, 4.4, 4.5 and msvc 7.1, 8, 9, 10. So, in sum, the interface is now cleaner and works consitently across compilers. Since this is the first release of has_xxx_template, I went ahead and checked the changes into trunk. Hopefully, I got this committed in time for the 1.44 code freeze... Do I still need to merge to release? Further discussion of some details follows for those who are interested. First, regarding the general problem of template arity detection, perhaps this is a motivating need for a seperate template_arity metafunction. There's already one in mpl/aux_ that's not part of the external library API. If there's interest, I'll post more on this later in a seperate thread. Regarding the specific problem of zero member template argument detection for has_xxx_template, the issue is that while you can instantiate a template with zero arguments, you do not actually declare a template with zero arguments, obviously. For example, struct S { template<class T = int> struct xxx {}; }; So, S::xxx is actually a one argument template that can be instatiated with zero args; e.g. S::xxx<>(). Originally, I was trying to detect how many arguments a template can be instatiated with, but I think this is the wrong approach. The technique I'm using in BOOST_MPL_HAS_XXX_TEMPLATE_DEF can only reliably detect the declared arity of the tempate. Here's a brief outline of how it works. BOOST_MPL_HAS_XXX_TEMPLATE_DEF defines a metafunction that uses SFINAE to detect member templates in the following way. template<template<class> class> struct substitute {}; template<class T> long has_xxx_test(substitute< T::template xxx >*); template<class> short has_xxx_test(...); const bool result = sizeof(has_xxx_test<S>(0)) == sizeof(long); However, to detect zero arguments, the following would be invalid, since you cannot declare a template with zero parameters. template<template<> class> struct substitute {}; So instead the zero arg test was performed using template<class T> long has_xxx_test(typename T::template xxx<>*); Unfortunately, this test causes ICE on msvc, and really, it doesn't completely work on any compiler, since it is invalid if T's xxx member template does not have default parameters; i.e. it cannot properly reject member templates requiring one or more arguments. The new BOOST_MPL_HAS_XXX_TEMPLATE_DEF on trunk resolves these issues by removing the requirement that users specify the template arity and arguments. Instead, it generates a metafunction that detects member templates of any arity. It does so by providing several overloads of the internal test function, one for each arity, up to a user configurable maximum (BOOST_MPL_LIMIT_METAFUNCTION_ARITY) as illustrated by the following simplified code. #include <boost/mpl/assert.hpp> #include <boost/mpl/bool.hpp> template<class T> class has_xxx { template<template<class> class> struct substitute1 {}; template<template<class,class> class> struct substitute2 {}; template<class U> static long has_xxx_test(substitute1<U::template xxx>*); template<class U> static long has_xxx_test(substitute2<U::template xxx>*); template<class> static short has_xxx_test(...); public: static const bool value = sizeof(has_xxx_test<T>(0)) == sizeof(long); typedef boost::mpl::bool_<value> type; }; struct S1 { template<class> struct xxx {}; }; struct S2 { template<class,class> struct xxx {}; }; int main() { BOOST_MPL_ASSERT(( has_xxx<S1> )); BOOST_MPL_ASSERT(( has_xxx<S2> )); BOOST_MPL_ASSERT_NOT(( has_xxx<int> )); } Daniel Walker

1 0

Re: [boost] auto-link with gcc/windows
by Jürgen Hunold 07 Jul '10

07 Jul '10

Hi Robert ! On Monday, 5. July 2010 19:35:02 you wrote: > In my code I use BOOST_HAS_DECLSPEC but I'm having problems with > mingw. I'm not sure it has anything to do with this, but it's not at clear > to me > what the differing meanings are of BOOST_HAS_DECLTYPE and > BOOST_HAS_DECLSPEC. BOOST_HAS_DECLSPEC is the interesting one. Please find a patch adding two more "#define BOOST_SERIALIZATION_SOURCE" to the sources. This fixed compilation for me when using gcc's symbol visibility and might help here as mingw uses symbol visibility "under the hood" for __declspec(dllimport/-export). Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * juergen.hunold(a)gmx.de ! -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

8 23