- Boost - lists.boost.org

Re: [boost] 1.32 release preparation
by Reece Dunn 25 Jun '04

25 Jun '04

Mathew Robertson wrote: > > > To allow the autoconf tools (ie configure) to detect the presence of >the various Boost libs and header file versions, would it be possible to >add a C-linkage function to each libraries' source file(s). This would >allow users to add a configure check which detects if a particular library >instance is installed. For example, we add the following code to each >library instance: > > > > > > extern "C" boost_autoconf() {} > > > > > > This allows autoconf users to add a test to their configure.in script: > > > > > > AC_CHECK_LIB(boost_regex,boost_autoconf,...,[Boost::Regex library >not found]) > > > > I don't see why you need a function with C linkage for this to work. > > The behavior of autoconf depends on the current language specified > > in configure.ac at the point where you call AC_CHECK_LIB. If that >language > > is C++, you should well be able to test for functions with C++ linkage. > > See >http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_chapter/auto… > >Yeah - thats what I'm trying to do. Specifically, I'm trying to detect if >"libboost_regex..." is installed, so I have the following: > >AC_CHECK_LIB(boost_regex-gcc,<somefunc>,,AC_ERROR([Must have the >Boost::Regex library installed]) > >Now the problem is, 'What do I put in for <somefunc>?' All other C++ >libraries I have used, specifically contain a C-linkage function to allow >configure to detect it. I am not familiar with the autoconf tool, but is it possible to have something like this: // include_test.cpp #include <boost/regex.hpp> int main() { // simple regex use here return( 0 ); } //--end That way, you'd get a compile error if regex.hpp is not found (Boost is not on the system) or a link error if the library is not available (library hasn't been built or configured). I am not sure how this translates to autoconf: have you had a look to see how GCC checks for stdio.h, etc.? Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

Boost.Variant concepts and LessThanComparable documentation
by Guillaume Melquiond 25 Jun '04

25 Jun '04

Hi, Looking through the documentation of Boost.Variant (both 1.31 and cvs versions), I see that "variant is itself LessThanComparable if and only if every one of its bounded types meets the requirements of the concept". The documentation directly hyper-links to the concept part of Boost and this concept description explains that "LessThanComparable types must have <, >, <=, and >= operators". Unfortunately, boost::variant implementation only defines operator<. So here we have a contradiction between the implementation and the interface. The same kind of problem arises with operator!= and the EqualityComparable concept. I am not sure what the best solution is: - define the missing operators in boost::variant, - remove any reference to LessThanComparable and EqualityComparable concepts from boost::variant documentation, - correct the concepts so they only speak about operator< and operator==. The last solution corresponds to the way the concepts are defined in the [lib.utilities] part of the C++ standard. But I would rather see the missing operators defined in boost::variant if possible. Regards, Guillaume

2 1

Child processes
by Angus Leeming 25 Jun '04

25 Jun '04

I am in the process of writing a little library to control the interaction of a parent program with any child processes that it spawns. Would there be any interest in such a library here? Assuming that there would, please excuse me diving in at the deep end. I'm currently mulling over how best to ensure that system resources are cleaned up automatically when the child exits and would value some advice. Under unix, I've defined a handler for SIGCHLD signals. The handler does two things only: * reaps the zombie * stores the return status in a std::map<pid_t, int> completed_children; variable. Each time a new child is spawned, the pid of the child process is registered in the map, so the handler needs do nothing other than find the entry. namespace { std::map<pid_t, int> completed_children; int status; sig_atomic_t pid; } extern "C" void child_handler(int) { pid = wait(&status); std::map<pid_t, int>::iterator it = completed_children.find(pid); if (it != completed_children.end()) it->second = status; } I'm pretty sure that the above is safe code. It does the absolute minimum in the handler routine. wait() is guaranteed to be async-safe. Moreover, the handler receives only SIGCHLD signals and so cannot receive multiple calls simultaneaously. However, I'm unsure whether it Ok to search the map like this. Any advice? My one other worry is that the SIGCHLD handler could be redefined elsewhere in the code, but AFAICS there's nothing that I can do about that. Furthermore, it means only that the user of my Child library won't be able to ascertain the exit status of child processes launched using it. (If the zombie is reaped elsewhere then a subsequent call to waitpid(pid, &status, WNOHANG); will result in errno being set to ECHILD. Ie, I'll know that the child process has ended but just won't know its exit status.) Under windows, I'm proposing to use a separate thread to wait() for each child process. This seems to be the standard way of dealing with the problem, but I'm a total novice when it comes to Windows programming so know only what I've read. Again, any advice would be greatly appreciated. Regards, Angus

9 24

[1.32 Plan] uBLAS preperation
by Michael Stevens 24 Jun '04

24 Jun '04

Hi Aleksey, Thanks for the clear plan. The current status of uBLAS is that it has been relatively untouched in the Boost CVS single 1.30.0. The active development takes place on a separate CVS. Therefore now would be a good time to bring in the latest code which as some quite significant improvements. The code is relatively stable and tested on core compilers. Issues: On exotic (old) compiler the code is relatively untested and expected to fail. Therefore the real need with regard to 1.32 is to get feedback from extensive regression testing results in good time. As ever the documentation could do with further work to bring it up to date with the to be release version. Thanks, Michael ___________________________________ Michael Stevens Systems Engineering 34128 Kassel, Germany Phone/Fax: +49 561 5218038 Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

2 1

Numeric Conversions Library added to CVS
by Fernando Cacciola 24 Jun '04

24 Jun '04

Hi All, In preparation for the upcoming 1.32 release I added this library to CVS. The code and docs have been changed according to the extensive review results. I still need to extend the documentation adding examples and motivating cases though, which I plan to do before the release. I haven't yet changed "boost/cast.hpp" to use the new stuff, I will as soon as I see the code stablilized among different compilers. In the meantime, new users can use "boost/numeric/conversion/cast.hpp" which contains the new version of numeric_cast<> Best Fernando Cacciola SciSoft

2 1

RE: [boost] (no subject)
by Michiel Salters 24 Jun '04

24 Jun '04

Would BOOST_STATIC_ASSERT( (T*) 0 ) work for you ? Regards, Michiel Salters. > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Robert Ramey > Sent: donderdag 3 juni 2004 22:29 > To: boost(a)lists.boost.org > Subject: [boost] (no subject) > > > BOOST_STATIC_ASSERT - > > On occasion I find it convenient to use: > > BOOST_STATIC_ASSERT(false) > > In templated code that should be unreachable. However, its > doesn't work > with compilers that are too smart for their own good. In > order to make this > work I need something like: > > BOOST_STATIC_ASSERT(boost::false_<T>::value) > > Where boost::false<T> is a type that yields false for any type T. > > Am I correct here? Where should such a code snippet be > placed? Could it be > added to mpl, type_trait or what? > > Robert Ramey > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

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