- Boost - lists.boost.org

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