- Boost - lists.preview.boost.org

min/max, revolutions
by Eric Niebler 02 Jul '04

02 Jul '04

I've made one more small tweak to the min/max fix. I have relocated the BOOST_USING_STD_MIN and BOOST_USING_STD_MAX macros to their rightful place in the config headers and removed boost/minmax.hpp. I have fixed all the code affected by this change. I have also changed the coding guidelines to say to #include config.hpp instead of minmax.hpp. I have also (hopefully!) fixed the problem with gcc-2.95/STLPort, although I don't have that platform so I couldn't test my changes. Thanks for your patience while I work these kinks out. -- Eric Niebler Boost Consulting www.boost-consulting.com

1 0

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

01 Jul '04

Or, maybe even, try_scoped_lock : private basic_lock { ... try_scoped_lock (mutex& m) : basic_lock(m, 0) {} bool try_lock() { basic_lock.try_lock(); } // No lock() for try_scoped_lock } Then, user-oriented interfaces would be pristine clean for average users and the majority of uses without affecting/complicating underlying implementation and disadvantaging the advanced/tricky users. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Batov, Vladimir Sent: Friday, 2 July 2004 7:40 AM To: boost(a)lists.boost.org Subject: [boost] Re: Boost.Threads: Do we need all those mutexes? I am thinking maybe technically it would be much easier and cleaner to implement one basic_lock (modeled on the current timed_lock) and then provide specializations (you see, I am avoiding "refinement" :-) ) of it to the user like: try_lock : public basic_lock { ... try_lock(mutex& m) : basic_lock(m, 0) {} } Then, 1. underlying implementation would be much simpler and without duplication as it'd always operate with basic_lock (good for maintainers/implementers); 2. average users would still have friendly and simple interface; 3. advanced users might do much more tricky stuff by simply cutting to the bone and using basic_lock. Just a thought. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Batov, Vladimir Sent: Friday, 2 July 2004 7:25 AM To: boost(a)lists.boost.org Subject: [boost] Re: Boost.Threads: Do we need all those mutexes? According to the current Boost.Threads documentation timed_wait() does not require timed_lock (cut and pasted from http://www.boost.org/libs/thread/doc/condition.html#class-condition) template <typename ScopedLock> bool timed_wait(ScopedLock& lock, const xtime& XT); Looking at the code it does appear to require timed_lock either: template <typename L> bool timed_wait(L& lock, const xtime& xt) { if (!lock) throw lock_error(); return do_timed_wait(lock.m_mutex, xt); } What am I missing? BTW. How can I get to have look at the development branch? I went to http://cvs.sourceforge.net/viewcvs.py/boost/boost/development/ but found nothing threads-related. Thanks, V. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Glassford Sent: Friday, 2 July 2004 4:35 AM To: boost(a)lists.boost.org Subject: [boost] Re: Boost.Threads: Do we need all those mutexes? Batov, Vladimir wrote: >>Well, as you point out, try_lock is like a timed_lock with >>time = 0, and lock is like a timed_lock with time = infinity, >>so why not give timed_lock both lock() and try_lock() >>methods as shorthand notation for lock(m, t=0) and >>lock(m, t=infinity)? > > > [Batov, Vladimir] Because, in my view, it violates the fundamental (and > I think widely accepted) OO design principle (guideline?) that in simple > terms can be expressed as "one class, one responsibility". Names like > Bertrand Meyer, Herb Sutter and many others immediately come to mind. > > We can either achieve that by having a universal lock (with timed_lock > as the basis) and shorthand notations in separate derived classes (lock, > timed_lock and try_lock) or by keeping those three completely unrelated > (probably at the expense of some code/functionality duplication). I am > personally leaning towards latter, as even though technically all three > concepts are related, from the user point of view they are distinct. > > >>The argument for try_lock not having a blocking lock() method, >>which you seem to stress more often, is much clearer; I'm much >>more inclined to agree with you there. > > > [Batov, Vladimir] Thank you. I feel that it is important that every > class does what it promises to do. No more, no less. For what it's worth, heres a use case I just ran across illustrating why timed_lock should have a blocking lock() method and/or a blocking locked constructor: condition c; void f(mutex m) { mutex::scoped_timed_lock l(m, locked); //always want the lock here for(;;) { //do stuff c.timed_wait(l, next_wakeup_time()); //timed_wait requires a timed_lock } } Mike _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

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

01 Jul '04

I am thinking maybe technically it would be much easier and cleaner to implement one basic_lock (modeled on the current timed_lock) and then provide specializations (you see, I am avoiding "refinement" :-) ) of it to the user like: try_lock : public basic_lock { ... try_lock(mutex& m) : basic_lock(m, 0) {} } Then, 1. underlying implementation would be much simpler and without duplication as it'd always operate with basic_lock (good for maintainers/implementers); 2. average users would still have friendly and simple interface; 3. advanced users might do much more tricky stuff by simply cutting to the bone and using basic_lock. Just a thought. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Batov, Vladimir Sent: Friday, 2 July 2004 7:25 AM To: boost(a)lists.boost.org Subject: [boost] Re: Boost.Threads: Do we need all those mutexes? According to the current Boost.Threads documentation timed_wait() does not require timed_lock (cut and pasted from http://www.boost.org/libs/thread/doc/condition.html#class-condition) template <typename ScopedLock> bool timed_wait(ScopedLock& lock, const xtime& XT); Looking at the code it does appear to require timed_lock either: template <typename L> bool timed_wait(L& lock, const xtime& xt) { if (!lock) throw lock_error(); return do_timed_wait(lock.m_mutex, xt); } What am I missing? BTW. How can I get to have look at the development branch? I went to http://cvs.sourceforge.net/viewcvs.py/boost/boost/development/ but found nothing threads-related. Thanks, V. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Glassford Sent: Friday, 2 July 2004 4:35 AM To: boost(a)lists.boost.org Subject: [boost] Re: Boost.Threads: Do we need all those mutexes? Batov, Vladimir wrote: >>Well, as you point out, try_lock is like a timed_lock with >>time = 0, and lock is like a timed_lock with time = infinity, >>so why not give timed_lock both lock() and try_lock() >>methods as shorthand notation for lock(m, t=0) and >>lock(m, t=infinity)? > > > [Batov, Vladimir] Because, in my view, it violates the fundamental (and > I think widely accepted) OO design principle (guideline?) that in simple > terms can be expressed as "one class, one responsibility". Names like > Bertrand Meyer, Herb Sutter and many others immediately come to mind. > > We can either achieve that by having a universal lock (with timed_lock > as the basis) and shorthand notations in separate derived classes (lock, > timed_lock and try_lock) or by keeping those three completely unrelated > (probably at the expense of some code/functionality duplication). I am > personally leaning towards latter, as even though technically all three > concepts are related, from the user point of view they are distinct. > > >>The argument for try_lock not having a blocking lock() method, >>which you seem to stress more often, is much clearer; I'm much >>more inclined to agree with you there. > > > [Batov, Vladimir] Thank you. I feel that it is important that every > class does what it promises to do. No more, no less. For what it's worth, heres a use case I just ran across illustrating why timed_lock should have a blocking lock() method and/or a blocking locked constructor: condition c; void f(mutex m) { mutex::scoped_timed_lock l(m, locked); //always want the lock here for(;;) { //do stuff c.timed_wait(l, next_wakeup_time()); //timed_wait requires a timed_lock } } Mike _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Serialization of infinite double - from comp.lang.c++
by Jeff Flinn 01 Jul '04

