June 2004 - Boost - lists.preview.boost.org

store a boost::bind
by Nico Massi 27 Jun '04

27 Jun '04

Hi, Is it possible to store a boost::bind? boost::bind<int> x( f, _1, _2 ); int i = x( 3, 4 ); I get errors if i want to declare a variable of type boost::bind. The point is: I want to have an object that gets a boost::bind, stores it and executes it with the correct values to the time i want. How can i do this? Ciao

4 6

[1.32 Plan] Any date for new version of MPL
by JOAQUIN LOPEZ MU?Z 27 Jun '04

27 Jun '04

Any tentative date for the new version of MPL making it into the CVS? Specially if we stick to July 21st a the release date, I'm concerned that the new MPL will have us fixing regressions for quite a few weeks. OTOH, maybe the update is smooth enough and not many problems arise, but it'd be good to know. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

detail/atomic_count_gcc.hpp error
by Rene Jager 27 Jun '04

27 Jun '04

trying to do: boost::detail::atomic_count c(0); std::cout << long(c) << std::endl; with gcc 3.2.2 gives: /usr/include/boost/detail/atomic_count_gcc.hpp: In member function `boost::detail::atomic_count::operator long int() const': /usr/include/boost/detail/atomic_count_gcc.hpp:46: invalid conversion from ` const _Atomic_word*' to `volatile _Atomic_word*' in the following function: operator long() const { return __exchange_and_add(&value_, 0); } The problem can be solved by making the private member "_Atomic_word value_" mutable. renej ps I know I shouldn't use detail/* stuff directly... --

3 3

[Concept checking] Missing TrivialIteratorConcept
by Hervé Brönnimann 27 Jun '04

27 Jun '04

Hi just occured to Sylvain Pion and myself recently that the TrivialIteratorConcept is documented but not part of the code, and same for Mutable_TrivialIteratorConcept. It is also missing from the test suite (concept_check_test.cpp) and from the archetypes. This may be intentional or not, but probably either the concepts and archetypes should be added to the code, or removed from the documentation. A small and easy bugfix for 1.32? -- Herve'

2 1

A new way of sorting and searching
by Nic Roets 27 Jun '04

27 Jun '04

Often when I write searching or sorting code in C or C++, I'm frustrated that I have to make a new "callback type" compare function. E.g. when you want to sort a number of points in 2D space according to their distance from a reference point, it's tempting to do something like struct Pt { int x, y; }; static Pt center; // Global or static variable yuck. int PtDistToCenterCmp (Pt &a, Pt &b) { return Dist (a, center) - Dist (b, center); } main() { ... center.x = ...; center.y = ...; ... sort (...); ... } This type of solution has many problems. Reviewing the code for correctness is difficult because now you have to read half way through main, stop to find the definition of center, then continue with main, then find the definition of PtDistToCenterCmp, then continue with main. To solve this problem I suggest a new template class "sorter" : template<class t> struct sorter { // Qsort would require a stack here. Heapsort only a few variables. iterator a, b; sorter(iterator begin, iterator end); // Exuse my cpp if it's // incorrect int Operate (int cmpResult); }; Then it would be used like this : void main () { ... sorter<Pt> sortObj (..., ...); while (sortObj.Operate ( Dist (sortObj.a, center) - Dist (sortObj.b, center))) {} ... } IMHO this is much clearer. A binary searching template class can also be implemented in this way. -- Regards Nic Roets

3 2

Request for reviewers for a CUJ article
by Joaquín Mª López Muñoz 27 Jun '04

27 Jun '04

I've just finished an article for publication in CUJ about Boost.MultiIndex (they accepted the preliminary proposal.) The author guidelines suggest that a couple of technical peers do a review of the text before submission (specifically, the purpose is that the peers "can give you candid feedback regarding accuracy and adherence to standard industry practices".) So, I kindly request some volunteer wanting to do the job. The review shouldn't be too time-consuming (about 3,000 words of text.) I guess someone without prior exposure to the library is a better candidate, so as to probe the introductory quality of the article. Due to (c) issues I guess I cannot just put the article on the web for you to download. If you are interested, please contact me privately and I'll send you the text. Thanks very much for your help. Regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

Re:BOOST_STATIC_ASSERT(false) - was (no subject)
by Robert Ramey 27 Jun '04

27 Jun '04

