- Boost - lists.boost.org

typeof and Visual C++
by Arkadiy Vertleyb 31 Mar '05

31 Mar '05

HI all, God only knows what else can be found inside this compiler if one is willing to dig real deep. For example, Igor' Chesnokov from RSDN (Russian Software Development Network) has found a way to implement typeof() that does not require registration, and probably has compile-time performance of a native typeof. How? Apparently, some weird "feature" of Visual C++ allowed him to twick a template body at the moment of instantiation, when additional context is available, thus "registering" classes on the fly, at the moment of taking typeof(). Microsoft-specific "bugfeatures" are generally not in the area of my interests. However I do realize that, on the Microsoft compiler, this might look much more attractive then anything Peder and I have implemented. And even though I realize that this might be a serious competition, I would feel really bad not to mention this here: http://rsdn.ru/Forum/?mid=1094305 Thoughts? In particular, how do people feel about implementing someting for some particular compiler using specific "features" of this compiler? Should this be acceptable? Regards, Arkadiy -- Regards, Arkadiy

5 15

boost/threads/condition.hpp documentation patch
by Larry Lansing 30 Mar '05

30 Mar '05

Attached please find a patch for boost/libs/thread/doc/condition-ref.xml which re-adds a warning about spurious wakeups that appeared in older versions of the boost threads documentation. Compare and contrast: http://www-eleves-isia.cma.fr/documentation/BoostDoc/boost_1_29_0/libs/thre… vs. http://www.boost.org/doc/html/condition.html The newer boost.org version omits this paragraph: *** Danger: This version should always be used within a loop checking that the state logically associated with the condition has become true. Without the loop, race conditions can ensue due to possible "spurious wake ups". The second version encapsulates this loop idiom internally and is generally the preferred method. *** Unless there was an important reason that this warning was removed, it seems like the spurious wakeup issue should definitely be mentioned in the wait() and timed_wait() interfaces. Unless I've screwed it up, the attached patch should put this paragraph in the right places. Thank you for your time. -- Larry Lansing Index: condition-ref.xml =================================================================== RCS file: /cvsroot/boost/boost/libs/thread/doc/condition-ref.xml,v retrieving revision 1.3 diff -d -u -r1.3 condition-ref.xml --- condition-ref.xml 17 Jul 2004 04:33:59 -0000 1.3 +++ condition-ref.xml 15 Mar 2005 19:18:42 -0000 @@ -97,6 +97,13 @@ lock.</simpara></effects> <throws><simpara><classname>lock_error</classname> if <code>!lock.locked()</code></simpara></throws> + <notes><simpara>This version should always be used within a + loop checking that the state logically associated with the + <classname>condition</classname> has become true. Without + the loop, race conditions can ensue due to possible + "spurious wake ups". The second version encapsulates this + loop idiom internally and is generally the preferred + method.</simpara></notes> </method> <method name="wait"> @@ -153,6 +160,13 @@ otherwise <code>true</code>.</simpara></returns> <throws><simpara><classname>lock_error</classname> if <code>!lock.locked()</code></simpara></throws> + <notes><simpara>This version should always be used within a + loop checking that the state logically associated with the + <classname>condition</classname> has become true. Without + the loop, race conditions can ensue due to possible + "spurious wake ups". The second version encapsulates this + loop idiom internally and is generally the preferred + method.</simpara></notes> </method> <method name="timed_wait">

2 2

IMPORTANT: yahoogroups admin rights problem
by Toon Knapen 30 Mar '05

30 Mar '05

Hello ALL, As many of you might know, currently we are unable to add new members to the ublas-ml. The problem is that only Joerg has the rights to add members to the list but Joerg does not respond anymore. Could some of you try to contact Joerg or give me his telephone number that I talk to him about this. If we do not have a solution by end of November I will create a new project on yahoogroups (and we all have to switch). Additionally we need to contact Joerg and Mathias (again!) about applying the Boost Software License. I currently have the impression that they are not willing to change ublas to the BSL. In that case IMO, we will have to rewrite uBLAS to not get thrown out of boost. Again his phone-number would be handy if you have it available. Please contact the ml or me asap about the above issues or we will need to take drastic actions. toon

4 4

MPL Question on crossing the compile \ runtime barrier with bind | adding to boost profiler abstracted file access
by Brian Braatz 30 Mar '05

30 Mar '05

I have been reading (ahem and re-reading) "C++ Template Metaprogramming" I have a problem I am trying to solve and was up late last night looking for the answer to jump out at me. If nothing else this helps me as I tend to re-read the same chapters over and over. Here is what I am trying to do In working on coded I am adding to the proposed Boost Profiler (started by Chris Diggings, inherited by yours truly). I am using RAII all "over" my program in the extensions I am adding to the profiler. This puts me in a spot where I have MACROs which stuff the profile points in the program. Now the problem is I would like to be able to add a template param to the TYPE of the profile points which gives it the initialization code for the STREAM it is using. The problem is since the objects themselves get created ALL OVER the program, I don't have a single point of construction (because I am using RAII to track the life cycles inside the functions themselves). I.e. I want to be able to use Boost.IOstreams or ofstream or whatever for these objects.I just need to , at the TYPE DEFINITION be able to define how to initialize this passed stream. I need to be able to do something like this Template <typename STREAMTYPE, typename INITFUNCTOR> Class MyClass { Public: STREAMTYPE outstream; MyClass() { INITFUNCTOR f(outstream); // open the file, init iostreams , or whatever } }; I can always pass in a functor, but what I really want for Christmas is to be able to Tyepdef MyClass<std::ofstream, bind(&std::ofstream::open,_1,"MyFile.txt") > MyNewClass; This doesn't work because bind returns an actual OBJECT instead of a type. (intuitively - it would be cool if I could say bind(...)::Type which would give me the TYPE of the generated functor) SO that led me to be up until 3 am reading about mpl::lambda. I am still trying to determine if THAT can be used in place, but the dots are not connecting for me yet. Any suggestions or directions pointed GREATLY appreciated. Is there a way to make this work with MPL::Lambda? Thanks Brian

