- Boost - lists.preview.boost.org

[program_options, function] vc7 problem
by Vladimir Prus 25 Jun '04

25 Jun '04

The regression logs show this error message from vc7 http://tinyurl.com/39fgc which says that pointer to function can be converted to boost::function The relevant code is: int stored_value; void notifier(const vector<int>& v) { stored_value = v.front(); } void test_semantic_values() { .... ("int", po::value< vector<int> >()->notifier(notifier)) ; } Where the 'notifier' member function is defines as: typed_value* notifier(function1<void, const T&> f) and in this case, T = vector<int>. Any ideas what I can do to make this work? - Volodya

3 3

The Test Tools Docs, Concept Checking
by Andy Little 25 Jun '04

25 Jun '04

Hi, I have been reading the Test Tools docs. Would it be a good idea to add ConceptChecking to the list of alternative methods of reporting errors, in /test/doc/index.html#introduction ? A recent post on boost alluded to the fact that Concepts (ie What is a concept? ) can be difficult to understand. Well ... ConceptChecks are the medium for pinning down Concepts in C++ code and are probably the most effective means of error reporting at compile time, but are not used as much as they could be. The Boost Test Library would seem to be as good a place as any to promote them, which could help to remove some of the mystery. regards Andy Little

1 0

(no subject)
by Robert Ramey 25 Jun '04

25 Jun '04

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

4 3

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