I hadn't considered Michaels idea. I've been using BOOST_STATIC_ASSERT(0 == sizeof(T)). Michiel Salters wrote: >Robert Ramey wrote: >> BOOST_STATIC_ASSERT(false) >This *should* work. IMHO, if it doesn't, we should fix it, not work >around it like Michiel suggested. I don't think I'ts fixable. But maybe one might want to make another macro named something like BOOST_BETTER_NOT_ARRIVE_HERE - lol >> 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: >Which compiler and which version of boost and the Compiler are you >using? Can you provide a minimal but complete example? Also, you might >want to have a look at checked_delete where we had similar problems in >the past IIRC. I've noticed it at least on Comeau. I just used the fix above so now I don't see it. So now I don't know which compilers complain. Robert Ramey

2 1

newbie question: Cannot open include file: 'boost/filesystem/operations.hpp': No such file or directory
by Chris 27 Jun '04

27 Jun '04

Hi to all.. sorry for the newbie question. I believe I have built the Boost libs correctly. I used: bjam -s"TOOLS=vc7.1" -s"VC71_ROOT=C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7" install The Includes and Libs are in C:\Boost as described in the "Getting Started Guide" Also I didn't get any errors during the building process (that's why I assume the build was succesfull), so I decided to test the libraries and just took one of the examples form the site. Compiled it and got the: "fatal error C1083: Cannot open include file: 'boost/filesystem/operations.hpp': No such file or directory" #include "boost/filesystem/operations.hpp" #include "boost/filesystem/path.hpp" #include <iostream> namespace fs = boost::filesystem; int main( int argc, char* argv[] ) { //removed for brevity... } I also added the path to the environmental variables in windows, under INCLUDE and LIB, but this didn't seem to change anything. Can anyone help me understand why the compiler doesn't find the headers? What am I missing? Thank you in advance for your help... Chris PS. I am really sorry for the newbie question....

2 1

Problems with conditions in boost::thread
by Andreas Pokorny 27 Jun '04

27 Jun '04