01 Jul '04

I'm posting this message from Gustav Lead from comp.lang.c++ while he gets access to boost devel and/or user mailing lists. Jeff Flinn ---------------------------------- Hi all, I have trouble reading back floating point data from a file. It appears as if the tokens for positive and negative infinity (1.#INF and -1.#INF) that my implementation writes get misinterpreted (to 1.0 and -1.0) when I try to read them back in. #include <fstream> #include <limits> void somefunction() { double d_infinity = std::numeric_limits<double>::infinity(); std::ofstream output; output.open("file.txt"); output << d_infinity; output.close(); double d_test1 = 0; std::ifstream input; input.open("file.txt"); input >> d_test1; input.close(); } The contents of "file.txt" is "1.#INF". At the end of the function the value of d_test1 is 1.0 . Trying to read in more data after that will fail, because the "#INF" fragment remains in the stream. Is this a problem of my STL implementation (I am using MSVC 7.1), or do I have to make some change to my code to get this to work correctly? Thanks in advance, G L "Mike Wahler" <mkwahler(a)mkwahler.net> wrote in news:xTIEc.470$oD3.371@newsread1.news.pas.earthlink.net: > > No, this is by design. > If you want to store a special 'token' to indicate 'infinity', you'll > need to specifically parse for it. > > Typically numeric input is handled more robustly by reading a 'line' > as a string, and using conversion functions after the fact (e.g. > 'strod()' or an istringstream extractor). To check for your > 'infinity' token, just search the string for that first. > > -Mike Thanks for your answer, Mike! Unfortunatly this is not an option for me, because I am using a serialization library (Boost::Serialization currently at http://www.rrsd.com/boost/) and I have to rely on the STL stream library operators to read back all of their repective data as they wrote it into the stream and to properly restore the state of the object. Perhaps I could alter the behavior of the "ostream& operator<<(ostream&, double)" (and istream)? I think overloading would be a redefintion and is out of the question (or is it???) unless I make some kind of wrapper for doubles, but maybe it is possible to do this with locales (or facets?) ? Locales are really terra incognita for me, so I'd really like some advice if this is a viable option at all, before I try to go down that path. Any other idea for a solution would of course be just as welcome.... Thanks, GL

1 0

Re: Learning boost::MPL (Daniel Wallin)
by Dan 01 Jul '04

01 Jul '04

Hi Daniel, I tried your code as well and it works fine (it's also nice and compact) >I don't know why you are using iter_fold instead of just fold here, but >anyway: Oops, don't assume I know what I'm doing, because I don't! Yesterday was the first I ever heard of boost MPL. Whats the difference between iter_fold and fold? I replaced iter_fold with fold in your code and it works as well. Thanks, -A fellow Daniel :)

2 1

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 01 Jul '04

01 Jul '04

> Well, as you point out, try_lock is like a timed_lock with > time = 0, and lock is like a timed_lock with time = infinity, > so why not give timed_lock both lock() and try_lock() > methods as shorthand notation for lock(m, t=0) and > lock(m, t=infinity)? [Batov, Vladimir] Because, in my view, it violates the fundamental (and I think widely accepted) OO design principle (guideline?) that in simple terms can be expressed as "one class, one responsibility". Names like Bertrand Meyer, Herb Sutter and many others immediately come to mind. We can either achieve that by having a universal lock (with timed_lock as the basis) and shorthand notations in separate derived classes (lock, timed_lock and try_lock) or by keeping those three completely unrelated (probably at the expense of some code/functionality duplication). I am personally leaning towards latter, as even though technically all three concepts are related, from the user point of view they are distinct. > The argument for try_lock not having a blocking lock() method, > which you seem to stress more often, is much clearer; I'm much > more inclined to agree with you there. [Batov, Vladimir] Thank you. I feel that it is important that every class does what it promises to do. No more, no less.

2 1

Converting Boost.Threads documentation to BoostBook
by Michael Glassford 01 Jul '04

01 Jul '04

I've just checked in the Boost.Threads documentation in BoostBook format and changed doc\src\boost.xml appropriately; is there anything else I need to do? Also, is the BoostBook documentation being regularly generated somewhere so that I can take a look at it and make sure everything is working properly somewhere besides my machine? Mike

4 4

gcc thread local storage
by Neal D. Becker 01 Jul '04

01 Jul '04

I know almost nothing about threads. Still I thought this link might be of interest for boost::thread. I'm guessing that the term "Thread Local Storage" is the same as "Thread Static Storage". http://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html

2 1

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 01 Jul '04

01 Jul '04

[Christopher Currie] In the need of extreme memory efficiency and speed: I already have, from prior use, a scoped_try_lock 'l' around my mutex, currently unlocked. I need to lock my mutex in a blocking fashion. I do not wish to pay the memory and time cost to create an instance of scoped_lock just to do this. I therefore call 'l.lock()' and not 'l.try_lock()'. [Batov, Vladimir] I am sorry but I am far from being convinced that "extreme memory efficiency" can be achieved by saving on one lock. Locks are very transient creatures and created on the stack. Commonly the stack is predefined by OS regardless if you use it or not. Consequently, even when you do not create another object on the stack, that memory is not available to you for anything else anyway. Even if it is, I greatly doubt that that approach is the right approach to achieve efficiency. The common approach would be to worry about the right design first and foremost, then run profilers/monitors/tests to see where we actually can save memory/gain performance. Twisting design for the sake of perceived performance/memory gains is often (I'd say always) a very bad idea. Even if you do not buy into my arguments in the prev. paragraph, you'll probably agree it'll be unfair to expect that the majority of library users and overall general-purpose library design need to pay the price of accommodating your very specific requirements. For example, general memory allocation is often slow for me. Then, I write my own special memory allocator. I am not asking for the general-purpose allocator to be changed. ... [Christopher Currie] Constructor parameters are, admittedly, a different discussion, and most of them boil down to syntactic sugar for a non-locking constructor and a call to some locking operation, blocking or otherwise. But (IMO) it's a useful syntactic sugar that *can* if used properly make programs less cumbersome to construct without sacrificing correctness or clarity. [Batov, Vladimir] I am not against syntactic sugar if it is in line with what is reasonably expected from a class. However, I am against syntactic sugar which is not relevant to class functionality. Like I am happy if I can simply give my credit card to a taxi driver and not worry about having cash. However, I am not sure if I'd like that driver singing. As far as S/W design is concerned, I'd prefer a taxi driver class (with its responsibilities) and a singer class (with its responsibilities). We all know how to blend those two classes if we ever need that.

2 1

min, max, GCC 2.95.3, and STLport
by Doug Gregor 01 Jul '04

01 Jul '04

The new handling of min/max seems to break under GCC 2.95.3 with STLport. I'm not quite sure _why_ it doesn't work (I don't have the compiler around), but you can see the failure here: http://tinyurl.com/ytdlf Perhaps someone with that compiler/lib combination could get preprocessed output for the problem area so we could see what's happening? Doug

4 5