- Boost - lists.boost.org

How to handle name mangling in "versioned" toolsets?
by John Maddock 28 Jun '04

28 Jun '04

At present we have two types of toolsets: 1) Unversioned toolsets such as "intel-win32", which produce unversioned toolset suffixes to library names, "iw" in this case. 2) Versioned toolsets such as "intel-win32-7.1-vc6-stlport-4.5.3" which produce versioned toolset suffixes to library names, "iw71" in this case. This produces a problem with the autolinking code which can take either approach, but not both (or at least not both auto-magically, and this is causing some regression test failures at present). In other words I'm asking for some kind of consistent policy here; note that if the choice is to consistently use "versioned" toolsets then we're committing ourselves to constantly updating the build system and autolinking code to keep up with new compiler releases. So, I guess I'm leaning towards "unversioned" mangled toolset names, but would like more some feedback, so: what does everyone else think? Thanks, John.

3 2

Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 28 Jun '04

28 Jun '04

My question was more about the design rather than how I could work it around. I may be wrong but specializing mutex does not look like a good idea as it appears to be lock-specific functionality. So, I thought we might consider having only mutex and typedefing others to it (not to break old code) -- the simpler the better. Isn't it? V. > Do we need all three separate concepts -- mutex, try_mutex and > timed_mutex? I think the idea was that it would be possible to implement the mutex types that supported fewer operations more efficiently. Whether this actually turned out to be true is another question. > I'd expect the mutex concept to remain unchanged and "try" > and "timed" refinements to be related solely to the ways I try locking > that only mutex. That is, I always have one mutex and under different > circumstances lock it unconditionally (scoped_lock) or try locking it > and check if that attempt succeeds (scoped_try_lock) or try locking > within a certain time period (scoped_timed_lock). If you want this, just use a timed_mutex and scoped_timed_lock. In the current release it supports lock() and timed_lock() operations; in the next release it will support try_lock() as well. Mike ------------------------------ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost End of Boost Digest, Vol 772, Issue 2 *************************************

1 0

GCC 3.4 lpthread warnings
by Jeff Garland 28 Jun '04

28 Jun '04

On the regression tests I'm seeing lots of warnings from gcc 3.4. For example: date_time - test_greg_wstream - gcc-3.4.0-linux Compiler output: In file included from /boost/head-regression/boost/boost/config.hpp:44, from /boost/head-regression/boost/boost/date_time/locale_config.hpp:19, from /boost/head-regression/boost/boost/date_time/compiler_config.hpp:14, from /boost/head-regression/boost/boost/date_time/gregorian/gregorian.hpp:19, from ../libs/date_time/test/gregorian/testgreg_wstream.cpp:10: /boost/head-regression/boost/boost/config/stdlib/libstdcpp3.hpp:33:7: warning: #warning "Boost threading support turned on, you may need to link against -lpthread unless you define BOOST_DISABLE_THREADS when building." Lots of other libraries are seeing similar warnings with gcc 3.4. Date-time does nothing with threads so I believe based that I should just set define BOOST_DISABLE_THREADS for the test cases to resolve this. But since I'm not certain of all the implications of this I thought I'd as for advice before proceeding. One specific question that comes to mind is do I need to limit the scope to gcc so I don't break MT, dll mode on Windows? Thanks, Jeff

6 15

[admin] Wiki Spam -- IP's are being banned
by Jeff Garland 28 Jun '04

28 Jun '04

All - I'm cross-posting this to boost-users and the developer list since it pertains to both. Over the last couple months there has been a rise in 'spam attacks' on the Wiki. Basically people are inserting links to commercial sites on wiki pages. These sites are totally unrelated to boost, c++, etc. I thank the many boosters that have spent their precious time removing the defacements. But the time has come to crack down. The following IP ranges have been banned from the Wiki. 61.55.32.* 61.55.33.* 69.63.103.* 210.82.76.* 210.82.106.* 219.233.195.* 218.5.65.* I will be monitoring and banning additional IP addresses as needed. If I have accidentally banned someone incorrectly, please let me know offlist: jeff at crystalclearsoftware.com Thanks, Jeff