Hi, I just started to use boost::thread in a bigger application. Since the condition variables do not work as expected - e.g. the waiting thread never wakes up ( example can be found here: http://svn.zynot.org/svn/zynot/projects/xeta/trunk/source/src/xeta/curl.cpp ) - I started writing a smaller test case to see if I use the library correctly. That little test application works fine if I run it in with the gnu debugger, and if I have debugging symbols in my glibc. In all other cases the process gets terminated before any debuging print outs show up or the debugger fails to run the application: #include <list> #include <iostream> #include <boost/bind.hpp> #include <boost/thread/xtime.hpp> #include <boost/thread/thread.hpp> using namespace boost; struct Mini { bool running; thread worker; mutex list_mutex; condition items_empty; std::list<std::string> items; typedef mutex::scoped_lock lock; Mini(); ~Mini(); void run(); void add( std::string const& item); }; Mini::Mini() : worker( bind( &Mini::run, this ) ) { } Mini::~Mini() { running = false; { lock the_list( list_mutex ); items_empty.notify_one(); } worker.join(); } void Mini::run() { running = true; while( running ) { lock the_list( list_mutex ); if( running && items.empty() ) { std::cout << "Waiting for item" << std::endl; items_empty.wait( the_list ); std::cout << "Continue" << std::endl; } std::cout << "Removing :" << items.front() << std::endl; items.pop_front(); } } void Mini::add( std::string const& item ) { lock list_access( list_mutex ); std::cout << "Adding :" << item << std::endl; items.push_back( item ); std::cout << "Notifying other thread" << std::endl; items_empty.notify_one(); } int main() { Mini my_mini; my_mini.add("Once upon a time"); my_mini.add("there was a little mouse"); my_mini.add("that lived in a little house"); xtime xt; xtime_get(&xt, TIME_UTC); xt.sec += 2; thread::sleep(xt); } After that I tried to do it without boost. This time everything works as expected, with and without debugger. #include <list> #include <unistd.h> #include <iostream> #include <pthread.h> struct Mini { bool running; pthread_t worker; pthread_mutex_t mutex; pthread_cond_t not_empty; std::list<std::string> items; Mini(); ~Mini(); static void * call_run( void *); void run(); void add( std::string const& item); }; void* Mini::call_run( void * ptr) { static_cast<Mini*>(ptr)->run(); return 0; } Mini::Mini() { pthread_mutex_t temp_mut = PTHREAD_MUTEX_INITIALIZER; mutex = temp_mut; pthread_cond_t temp_cond = PTHREAD_COND_INITIALIZER; not_empty = temp_cond; worker = pthread_create( &worker, 0, Mini::call_run, this ); } Mini::~Mini() { running = false; { pthread_mutex_lock( &mutex ); pthread_cond_broadcast( &not_empty ); pthread_mutex_unlock( &mutex ); } pthread_join( worker, 0 ); pthread_cond_destroy( &not_empty ); } void Mini::run() { running = true; while( running ) { pthread_mutex_lock( & mutex ); if( running && items.empty() ) { std::cout << "Waiting for item" << std::endl; pthread_cond_wait(&not_empty, &mutex); std::cout << "Continue" << std::endl; } std::cout << "Removing :" << items.front() << std::endl; items.pop_front(); pthread_mutex_unlock( &mutex ); } } void Mini::add( std::string const& item ) { pthread_mutex_lock( & mutex ); std::cout << "Adding :" << item << std::endl; items.push_back( item ); std::cout << "Notifying other thread" << std::endl; pthread_cond_broadcast(& not_empty); pthread_mutex_unlock( &mutex ); } int main() { Mini my_mini; my_mini.add("Once upon a time"); my_mini.add("there was a little mouse"); my_mini.add("that lived in a little house"); sleep(2 ); } Any ideas?

2 2

Autolinking problem on Intel (Win32) with STLport
by Doug Gregor 26 Jun '04

26 Jun '04

It looks like there is a problem with autolinking as mentioned in the subject. It looks like a library naming issue: http://tinyurl.com/2djmv Doug

2 2

How to use boost::thread::condition
by Andreas Pokorny 26 Jun '04

26 Jun '04

Hi, I have problems understanding how mutexes, scoped locks and conditions should work togehter. I took the condition.cpp example and with the buffered shared by two threads as a basis of my code: http://svn.zynot.org/svn/zynot/projects/xeta/trunk/source/src/xeta/curl.cpp There is a list filled by one thread, and a thread that removes the entries after they have been downloaded using curl. The worker-thread waits for a jobs_empty condition and the insertion method calls notify_one after every insertion. Currently the worker-thread just prints "Sitting and waiting", and never reacts on any calls of notifiy_one(). Regards Andreas Pokorny

1 1

BOOST_WORKAROUND in test files?
by Gennaro Prota 26 Jun '04

26 Jun '04

Hi, is it allowed/OK to use BOOST_WORKAROUND in the boost test files? Or should we simply use #if/#ifdef? For instance, Codewarrior 8.3 for Windows has some problems in parsing a function template in dyn_bitset_unit_tests4.cpp. A simple fix, suggested by Howard, is: #ifdef __MWERKS__ // will be: __MWERKS__ && __MWERKS__ <= xxx #pragma parse_func_templ off #endif Should this use BOOST_WORKAROUND? In general: What should compiler/library vendors see when they define BOOST_STRICT_CONFIG? Just errors in the boost headers or errors in the test files too? -- Genny.

2 1

intrusive_ptr: proposal for common base class
by Stefan Slapeta 26 Jun '04

26 Jun '04

Hi all, Sorry if this has been discussed yet, but I think there is an obvious pattern in the usage of intrusive_ptr which should be exposed as common functionality in boost. In most of the cases you just want to handle a simple reference count and delete the object which is held by the intrusive_ptr when the reference count is decreased to zero. It's very annoying that you currently have to write external add_ref/release functions for every class you want to use with this smart pointer. Additionaly, it makes the code unreadable. That's why I would like to suggest having a base class which provides the simplest functionality a user could expect from intrusive_ptr: handling the reference count and deleting the object. A class which should be maintained by intrusive_ptr can derive from it and would not have to provide any further interfaces. I'm not glad about the class name 'intrusive_ptr_base' but I don't have any good ideas at the moment :( Awaiting you comments! (code: see below) Stefan namespace boost { class intrusive_ptr_base; void intrusive_ptr_add_ref(intrusive_ptr_base*); void intrusive_ptr_release(intrusive_ptr_base*); class intrusive_ptr_base { friend void intrusive_ptr_add_ref(intrusive_ptr_base*); friend void intrusive_ptr_release(intrusive_ptr_base*); int ref_count__; protected: intrusive_ptr_base() : ref_count__(0) {} virtual ~intrusive_ptr_base() {} }; inline void intrusive_ptr_add_ref(intrusive_ptr_base* o) { ++o->ref_count__; } inline void intrusive_ptr_release(intrusive_ptr_base* o) { if (--o->ref_count__ == 0) { delete o; } } } // namespace

2 2

Hmmm.. how do I add a new test to the regressions?
by Fernando Cacciola 26 Jun '04

26 Jun '04

I forgot it.... I need to add the Numeric Conversions Library so I can start hunting compiler problems. Fernando Cacciola SciSoft

2 1

RE: Boost.Threads proposed change: lock constructors
by Batov, Vladimir 25 Jun '04

25 Jun '04

Mike, With all due respect I am not sure that the additional complexity you are proposing is justified. It appears that the differences in lock and try_lock default constructors' behavior are consistent with other libraries and actually feel intuitive and natural to me. After all, it is reflected in what I do -- with lock I try until I succeed (that is [Batov, Vladimir] the lock blocks until succeeds), with try_lock I try once and may fail (that is it unconditionally falls through for me to check the result). Best, V. Date: Thu, 24 Jun 2004 14:14:02 -0400 From: Michael Glassford <glassfordm(a)hotmail.com> Subject: [boost] Boost.Threads proposed change: lock constructors To: boost(a)lists.boost.org Message-ID: <cbf5as$hvv$1(a)sea.gmane.org> Content-Type: text/plain; charset=us-ascii; format=flowed Below I detail proposed changes to the Boost.Threads lock class constructors. Comments? Questions? Mike ----------------------------------------------------------------- The Boost.Threads lock concept constructors are currently defined as follows: Definitions ----------- L: lock type l: lock variable (type L) m: mutex variable (appropriate Mutex type) s: initial lock state (type bool, true=locked, false=unlocked) Lock Concept ------------ L l(m,s) //Blocking lock if s L l(m) //Blocking lock TryLock Concept --------------- L l(m,s) //Blocking lock if s L l(m) //Non-blocking lock TimedLock Concept ----------------- L l(m,s) //Blocking lock if s L l(m,t) //Blocking lock, failing if not obtained by time t These definitions have the following drawbacks: 1) That one of the TryLock constructors blocks while the other doesn't is neither obvious nor very consistent. 2) That the single-parameter constructor of Lock blocks while the single-parameter constructor of TryLock doesn't is neither obvious nor very consistent. 3) Part of the reason for the above inconsistencies is that it's not clear whether the constructors of TryLock should block or not. 4) The TimedLock constructors have no way to request a non-blocking lock. To address these problems, I would like to redefine the lock concept constructors as follows (changes indicated with "^"): Definitions ----------- L: lock type l: lock variable (type L) m: mutex variable (appropriate Mutex type) s: initial lock state (enum type {NO_LOCK=0, LOCK=1}) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ b: block? (enum type blocking_state {NON_BLOCKING=0, BLOCKING=1}) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Lock Concept ------------ L l(m,s) //Blocking lock if s L l(m) //Blocking lock TryLock Concept --------------- L l(m,s,b) //Lock if s; blocking if b ^ ^^^^^^^^^^^^^ L l(m,b) //Lock; blocking if b ^ ^^^^^^^^^^^^^ TimedLock Concept ----------------- L l(m,s,b) //Lock if s; blocking if b ^ ^^^^^^^^^^^^^ L l(m,t) //Blocking lock, failing if not obtained by time t Note: s and b are defined as enums rather than bools to prevent existing code from breaking silently: e.g., if s and b were bools, "TryLock l(m, false)", which currently means "construct a lock object but don't obtain a lock", would change with the new definitions to mean "construct a lock and make a non-blocking attempt to obtain a lock". Also, enums are more explicit than bools. Note: these changes will cause some existing code to break by producing compile errors; the compile errors can be fixed by appropriately adding or changing parameters being passed to the changed TryLock and TimedLock constructors. Mike