2 1

[thread] condition::wait docs clarification
by Vladimir Prus 30 Mar '05

30 Mar '05

Hello, the docs for condition::wait say: blocks the current thread of execution until readied by a call to <code>this->notify_one()</code> or<code> this->notify_all()</code>, and then reacquires the lock. Shouldn't the docs also mention 'spurious wakeups', that is returns from wait without any notify_one or notify_all coll? I won't pretend to know why those wakeups can happen and on what systems, but at least is relevant to pthreads conditions. I'm asking because a colleague just read this, and though that a parent thread can launch child thread and wait for it to become ready with just condition.wait(); on parents side and condition.notify_one(); on child's side, while in fact return from condition.wait() only means that the predicate waited on must be reevaluated. - Volodya

3 2

Open watcom
by Charles Schwartz 30 Mar '05

30 Mar '05

Does anyone know of the status of Watcom (http://www.openwatcom.org/) w.r.t. boost compilation? Are there plans to test against this compiler in the future?

8 12

RE: [boost] Re: Lock free shared_ptr on gcc, help needed
by Brian Braatz 30 Mar '05

30 Mar '05

I talked to Andrei about this. It IS possible to do this as a std::allocator<> replacement, but I have been led to believe it is not a simple matter. The lock free algo (I have been studying this) is one that seems to be more tailored to specific implementation and less to a general library concept. The problem with the std containers is that they are "too power" and provide many conceptual ways to access the data. The model of how std containers work is very different from the "purposely" heavily constrained access provided with the lock free mechanism. I was thinking it might be useful to write a simple lock free container with a limited interface. With this pattern, one could do something in alignment with lock free, but I am not sure it would be palatable for people as the first thing folks would say is "Hey, that's not a std::vector<>". > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Peter Dimov > Sent: Wednesday, March 30, 2005 8:08 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Lock free shared_ptr on gcc, help needed > > Robert Zeh wrote: > > Could the primitives used by the lock-free shared_ptr be made > > available from boost threads? It would be helpful for other people > > writing lock-free code. > > Probably not, and even if they are made available, it wouldn't be helpful. > You can't write correct lock-free code with primitives that have > unspecified > memory synchronization properties. Well... maybe you can, but most of us > cannot. ;-) > > (Most of us can't write correct lock-free code at all, but that's a > different story.) > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: size of libboost_thread-gcc-mt.so
by Vladimir Prus 30 Mar '05

30 Mar '05

Alexander Nasonov wrote: > Amerio wrote: >> Hello, >> After compiling libboost_thread-gcc-mt.so on debian/gcc-2.95.4, this so >> weights 195kB, while libpthread weights only 100kB. >> Why such a huge difference ? Isn't boost::thread meant to be as >> lightweight as possible ? > > Try building it with Boost.Build v2 (bjam --v2 gcc release). It's only > 64K because read_write_mutex.o (223K in release) is excluded from link. > I don't know whether it's intentional or an oversight. I'm afraid it's an oversight -- that's a recently added feature. I'm surprised that it adds so much to the size though, let me try here. Without read_write_mutex the size of gcc/release/shared build is 46K. With read_write_mutex the size is 136K. Wow, that's a difference! When I comment out explicit template instantiations in that source file, the library is becomes 76K. The comment says explicit instantination are needed to detect syntax errors in templates but those instantination bloat the library. BTW, I'm not sure read_write_mutex should be a template, either. Maybe, we need class polymorphic_mutex; and template<class Mutex> class concrete_polymorphic_mutex : public polymorphic_mutex { }; and read_write_mutex_impl must be implemented in terms of polymorphic_mutex? - Volodya

3 4

Re: size of libboost_thread-gcc-mt.so
by Vladimir Prus 30 Mar '05

30 Mar '05

Alexander Nasonov wrote: > Amerio wrote: >> Hello, >> After compiling libboost_thread-gcc-mt.so on debian/gcc-2.95.4, this so >> weights 195kB, while libpthread weights only 100kB. >> Why such a huge difference ? Isn't boost::thread meant to be as >> lightweight as possible ? > > Try building it with Boost.Build v2 (bjam --v2 gcc release). It's only > 64K because read_write_mutex.o (223K in release) is excluded from link. > I don't know whether it's intentional or an oversight. I'm afraid it's an oversight -- that's a recently added feature. I'm surprised that it adds so much to the size though, let me try here. Without read_write_mutex the size of gcc/release/shared build is 46K. With read_write_mutex the size is 136K. Wow, that's a difference! When I comment out explicit template instantiations in that source file, the library is becomes 76K. The comment says explicit instantination are needed to detect syntax errors in templates but those instantination bloat the library. BTW, I'm not sure read_write_mutex should be a template, either. Maybe, we need class polymorphic_mutex; and template<class Mutex> class concrete_polymorphic_mutex : public polymorphic_mutex { }; and read_write_mutex_impl must be implemented in terms of polymorphic_mutex? - Volodya

1 0

[call_traits]split
by Gennadiy Rozental 30 Mar '05

30 Mar '05

Hi, Is there any plans to split call_traits? I really need only reference type trait. Shouldn't it be part of type traits lib? Is there an alternative already in there? Thanks, Gennadiy

4 7