February 2005 - Boost - lists.preview.boost.org

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: 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: [boost] Call for Volunteers: the Synopsis project
by Stefan Seefeld 30 Mar '05

30 Mar '05

Hi Volodya, > From: Vladimir Prus [mailto:ghost@cs.msu.su] > Sent: September 30, 2004 03:04 > Count me as interested. Are you going to base that parser on > OpenC++, which, > IIRC, was used by Synopsis some time ago? Last time a looked > at OpenC++, it > did not even distinguish between ordinary names and > typenames, which makes me > wonder if it's a good parser. You are right, there remains a lot of work to be done. The C++ parser backend of synopsis which we are talking about here is indeed based on OpenC++, but has already undergone lots of improvements. In its original design the parser didn't contain any form of semantic analysis such as symbol lookup to disambiguate certain expressions. For what it had been used so far it was good enough. I'm now working on the features that allow it to get closer to the standard, i.e. constant expression evaluation, symbol (type) lookup, etc. As I said, any help would be very appreciated ! Regards, Stefan

2 2

Warnings in Boost.Thread
by Janusz Piwowarski 29 Mar '05

29 Mar '05

Hi all, When Boost.Thread is compiled in release mode, there are a lot of warnings about unused variable 'int loop_count' in read_write_mutex.cpp. They comes from code like: int loop_count = 0; while (m_state == -1) { BOOST_ASSERT(++loop_count == 1); ++m_num_waiting_readers; m_waiting_readers.wait(l); --m_num_waiting_readers; } If loop is for second evaluation of condition only, i think it would be better to write: if (m_state == -1) { ++m_num_waiting_readers; m_waiting_readers.wait(l); --m_num_waiting_readers; BOOST_ASSERT(m_state != -1); } Regards, Janusz

2 1

Re: [boost] shared_ptr doubts
by Don G 20 Mar '05

20 Mar '05

It is likely that we will simply just disagree on this, but I will at make a stab at responding to your points. > For some specific smart pointer applications, it is possible to > design a smart pointer that is more optimal than shared_ptr. > That's what a policy-based smart pointer is all about, and > hopefully we will soon have one in Boost. In the meantime, look > at the Loki policy-based smart pointer. I'm familiar with Alexandresu's book (even if I can't always remember how to spell his name<g>), but... > But sometimes a single general-purpose smart pointer is needed. Yes! Although I am focused purely on reference counting smart pointers. But... > For example, as a standard type to communicate between libraries, > including third-party libraries. Or to recommend generally to a > wide-range of programmers, including those who might be confused > by a plethora of choices. Exactly. > Or in cases where various efficiency concerns are nowhere near as > important as using a well-known, well-understood, and soon > standardized smart pointer. Why can't we have both? I would suggest that a major reason STL is so popular is that it paid careful attention to efficiency from its inception. If std::vector had allocated several or nearly a dozen extra machine words per object as shared_ptr does at times, I believe things would have turned out differently. The std containers offer what is needed to accomplish a well focused task, allocating only the data necessary for that job and no more. For example std::list need only allocate 2 pointers per object. If Stepanov had gone on to add feature after feature that made this number on par with shared_ptr, again, it likely would not have been well received. > The Colvin-Dimov shared_ptr design solves a far-broader range of > smart pointer problems than any other proposed design. That's > why it is the most commonly recommenced C++ smart pointer type > in the world. That's why the C++ committee is standardizing it. Please don't take my doubts the wrong way; I am not trying to "dis" their fine work. If folks want to use it, that's fine. They should be warned, but caveat emptor. I am focused on the last statement above. As it sits, shared_ptr simply goes too far and in so doing one must always ask "is shared_ptr suitable in this case?" As a library author, this is often an impossible question to answer, because it could depend on the use to which the library is put. In other words, by adding all the frills, shared_ptr actually reduces its scope of applicability. > It isn't intended to replace all other smart pointers. No single > smart pointer type can do that. So appreciate it for the many > problems it solves, rather than worrying about the problems > where another smart point would be more optimal. Where is the standard smart pointer to which you refer? I can keep writing my own (have been for many years, and kinda like it<g>), but what I would really love to see is a pair of simple ones provided by the standard library that accomplish just two jobs: delete it; and delete it when the count drops to 0 (with some means for the count to be internal to the object). If more smart pointers are added beyond that, that would be great. So far, both auto_ptr and soon shared_ptr fail at the K.I.S.S. test. They set out to solve these two "simple" problems and got lost along the way. A standard facility should not offer such surprises to unsuspecting users. With auto_ptr we got "surprise! you thought I was the owner, but it was that other guy that just left scope". With shared_ptr we will have "surprise! here's that bad_alloc you've always wanted". If the current design is the way it will be (probably), can't we at least have a warning label: "WARNING: shared_ptr may allocate 40+ bytes per object (fine print: depending on platform and multithread considerations, your mileage may vary, etc.)" Well, I'm no lawyer I guess... <g> > All IMO, of course! Likewise! Best, Don ===== __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250