2 1

Regression logs oddity
by Gennaro Prota 25 Jun '04

25 Jun '04

Hi everybody, does anyone have hints as to why the Linux regression logs include the first 3 dynamic_bitset test files twice, in two different versions? Example: gcc-3.4.0- linux 3.4.0 ------------------------------------------------------------------- dyn_bitset_unit_tests1 Fail dyn_bitset_unit_tests1 Pass dyn_bitset_unit_tests2 Fail dyn_bitset_unit_tests2 Pass dyn_bitset_unit_tests3 Fail dyn_bitset_unit_tests3 Pass dyn_bitset_unit_tests4 Pass -- Genny.

2 1

dynamic_any campaign?
by fehrin＠t-online.de 25 Jun '04

25 Jun '04

On http://www.cuj.com/boost/ (Boost Corner) the first article is I/O System: dynamic_any campaign by Alexander Nasonov. Is dynamic_any really scheduled for inclusion in boost (1.32 say)? Greetings Franz

3 2

Re:[boost] 1.32 release preparation
by Robert Ramey 25 Jun '04

25 Jun '04

I would very much like to see the serialization library in the 1.32 Release. However, I'm not sure it will be possible to make the posted schedule. I have made all changes to address issues raised in the review. On my personal machine I have passed tests for the compilers VC 7.1 VC 6, gcc 3.3. Borland compiles (almost everything but requires some debug - it will pass most tests) Comeau- compiles everthing - accept for a show stopping problem I've been unable to resolve. My intention has been: a) post version compatible with 1.31 next week. b) build and test against the CVS tree on my computer c) check in In order to do this I need: a) authority to check in b) information on how to mark tests/compilers known to fail. c) I have a couple of questions that I need an expert opinion on. i) the first one is that in order to work, versions for vc 6.0 and borland need to be compiled with spirit 1.61. So the a special environmental variable indicating the directory path where this version of spirit is located on the testing machine. SPIRIT_ROOT. This variable has to be set when serialization libraries are built for these compilers. I should say I'm more than a little bit concerned about changes to mpl and iterators. I'm very much aware of the delays and difficulties associated with the 1.31 release - and it didn't even include this package. So I would like to continue on the path I've established above and we'll see where things stand July 16 when/if you are ready to branch for release. Good Luck ! Robert Ramey

