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'… [View More]

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 … [View More]

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; … [View More]

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 … [View More]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 [View Less]

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 … [View More]

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