1 0

shared_ptr<> and atomic_count
by Colin Rafferty 28 Jun '04

28 Jun '04

Hi- Looking at the implementation of shared_count<>, it seems as though it always uses a mutex for incrementing and decrementing the counter. Is there a reason why we aren't using atomic_count instead? In the worst case, it will have the same performance, but in the best case, it can be significantly faster (BOOST_USE_ASM_ATOMIC_H). Thanks. -- Colin Rafferty

1 0

Re: 1.32 release preparation
by Johannes Brunen 28 Jun '04

28 Jun '04

On Mon, 28 Jun 2004 07:37:24 -0400, David Abrahams wrote > Boost.Graph changes have caused plenty of regressions in Boost.Python > in the past. Sorry, I thougth that this would be a pretty good example of a high level library. So I was wrong. On Mon, 28 Jun 2004 07:33:26 -0400, David Abrahams wrote > We should have more releases. Waiting for libraries to be checked in > is one thing that keeps us from being able to release more frequently. Yes, but if I have the choice of waiting one additional week for the check in of an accepted library against waiting 2 month for the next release I would choose to wait that additional week. However, I have read in one of the other mails that you have a deadline with your book. So live is not that simple at all. I won't persist on changing the planned schedule. Don't get me wrong. > It sounds like you want a whole new Boost procedure for reviews *and* > releases. That seems like a stretch; we don't have any idea whether > it would work at all. No, I merely think that a library should be accepted when it is ready for checkin and there is not a list of changes and request pending. On Mon, 28 Jun 2004 07:34:22 -0400, David Abrahams wrote >> On Mon, 28 Jun 2004 10:51:36 +0200, Johannes Brunen wrotes >> We should list them on the lib page but in a special section. > I don't like the sound of that. It should be very clear to people > which things are part of Boost and which aren't. Ok, I second that. If it not clear for people what is part of boost then it is the wrong way. People should be able to build on a boost release. With kind regards Johannes

1 0

iterator_traits.pdf not marked as binary
by Peter Dimov 28 Jun '04

28 Jun '04

libs/iterator/doc/iterator_traits.pdf is not marked as binary in the CVS. -- Peter Dimov http://www.pdimov.com

2 1

[Graph] What to do about broken compilers?
by Doug Gregor 28 Jun '04

28 Jun '04

The graph library has always been in a "barely usable" support on certain compilers (Borland <= 5.6.4 and MSVC 6.0, in particular). The regression tests have always been a mess---Boost 1.31.0 has very few passes for these compilers, and 1.32.0 isn't looking any better. However, the library is somewhat usable, if you stick to a very small subset and don't mind working around INTERNAL COMPILER ERRORs all of the time. What to do? I'm marking the library "unusable" on both compilers, so that we can concentrate our efforts on those compilers that might actually work. Complain loudly, quickly, and preferably with patches if you think this is the wrong approach. Doug

4 5

Boost.Threads: RW mutexes and locks.
by Batov, Vladimir 28 Jun '04

28 Jun '04