4 4

Random number library
by Oliver Kullmann 25 Jun '04

25 Jun '04

Hi, one of my students tried some time in vain to use the random number generator from the boost library, but he couldn't understand the documentation. I must say, the documentation is not exactly "user-friendly". Here's the problem: Given integers min and max, we want to have a pseudo-random-number generator for random numbers from min, min + 1, ..., max (uniform distribution). The generator should take a seed, and then producing a sequence of pseudo-random numbers (and we should be able to find out about the period of the generator). I couldn't think of anything more basic for a library on random numbers, and so I would expect an example of how to get such a thing in the documentation. (I mean, a real example, complete with code, explanations, and how to use it.) But there's no such a thing, which I find rather strange. We have the concept of a "Uniform Random Number Generator", which looks exactly what we want, but, alas, it seems to be more of a fictitious concept, since no models seem to be provided?!?! So well, let's have a look at "Random Distribution". Only that it needs as input a "Uniform Random Number Generator", and the library does not seem to provide these things?!?! (We have the "Random Number Library Generators", but this library seems to provide only models for the most general concept, the concept of a "Number Generator", but not of a "Uniform Random Number Generator".) Let's ignore this for a moment, and continue our investigations into "Random Distribution". Here are actually some models, most useful for our purpose seems to be "Class template uniform_smallint" and "Class template uniform_int". Now, even if we would know where to get the argument urng from, still we wouldn't know which to choose: The documentation on these class templates is rather cryptic, and additionally asks us to be "wise". Shouldn't this be the job of the library?! Final rescue: "random_demo.cpp". The macros don't enhance readability. But there is an example "Define a uniform random number distribution of integer values between // 1 and 6 inclusive." where I find the text misleading (since we don't define a distribution, which is an assignment of probabilities to certain events, but we define a generator), but looking at the output of the program experiment: roll a die 10 times: 3 3 2 6 6 5 5 6 6 3 it seems to be what we want. So I could copy and past the relevant parts of the program (which is not completely trivial), and I would get close to my goals. If only I would understood the meaning of what I'm doing! Unfortunately, variate_generator.hpp seems to be of some importance, but is not documented. Sigh. --------------------------- My student didn't get to this point, although he is rather good. But there are too many unknowns in the "equation" to solve (starting with the concept of a concept, ...), so the job becomes overwhelming. Now it doesn't look too complicated for me to write a nice explanation for the above problem in a tutorial style, explaining on the way all the concepts and concepts of concepts in the library, and that's what I wanted to kindly request with my e-mail. (And also the rest of the documentation could need a sentence here and there, as mentioned in the above case study.) And, of course, for any example of the best way how to solve the above problem with the library, and explanations how it works, I would be glad! Oliver

4 9

boost::any debug assertion failed in destructor
by Olivier Tristan 25 Jun '04

25 Jun '04

Hi guys, I'm currently trying got use boost::any to create some container with different type and I'm having some trouble with a small exemple. I try this on VC2003, VC2002 and gcc 3.3 Here is my class class A { public: A(unsigned long size) : mSize(size), mBuffer(new boost::any[size]) {} ~A() { delete mBuffer; } private: unsigned long mSize; boost::any *mBuffer; }; int main(void) { A(256); return 0; } and I got an assertion in the destructor of A; Can someone tell me if I did something wrong or if there is some problem is boost::any Thanks, -- Olivier Tristan Ultimate Sound Bank

2 2

[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