- Boost - lists.boost.org

multi_array is a BasicMatrix
by Andreas Fabri 02 May '05

02 May '05

Hello, I seems that the MultiArray is a refinement of the concept BasicMatrix At least its model multi_array compiles when used with johnson_all_pairs_shortest_paths which needs a model of BasicMatrix Not being actively involved in the boost projects, I am wondering how the community is organized to add this to the documentation. best regards, andreas

2 1

free_on_error
by Jason Hise 02 May '05

02 May '05

Does a utility like the following already exist in boost? If so, what is it called? If not, is there interest in adding it? template < typename Function > struct free_on_error { private: Function function_; bool reset_; public: free_on_error ( Function function ) : function_ ( function ), reset_ ( true ) { } ~ free_on_error ( ) { if ( reset_ ) { function_ ( ); } } void discard ( ) { reset_ = false; } }; This would be used to make certain operations exception safe. For example: A * foo ( ) { A * a = new A ( ); free_on_error < BOOST_TYPEOF ( lambda::bind ( delete _1, a ) ) > release ( lambda::bind ( delete _1, a ) ); a->DoSomethingThatMightThrow ( ); release.discard ( ); return a; } (my experience with lambda is minimal, so I'm not sure that delete _1 creates a valid lambda functor, but you get the idea) -Jason

5 5

[bcp] trapping invalid boost path
by Andy Little 02 May '05

02 May '05

Hi, having tried out bcp in WinXp I was fooled for some time by not entering the correct boost path at the command line, when the app silently fails. Therefore I wonder if testing for invalid boot path would improve things. Something like the following patch in cpp_main in file main.cpp seems to work: cpp_main(int argc, char* argv[]) .... else if(0 == std::strncmp("--boost=", argv[i], 8)) { const char* boost_path = argv[i] + 8; if(boost::filesystem::exists(boost_path)){ papp->set_boost_path(boost_path); } else{ std::string msg("ERROR boost path : "); msg += boost_path msg += " is invalid\n"; throw std::runtime_error(msg); return 0; } } ... } regards Andy Little

2 1

lambda bind breaks VC 7.1
by Jason Hise 02 May '05

02 May '05

For some reason, it seems that whenever I type '(' after boost::lambda::bind (which would normally cause the intellisence list to pop up with the arguments the function takes), visual studio completely locks up. Does anyone else have this problem? Are there known fixes or work-arounds? -Jason

5 4

Re: [boost] broken links in ublas doc
by Michael Stevens 02 May '05

02 May '05

> Several of the ublas doc pages reference the file: > libs/numeric/ublas/doc/c++boost.gif which does not in fact exist, I assume > these links should point to boost.png now? Any chance of the authors fixing > this up? Fixed. Thanks, Michael ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

1 0

[threads] Improvement idea #1: Lock constructors [long]
by Michael Glassford 02 May '05

02 May '05