5 13

Re: Boost.Threads Bug (recursive_try_mutex)
by Jonathan Biggar 17 Mar '05

17 Mar '05

Mark Rodgers wrote: > Bill, > > recursive_try_mutex::do_trylock() (BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE > implementation) contains the following: > > assert(res == 0); > > Surely that should be > > assert(res == 0 || res == EBUSY); This bug still exists in 1.32! -- Jon Biggar Levanta jon(a)levanta.com

2 1

How to add examples ot the regression testing?
by Gennadiy Rozental 16 Mar '05

16 Mar '05

I want to make sure that all examples are successfully compilable. What is the best way to do this? Gennadiy

3 3

ANN: review of FSM library starts
by Pavel Vozenilek 15 Mar '05

15 Mar '05

Review of Finite State Machine library written by Andreas Huber starts today, February 21, and lasts 10 days. The library can be found at: http://boost-sandbox.sf.net/fsm.zip (781 kB). FSM is feature rich library to design finite state machines without need for external generator. It is accompanied by extensive documentation. Here are some questions you might want to answer in your review: * What is your evaluation of the documentation? How easy (or hard) it is to understand library features? What can be improved? * What is your evaluation of the design? What features are supported better by alternative FSMs? What could be added (or removed) from the library? * The library documentation contains few not yet solved issues (name, separating the library into two parts, exception handling). What is you opinion here? * What is your evaluation of the implementation? Are there parts of code too obscure or duplicating exiting Boost functionality? Can something be factored out to standalone library or among general utilities? * Are there performance bottlenecks? Does the library design fit requirements of real-time systems? How is it useable for embedded systems? Is the documentation clear on performance tradeoffs? * What is your evaluation of the potential usefulness of the library? Can you compare this FSM to other implementations? * Did you try to use the library? With what compiler? Did you have any problems? Do you have tips for better support of older compilers? What are possible portability problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every reviewer should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Pavel Vozenilek FSM review manager

7 19

boost/pending/mutable_queue missing clear() function
by Lloyd J Lewins 14 Mar '05

14 Mar '05

I notice that mutable_queue is missing a clear() function, i.e. a low overhead way of emptying the entire queue (without resorting to repeated pops). However, I think clear() can be implemented as follows: void clear() { clear(); } Which is efficient and (often) fast. I don't think there is any need to "clear" the index_array (since the constructor for mutable_queue doesn't initialize its contents) Lloyd J. Lewins Fellow, Raytheon Co., llewins(a)raytheon.com +1 (310) 647-8832

3 3

casp.hpp workaround and more
by Gennadiy Rozental 07 Mar '05

07 Mar '05

1. Shouldn't this header use workaround from config/suffix.hpp instead of BOOST_EXPLICIT_DEFAULT_TARGET? 2. Shouldn't this header be split by ..._cast? 3. Doesn't numeric_cast facility shouldn't be deprecated? Genandiy

4 23