RW mutexes/locks are important to a threading library and appear simple to implement. However, Boost.Threads lacks it. I wrote something simple that appear to do the job using the functionality already available in Boost.Threads. If the idea is considered good/robust/efficient enough and worth having in the library, I can re-write it to conform with the rest of Boost.Threads. class rw_mutex : private boost::noncopyable { typedef boost::condition Condition; public: friend class writer_lock; friend class reader_lock; rw_mutex() : num_readers_(0), num_writers_(0) {} private: boost::mutex mutex_; Condition reader_condition_; Condition writer_condition_; int num_readers_; int num_writers_; }; class writer_lock : public boost::mutex::scoped_lock { typedef boost::mutex::scoped_lock super; public: writer_lock(rw_mutex& mutex) : super(mutex.mutex_), mutex_(mutex) { ++mutex_.num_writers_; // Make new readers wait. // If there are readers in-progress, wait for them to finish. while (mutex_.num_readers_) mutex_.writer_condition_.wait(*this); } ~writer_lock() { --mutex_.num_writers_; // Last writer notifies waiting readers. // If not last, wake up the next writer. if (!mutex_.num_writers_) mutex_.reader_condition_.notify_all(); else mutex_.writer_condition_.notify_one(); } private: rw_mutex& mutex_; }; class reader_lock : public boost::mutex::scoped_lock { typedef boost::mutex::scoped_lock super; public: reader_lock(rw_mutex& mutex) : super(mutex.mutex_), mutex_(mutex) { // If there are writers waiting, let them in first. while (mutex_.num_writers_) mutex_.reader_condition_.wait(*this); ++mutex_.num_readers_; // Make new writes wait. unlock(); } ~reader_lock() { lock(); --mutex_.num_readers_; // Last reader notifies if (!mutex_.num_readers_) mutex_.writer_condition_.notify_one(); } private: rw_mutex& mutex_; };

3 2

Re:[boost] Re: 1.32 release preparation
by Johannes Brunen 28 Jun '04

28 Jun '04

On Sun, 27 Jun 2004 19:05:45 -0700, Robert Ramey wrote > Here is the current scenario. > > a) The announcement gets posted - release 1.32 scheduled for date x. > b) Each developer decides - uh oh I better get in my changes before date x. > c) Of course these changes take longer > d) and break some other things > e) which takes longer still IMHO, point d) touches a weak point: There are two kind of libraries in a system like boost. At first, there are core libraries which are used by many other libraries. Changes at these libraries are potentially dangerous and must be well-considered since they can broke a lot of stuff. They should early checked into CVS to get time for stabelizing the base. Secondly, there are libraries which 'only' provide a special feature like the boost graph library the circular_buffer library. They shouldn't be expected to lead to regressions of other boost libraries. I think that they could be handled differently than the core libraries. > a) the release manager or the core influential developers keep an eye on the > current state of the CVS tree and tests. > b) When things look "pretty good", branch for release without warning. None > of this loading my latest feature in to make the schedule. > c) the Main tree goes on as usual > d) pending issues in the release branch are addressed by nagging the person > responsible. > e) the new version is releases with a number like 1.31.1 or maybe even 28 > July 2004. > f) any changes between branch and release should be just bug fixes which can > then be merged back into the development tree. > > Under this system, releases would occur more frequently - on the order of 6 > weeks. If you're ready to check in your latest feature and the new release > branch catches you with your pants down - well too bad. But it's no big deal > because the next release will be in 6? weeks anyhow which is close to what > its going to take to shake out the repercussions of your check in anyway. We should seriouly consider such a release process. Howerver, then the CVS main tree must always be in a nearly 'Release-Ready' state. But IMO that is anyway a good idea. > But I > think it's really hard to get such a large number of people working > independently on exactly the same schedule. Yes ... > Almost all libraries are accepted subject to some changes being made. Many > such changes seem simple but end up rippling through the whole library. This > takes time. This is IMHO an indication of a flaw in the current boost review process. A library should be only accepted after the list of requested changes has been made. Additionally, I think a library should be accepted only if it is compatible to the current CVS main tree. > Once a library is accepted, then one can get serious about making it pass > with a larger number of compilers. This also takes time - a lot of time Passing compilers which weren't supported during the review process under no circumstances shouldn't delay the integration of the library into the boost main pool. Supporting a special compiler is only a nice to have feature. This means not that it not worth spending the effort supporting important platforms. However, in the first iteration I just expect a library to be written in ANSI C++ and to be usable on platforms which support it. > These changes end up having a ripple effect and can result it changes like > moving things in namespaces and subdirectories. While this is going on, the > system is broken and really not suitable to be subject to the daily testing > routine. This is IMHO an indication of a flaw ... (s.a) > So it seems attractive to deal with all this stuff before one does > the initial check in to CVS. This way one can start with a relatively clean > start. I second this. With best regards Johannes

2 1