April 2005 - 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

[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

[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

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

Steps before moving to Subversion
by Beman Dawes 01 May '05

01 May '05

Dave Abrahams, Doug Gregor, Thomas Witt and I talked about moving to Subversion when we got together at the C++ committee meeting last week. (I've been using Subversion on my machine for about a month, and quickly became convinced it is superior to CVS.) Points discussed included the importance of a slow, step-by-step approach, because of the importance to Boost and to individual developers, and the need to build familiarity before diving in head first. Doug Gregor will lead the effort, and will be the contact at IU when issues arise. Hopefully Troy Straszheim can help, given that he has already setup a Boost SVN repository. Some of the possible tasks to be accomplished before a final conversion: * Research any remaining questions from Boosters regarding Subversion. * Decide on the repository directory structure - follow Troy's lead or maybe something else? (One of the advantages of Subversion is that the repository directory structure isn't hard-wired, but that means we have to decide which approach is best.) * Set up a trial repository, like the one Troy set up, but on the actual machine at IU. * Set up write authorization. This might be a good time to prune the write-access list to those still active. * Load test. (Maybe set a time, and have a bunch of Boosters hit the repository at the same time?) * Make final go/no-go decision. This probably involves both discussion on the list and polling the moderators (as the closest thing we have to a steering committee.) * Put change notifications in place. * Verify that backup (tarball or whatever) procedures are in place and functioning. * Update Boost documentation which refers to the source repository. * Schedule and execute the actual changeover. Comments? --Beman PS: The book "Version Control with Subversion" by Collins-Sussman, Fitzpatrick, and Pilato, is worthwhile, either in hard copy (O'Reilly) or download from http://svnbook.red-bean.com/

14 28

Re: [boost] Re: [test][comeau] problem with va_list
by JOAQUIN LOPEZ MU?Z 01 May '05

01 May '05

----- Mensaje original ----- De: Edward Diener <eddielee(a)tropicsoft.com> Fecha: Miércoles, Abril 27, 2005 10:25 pm Asunto: [boost] Re: [test][comeau] problem with va_list > JOAQUIN LOPEZ MU?Z wrote: > > Current tests for Comeau 4.3 show this problem: > > > > "G:\boost\boost/test/impl/test_tools.ipp", line 136: error #135: > > namespace > > "std" has no member "va_list" > > std::va_list args; > > > > Looks like va_list is not properly injected into std:: > > (yet BOOST_NO_STDC_NAMESPACE is *not* defined > > for this platform, and I guess for a good reason.) > > I've googled for this and found some discussions at the > > Boost list on the very same problem, with no definitive > > answer :( > > > > 1. Could anyone take a look at Comeau stdlib <cstdargs> > > and see what's going on? > > It is <cstdarg>, and in libcomo for Comeau 4.3.3 I see: > > #include <stdarg.h> > > namespace std { > > using ::va_list; > > } > > Comeau uses the back end compiler for the C headers, such as > stdarg.h, > although it provides a few of its own for various compilers > evidently to > make up for some compiler deficiences. I do not see any stdarg.h > among > the latter. What is the back end compiler being used for the > failing test ? > VC 7.1. The offending file seems pretty straightfoward (http://tinyurl.com/e27be) so I don't really have a clue what's going on... Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 12

Boost.Test and gcc-2.95
by John Maddock 01 May '05

01 May '05

I don't know if the following are fixable or not, but there are a few regex lib tests failing on gcc-2.95 with: In file included from /boost/head-regression/boost/boost/test/included/test_exec_monitor.hpp:27, from ../libs/regex/test/object_cache/object_cache_test.cpp:19: /boost/head-regression/boost/boost/test/impl/unit_test_log.ipp: At top level: /boost/head-regression/boost/boost/test/impl/unit_test_log.ipp:37: redefinition of `struct io_saver_type' /boost/head-regression/boost/boost/test/impl/results_reporter.ipp:35: previous definition here /boost/head-regression/boost/boost/test/impl/unit_test_log.ipp:40: confused by earlier errors, bailing out Given that this is an old compiler can these be fixed without undue heroics? Thanks, John.

2 2

Re: [boost] Re: [test][comeau] problem with va_list
by JOAQUIN LOPEZ MU?Z 30 Apr '05

30 Apr '05

----- Mensaje original ----- De: Bronek Kozicki <brok(a)rubikon.pl> Fecha: Viernes, Abril 29, 2005 6:36 pm Asunto: Re: [boost] Re: [test][comeau] problem with va_list > Quoting Edward Diener <eddielee(a)tropicsoft.com>: > > For whatever reason, although #include <cstdarg> is in the > source file, > > when the Comeau compiler is executed it never actually includes the > > file. This must be a bug in the Comeau compiler but perhaps Greg > Comeau> has a fix for it. > > Do you have libcomo31 properly installed and built? Did you try > "Hello world" > using iostreams? > > Broneck, if I'm not wrong you have access to a properly setup Comeau environment. It'd be great if you could apply a patch to your local version of boost/test/impl/test_tools.ipp and see what happens. The patch reduces to issuing a namespace std{using ::va_list;} for the Comeau compiler. If this works, a lot of tests that are currently failing because of this single problem could clear up (or at least progress to some further error.) If the patch works, there's still the issue of tuning the workaround: is it a problem with all versions of stdlibcomo, under any backend? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 5

Re: [boost] Re: Re: [test][comeau] problem with va_list
by JOAQUIN LOPEZ MU?Z 30 Apr '05

30 Apr '05

----- Mensaje original ----- De: Gennadiy Rozental <gennadiy.rozental(a)thomson.com> Fecha: Sábado, Abril 30, 2005 8:32 pm Asunto: [boost] Re: Re: [test][comeau] problem with va_list > > 1. Replace <cstdarg> with <stdarg.h> > > 2. Remove std:: qualifications for all entities belonging > > to <cstdarg> > > Done. Committed in cvs. > > Gennadiy Thank you! Let's see if this improves regression results on the next turnaround. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0