- Boost - lists.boost.org

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

Re: range_ex
by Eric Niebler 01 May '05

01 May '05

"Thorsten Ottosen" wrote... > > "Gennadiy Rozental" <gennadiy.rozental(a)thomson.com> wrote... > | > | I believe we should move this discussion into separate thread. > | FOREACH is under review now and range_ex is not even requested yet. > | If we want it to be reviewed the first step in this direction could > | be to request one. > > Then I request a review :-) > > Eric, please just respond privately or in a new thread. > > -Thorsten I don't believe it's ready for that. You may feel you know the answers to those design questions, but I'm less confident, and I would like more feedback. Besides, Dave A. has been working in this space, and if a unified approach to range algorithms can be found, that would be preferable. If no such unified approach can be found, I want to know that it has at least been explored. If you would like to drive the development of range_ex, be my guest. -- Eric Niebler Boost Consulting www.boost-consulting.com

2 1

[ptr_container] missing style sheet in docs.
by John Maddock 01 May '05

01 May '05

The ptr_container docs reference the style sheet libs/ptr_container/doc/style.css, which is not in cvs, is this waiting to be checked in, or should it be using boost.css instead? Thanks, John.

2 1

[MPL] How to Derive from inherit_linearly generated class?
by Rick Sloan 01 May '05

01 May '05

Hello all, Given a mpl::list typedef mpl::list<structA, structB, structC> typeList; and a wrapper struct template <class T> struct wrap { virtual void someFunction(T&) = 0; virtual ~wrap } You can generate a class by mpl::inherit_linearly<typeList, mpl::inherit<wrap<_2>,_1> >:;type generated; This is pretty much straight from "C++ Template Metaprogramming" pg. 193-194. My question is how do you generate the derived concrete class? I can override any particular function by struct Child : public generated { virtual void someFunction(structA&); } but I can't seem to generate an entire class. I apologize if this is a newbie question, but alas I am a newbie to template metaprogramming. Regards, Rick Sloan

1 0