- Boost - lists.boost.org

Any scheduled date for Boost 1.32?
by Joaquín Mª López Muñoz 24 Jun '04

24 Jun '04

Aleksey talked about June 28th: http://lists.boost.org/MailArchives/boost/msg62871.php but seems like there has been no activity wrt to releasing Boost 1.32 since. Is that date still valid? I guess it is not, for the one week remaining is probably to little time to arrange everything. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

7 7

Boost.Python / Graph library problem after cvs update
by Ralf W. Grosse-Kunstleve 24 Jun '04

24 Jun '04

With the latest Boost CVS compilation of boost/libs/python/src/object/inheritance.cpp with the old IRIX MIPSpro compiler (EDG 238) fails for this code in boost/boost/graph/properties.hpp: namespace detail { template<typename VertexBundle, typename EdgeBundle> type_traits::yes_type is_vertex_bundle_helper(VertexBundle*); template<typename VertexBundle, typename EdgeBundle> type_traits::no_type is_vertex_bundle_helper(EdgeBundle*); template<typename VertexBundle, typename EdgeBundle, typename Bundle> struct is_vertex_bundle { BOOST_STATIC_CONSTANT(bool, value = ((sizeof(is_vertex_bundle_helper<VertexBundle, EdgeBundle>((Bundle*)0)) == sizeof(type_traits::yes_type)))); }; } The error is: cc-1278 CC: ERROR File = /txusr/rwgrosse/hot/boost/boost/graph/properties.hpp, Line = 363 No instance of overloaded function "boost::detail::is_vertex_bundle_helper" matches the argument list. The argument types are: (Bundle *). BOOST_STATIC_CONSTANT(bool, value = ((sizeof(is_vertex_bundle_helper<VertexBundle, EdgeBundle>((Bundle*)0)) ^ I tried to rearrange the code a bit: namespace detail { template<typename VertexBundle, typename EdgeBundle> struct is_vertex_bundle_helper { static type_traits::yes_type get(VertexBundle*); static type_traits::no_type get(EdgeBundle*); }; template<typename VertexBundle, typename EdgeBundle, typename Bundle> struct is_vertex_bundle { typedef is_vertex_bundle_helper<VertexBundle, EdgeBundle> helper_t; BOOST_STATIC_CONSTANT(bool, value = ((sizeof(helper_t::get((Bundle*)0)) == sizeof(type_traits::yes_type)))); }; } This still compiles with other compilers (gcc 3.4 and EDG 245), but not with the old EDG 238: cc-1108 CC: ERROR File = /txusr/rwgrosse/hot/boost/boost/graph/properties.hpp, Line = 368 The indicated expression must have pointer-to-function type. BOOST_STATIC_CONSTANT(bool, value = ((sizeof(helper_t::get((Bundle*)0)) == sizeof(type_traits::yes_type)))); ^ It doesn't even compile if I simplify the code like this: cc-1108 CC: ERROR File = /txusr/rwgrosse/hot/boost/boost/graph/properties.hpp, Line = 371 The indicated expression must have pointer-to-function type. static const std::size_t value1 = sizeof(helper_t::get((Bundle*)0)); ^ 1 error detected in the compilation of "/txusr/rwgrosse/hot/boost/libs/python/sr I am lost here. Suggestions for workarounds are very much appreciated. It used to compile with the CVS from a couple of days ago. It is important to us to get the IRIX build working again. Thanks in advance, Ralf P.S.: inheritance.cpp compiles if I simply set BOOST_STATIC_CONSTANT(bool, value = false); Therefore I was hopeful that the problem can be fixed by rearranging the code fragments shown above. __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

3 5

Boost.Threads inconsistency question
by Michael Glassford 23 Jun '04

23 Jun '04

The Boost.Threads documentation states that the ScopedTimedLock concept is a refinement of the ScopedTryLock concept; however, the boost::timed_mutex::scoped_timed_lock class, which is supposed to be a model of the ScopedTimedLock concept, doesn't define the various try_* methods. In your opinion, should the documentation be changed to state that the ScopedTimedLock concept is a refinement of the ScopedLock (rather than ScopedTryLock) concept, or should the boost::timed_mutex::scoped_timed_lock class implement the various try_* methods? (FYI: a similar situation applies to boost::recursive_timed_mutex::scoped_timed_lock and boost::timed_read_write_mutex::scoped_timed_lock). Mike

2 3

problem with boost::thread
by Janusz Piwowarski 23 Jun '04

23 Jun '04

Hello. After latest cvs update, i've got errors like: gcc-C++-action bin\boost\libs\thread\build\boost_thread.dll\mingw\debug\threading-multi\con dition.obj In file included from d:/sources/boost/libs/thread/src/condition.cpp:18: d:/sources/boost/libs/thread/src/timeconv.inl: In function `void <unnamed>::to_time(int, boost::xtime&)': d:/sources/boost/libs/thread/src/timeconv.inl:24: error: template-argument ` boost::<anonymous enum>' uses anonymous type d:/sources/boost/libs/thread/src/timeconv.inl: In function `void <unnamed>::to_duration(boost::xtime, int&)': d:/sources/boost/libs/thread/src/timeconv.inl:92: error: template-argument ` boost::<anonymous enum>' uses anonymous type d:/sources/boost/libs/thread/src/timeconv.inl: In function `void <unnamed>::to_microduration(const boost::xtime&, int&)': d:/sources/boost/libs/thread/src/timeconv.inl:114: error: template-argument ` boost::<anonymous enum>' uses anonymous type "g++" -c -Wall -ftemplate-depth-100 -DBOOST_THREAD_BUILD_DLL=1 -g -O0 -f no-inline -mthreads -mthreads -mno-cygwin -I"bin\boost\libs\thread\build" -I"d:\sources\boost" -o "bin\boost\libs\thread\build\boost_thread.dll\mingw\debug\threading-multi\co ndition.obj" "d:\sources\boost\libs\thread\build\../src/condition.cpp" Error lines in timeconv.inl file contains: assert(res == boost::TIME_UTC) where res is int, and boost::TIME_UTC is enum. When i changed it to assert(res == static_cast<int>(boost::TIME_UTC)); it starts to compile. But I don't understand what's happend, there aren't changes in boost::thread. Any ideas? WinXP, mingw 3.3.1 Regards, Janusz

3 5

shared_ptr with dynamic_cast
by Yuval Ronen 23 Jun '04

23 Jun '04

Hi, I'm new to boost, so this post might seem silly to some of you, and I apologize if this is the case. I have a tiny performance suggestion: The c'tor template<class Y> shared_ptr(shared_ptr<Y> const & r, detail::dynamic_cast_tag): px(dynamic_cast<element_type *>(r.px)), pn(r.pn) { if(px == 0) // need to allocate new counter -- the cast failed { pn = detail::shared_count(); } } should be changed to: template<class Y> shared_ptr(shared_ptr<Y> const & r, detail::dynamic_cast_tag): px(dynamic_cast<element_type *>(r.px)), pn(px ? r.pn : detail::shared_count()) { } The difference is when the dynamic_cast fails and returns NULL. In such cases the existing code copies the shared_count object, including mutex locking, only to discover later that it was unnecessary (the 'if(px == 0)' statement). The suggested code saves this copy of the shared_count object, which also saves some mutex lockings. Hope I'm not talking nonsense, Yuval

2 1

min/max, reloaded
by Eric Niebler 23 Jun '04

23 Jun '04

I have ripped out the std_min/std_max functions. They were a less-than-perfect solution to the problems caused by the min/max macros defined by some platform headers. I have fixed all the places in the Boost affected by this change, and I have also updated the coding guidelines. For your references, the guidelines are reproduced here: Make sure your code compiles in the presence of the min() and max() macros. Some platform headers define min() and max() macros which cause some common C++ constructs to fail to compile. Some simple tricks can protect your code from inappropriate macro substitution: If you want to call std::min() or std::max(): If you do not require argument-dependent look-up, use (std::min)(a,b). If you do require argument-dependent look-up, you should: #include <boost/minmax.hpp> Use BOOST_USING_STD_MIN(); to bring std::min() into the current scope. Use min BOOST_PREVENT_MACRO_SUBSTITUTION (a,b); to make an argument-dependent call to min(a,b). If you want to call std::numeric_limits<int>::max(), use (std::numeric_limits<int>::max)() instead. If you want to call a min() or max() member function, instead to doing obj.min(), use (obj.min)(). If you want to declare or define a function or a member function named min or max, then you must use the BOOST_PREVENT_MACRO_SUBSTITUTION macro. Instead of writing int min() { return 0; } you should write int min BOOST_PREVENT_MACRO_SUBSTITUTION () { return 0; } This is true regardless if the function is a free (namespace scope) function, a member function or a static member function, and it applies for the function declaration as well as the function definition. Thanks. -- Eric Niebler Boost Consulting www.boost-consulting.com

3 4

Boost.Config defect macro proposal
by Joaquín Mª López Muñoz 23 Jun '04

23 Jun '04

Some months ago I proposed to include a defect macro to detect some defficiencies by several compilers regarding the ability to handle pointers to data members as template parameters. The name we came up with is BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS I include a little test case that successfully detects the bug in three out of the four compilers checked to show the problem * MSVC 6.5 (MSKB article ##249045), * MSVC 7.0 (***) * ICC 7.0/7.1 for Windows (support issue #207321), * VisualAge 6.0 for AIX (internal defect #288539.) The compiler marked with (***) does fail with the test, but only under certain compiler settings that I've not been able to isolate properly. When last discussed, it was argued that a new defect macro would only make sense if some lib needed it: now Boost.MultiIndex can take advantage of it (actually, the lib assumes the macro even if not currently supported by Boost.Config), and the problem has turned out to be more prevalent than the original MSVC-constrained case hinted at. Is it OK to add this to Boost.Config? Comment? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo *** BEGIN TEST CODE*** #include <iostream> struct pair { int x,y; pair(int x_,int y_):x(x_),y(y_){} }; template<int pair::* PtrToPairMember> struct foo { int bar(pair& p){return p.*PtrToPairMember;} }; int main() { pair p(0,1); foo<&pair::x> fx; foo<&pair::y> fy; if(fx.bar(p)!=0||fy.bar(p)!=1)std::cout<<"KO"<<std::endl; else std::cout<<"OK"<<std::endl; return 0; } ***END TEST CODE***

4 5

Generalized Iterator Ranges
by Dale Muchow 23 Jun '04

23 Jun '04

Here is a paper I wrote discussing the notion of generalizing an iterator defined range. It includes the proposal and definition of a new concept, Range. It was written as a masters research paper for graduate work I did at North Dakota State University. http://www.lycanth.com/dmuchow/GeneralizedIteratorRanges.doc.zip _________________________________________________________________ >From will you? to I do, MSN Life Events is your resource for Getting Married. http://lifeevents.msn.com/category.aspx?cid=married

2 1

[Graph] Bundled properties, take 2
by Douglas Paul Gregor 23 Jun '04

23 Jun '04

Good evening, I've just checked in version 2 of the "bundled properties" patch for the BGL, which allows one to stick various vertex/edge properties into a class to be stored within adjacency_list/adjacency_matrix. Accessing these properties is easier and more convenient. This patch completes support for bundled properties. Both of the major graph types are supported, bundled properties play nice with other property maps (get/put support added), and bundled properties work with graph adaptors. The documentation now strongly urges users to adopt bundled properties instead of property lists :) Doug

2 1

RE: [boost] Child processes
by Glen Knowles 23 Jun '04

23 Jun '04

> I don't know how java deals with this but on posix platforms > a sub-process holds some resources that have to be claimed > back by the parent process. > This includes (but is not restricted to) the result of the > process, i.e. > its return value. In case you are familiar with (posix) > threads: there you have to join a thread after it terminated. > It's conceptually the same thing here. > If you find yourself joining posix's threads only for this reason you should consider setting the detachstate attribute to PTHREAD_CREATE_DETACHED instead. Glen

1 0