I've been mentioning that I have some ideas about improvements for Boost.Threads. I intend to bring up these ideas one at a time for discussion. I'm particularly interested in finding out: 1) Whether people think that the idea would be an improvement. 2) If so, suggestions for improving the idea even more. The first idea has to do with the long discussion that occured some time back about the lock class--in particular, its constructors. There were several ideas about whether lock constructors should make the full range of lock, try_lock, and timed_lock functionality available and, if so, how; I don't recall any consensus being reached. I experimented for a while with a series of template classes that would allow a user to choose whatever interface they wanted, but another idea has occured to me since then that I don't remember being mentioned anywhere (if I'm wrong, my apologies to whoever mentioned it): to eliminate the locking contructors altogether. In this scheme, a lock object would no longer be responsible for locking a mutex, only for unlocking it. Instead, a mutex object would lock itself and transfer ownership of the lock to a lock object by way of a lock_transfer object. A sample of what the classes would look like and their usage is given at the end of this message. Some advantages I see to this approach: #1: it simplifies the lock class and allows it to be used to lock any costructor, no matter what its type (it can own a lock to an exclusive mutex, an exclusive lock to a shared_mutex, or a shared lock to a shared_mutex). #2: instead of the following, which in my mind leaves an ambiguity of whether the mutex should be unlocked, shared-locked, or exclusive-locked at the end: shared_lock l1(shared_mutex, SHARED_LOCK); ... { exclusive_lock l2 = l1.promote(); ... } It is possible to write this, which removes the ambiguity: lock l = shared_mutex.shared_lock(); ... l = shared_mutex.promote(l.transfer()); ... Comments? Mike //------------------------------ //Exclusive mutex usage examples //------------------------------ mutex_type m; lock_type l; //Create lock object that doesn't lock anything lock_type l = m.lock(); //Create lock object and lock mutex m lock_type l = m.try_lock(); //Create lock object and conditionally lock mutex m lock_type l = m.timed_lock(xxx); //Create lock object and conditionally lock mutex m l = m.lock(); //Lock mutex m (first unlocking whatever mutex l was previously locking, if any) l = m.try_lock(); //Conditionally lock mutex m (first unlocking whatever mutex l was previously locking, if any) l = m.timed_lock(xxx); //Conditionally lock mutex m (first unlocking whatever mutex l was previously locking, if any) l = other_lock.transfer(); //Transfer the lock from one lock object to another l.unlock(); //Unlock whatever mutex is locked (throw exception if nothing is locked) l.is_locked(); //Is l locking a mutex? //NOT ALLOWED: l.lock(), l.try_lock(), etc.; //------------------------------ //Shared mutex usage examples //------------------------------ lock_type l; //Create unlocked lock object lock_type l = m.lock(); //Create lock object and lock mutex m lock_type l = m.try_lock(); //Create lock object and conditionally lock mutex m lock_type l = m.timed_lock(xxx); //Create lock object and conditionally lock mutex m lock_type l = m.shared_lock(); //Create lock object and shared-lock mutex m lock_type l = m.shared_try_lock(); //Create lock object and conditionally shared-lock mutex m lock_type l = m.shared_timed_lock(xxx); //Create lock object and conditionally shared-lock mutex m l = m.lock(); //Lock mutex m (first unlocking whatever mutex l was previously locking, if any) l = m.try_lock(); //Conditionally lock mutex m (first unlocking whatever mutex l was previously locking, if any) l = m.timed_lock(xxx); //Conditionally lock mutex m (first unlocking whatever mutex l was previously locking, if any) l = m.shared_lock(); //Shared-lock mutex m (first unlocking whatever mutex l was previously locking, if any) l = m.try_shared_lock(); //Conditionally shared-lock mutex m (first unlocking whatever mutex l was previously locking, if any) l = m.timed_shared_lock(xxx); //Conditionally shared-lock mutex m (first unlocking whatever mutex l was previously locking, if any) lock_type l = other_lock.transfer(); l = other_lock.transfer(); l = m.promote(l.transfer()); l = m.try_promote(l.transfer()); l = m.timed_promote(l.transfer(), xxx); l = m.demote(l.transfer()); l = m.try_demote(l.transfer()); l = m.timed_demote(l.transfer(), xxx); l.unlock(); //Unlock whatever mutex is locked (throw exception if nothing is locked) l.is_locked(); //Is l locking a mutex? //NOT ALLOWED: l.lock(), l.try_lock(), etc.; //------------------------------ //Class definitions //------------------------------ class lock_transfer { public: //Used to return ownership of a lock from a mutex or //to transfer ownership of a lock from one lock object to another lock_transfer(...) {...} ~lock_transfer() { //unlock the mutex if ownership of the lock //hasn't been taken by a lock object } ... }; class lock { public: lock(void) { //create lock object that doesn't lock any mutex ... } lock(lock_transfer& transfer) { //copy necessary information out of transfer ... } ~lock() {if (is_locked()) unlock();} lock_transfer transfer(void) { ... } void unlock(void) { //unlock the mutex ... } bool is_locked(void) { ... } }; class mutex { public: mutex(void); ~mutex(); lock_transfer lock(void); //lock the mutex and return a lock_transfer lock_transfer try_lock(void); lock_transfer timed_lock(...); ... }; class shared_mutex { public: mutex(void); ~mutex(); lock_transfer lock(void); lock_transfer try_lock(void); lock_transfer timed_lock(time t); lock_transfer shared_lock(void); lock_transfer try_shared_lock(void); lock_transfer timed_shared_lock(time t); lock_transfer demote(lock_transfer& exclusive_lock); lock_transfer try_demote(lock_transfer& exclusive_lock); lock_transfer timed_demote(lock_transfer& exclusive_lock, time t); lock_transfer promote(lock_transfer& shared_lock); lock_transfer try_promote(lock_transfer& shared_lock); lock_transfer timed_promote(lock_transfer& shared_lock, time t); ... };

4 14

[ios_state] CodeWarrior and many errors because of locale..
by Rene Rivera 02 May '05

02 May '05

As others have pointed out there were a number of "mysterious" errors having to do with multiply defined symbols during link. The problem was in the Boost.Test library which was indirectly relying on std::locale support. The indirect part is that it's using boost/io/ios_state.hpp which *assumes* that std::locale is available. Anyway.. I've checked in changes to make ios_state.hpp compile in the face of missing locale support. Basically I just conditionally remove the part that use std::locale based on the BOOST_NO_STD_LOCALE config macro. I also removed the Boost.Test change that causes the multiple symbols. I don't know how many libraries and compilers this affects. But if you are running incremental tests, expect your next run to be considerably longer as it's going to recompile Boost.Test. Which will likely recompile everything else. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

1 0

[boost.range] cw 8.3 test
by Thorsten Ottosen 02 May '05

02 May '05

Hi, Does anyone know why the output from cw8.3 is so wierd: http://tinyurl.com/77hhw ? Thanks -Thorsten -- Thorsten Ottosen ---------------------------- www.dezide.com http://www.cs.aau.dk/index2.php?content=Research/mi www.boost.org www.open-std.org/JTC1/SC22/WG21/

2 1

[como working with boost.test and more]
by Thorsten Ottosen 02 May '05

02 May '05

Thanks to those responsible for getting como to work again on the cvs with test and type-traits being problematic lately. It saves me a great deal of time when I can ask como to pick up the stupid errors in my source. best regards Thorsten -- Thorsten Ottosen ---------------------------- www.dezide.com http://www.cs.aau.dk/index2.php?content=Research/mi www.boost.org www.open-std.org/JTC1/SC22/WG21/

3 2

building container on stack (var arg)
by Eric Zijlstra 02 May '05

02 May '05

I was looking for a convinient way to have variabele arguments for functions and avoiding the memory allocations and copying that come with std containers. I didn't find such a container so I hacked one together myself. The container builds a linked list by storing pointers to the arguments in temporary node objects (StackArg). The list becomes invalid as soon as the nodes go out of scope. A test showed that this was 5 times faster than using a std::vector. I don't have access to the code ATM, but look below how it looks like (very shortend). Ofcourse, the + operator is misleading (the leading empty StackArg<>() clarifies a lot) but otherwise it's pretty convinient. template<class T> class StackArg { public: StackArg *link; T *data; StackArg() link(0), data(0) {} StackArg(StackArg *prev, T *t) :link(prev), data(t) { } StackArg operator + (T &t) { return StackArg(this, &t); } iterator begin(); iterator end(); }; The first time when begin() or end() is called, the list is reversed because since operator+() is evaluated from left to right, the last element becomes the container handle (s in code below). // usage example: void print(StackArg<const int> s) // outputs 345 { StackArg<const int>::iterator i= s.begin(), e=end(); while(i!=e) cout << *i++; } void test() { print( StackArg<const int>() + 3 + 4 +5 ); }

2 2