August 2005 - Boost - lists.boost.org

?? yilin yang ????????????????!
by yyl_20020115＠yahoo.com.cn 26 Aug '05

26 Aug '05

yilin yang 希望与您通过雅虎通聊天。请点击这个链接接受邀请： http://invite.msg.yahoo.com/invite?op=accept&intl=cn&sig=jjk1zy0GAiCp6Fp5jR… 通过雅虎通，您将获得：卓越语音通过质量，通达全球，完全免费。您只需要扬声器和麦克风。如果对方无法接听，还可以语音留言！轻松的照片共享。简单到只需把图片拖拽到聊天窗口就可以开始共享了。选择性隐身。轻松控制谁可以看到您是否在线，进退自如，保护隐私。还在等什么？这些都是免费的！现在就下载雅虎通，开始与您的好友交流吧！

1 0

Discussion Policy document - Outlook QuoteFix
by Martin Bonner 26 Aug '05

26 Aug '05

http://www.boost.org/more/discussion_policy.htm has a link to OE-QuoteFix by Dominic Jain, and the statement "Unfortunately there's no similar utility for Outlook Users; they will have to clean up their posts manually." In actual fact, the nice Mr Jain has also written Outlook-Quotefix available at: http://home.in.tum.de/~jain/software/outlook-quotefix/ (This is particularly generous of him as he doesn't actually /use/ Outlook - just Outlook Express). It would be good if somebody could update the discussion policy document. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

2 1

Re: [boost] Questions on Serialization
by Bjorn.Karlsson＠readsoft.com 26 Aug '05

26 Aug '05

> From: David Abrahams [mailto:dave@boost-consulting.com] > > "Robert Ramey" <ramey(a)rrsd.com> writes: > > > When the test system introduced automatic memory leak detection, I > > noticed for the first time that lots of the demos and tests had > > memory leaks. It doesn't affect the validity of the demos and tests > > but it does look a little sloppy. I'm reluctant to fix this as I'm > > concerned about complicating the demos and diminishing their > > tutorial value and about complicating the tests. > > IMO that's unacceptable for Boost. A naive user who follows a Boost > example like a recipe could introduce errors into his organization's > codebase. Who do you think the deveopment team manager will blame > when he finds out the error was present in our example? Do you think > they'll continue to have confidence in the quality of the Boost > libraries they're using? I don't. I strongly agree with this sentiment. I often direct colleagues and readers of my articles to the Boost libraries' online documentation; knowing that the documentation is generally of very high quality and accuracy. Bjorn

1 0

Which libs need multithreading?
by Neal Becker 26 Aug '05

26 Aug '05

I'm trying to package up a boost_1_33 RPM. The current default build produces single/multi thread variants of all libs. The current Redhat/Fedora rpm doesn't follow this. I'm tempted to just build single/multi thread variants of all libs just like the default build, but my question is, for which libs does multi-threading actually matter? Is there a subset of boost libs that actually change behavior with this switch? I'd like to get a minimal set.

9 14

[Boost-bugs] [ boost-Patches-1273960 ] spirit/symbols.ipp pragma warning fix
by SourceForge.net 26 Aug '05

26 Aug '05

Patches item #1273960, was opened at 2005-08-26 13:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1273960&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: jmihalicza (jmihalicza) Assigned to: Nobody/Anonymous (nobody) Summary: spirit/symbols.ipp pragma warning fix Initial Comment: The original version sets the default setting back at the end of the file so the following code doesn't work as expected: #pragma warning (disable:4355) #include <boost/spirit/....> // some file that includes symbols.ipp // here 4355 may be enabled according to the default settings (warning level) The fix uses push/pop ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1273960&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[quick_allocator] false sharing on SMP
by Maxim Yegorushkin 26 Aug '05

26 Aug '05

Pavel Vozenilek asked to repost this here, so here it is: http://groups.google.com/group/comp.lang.c++.moderated/msg/2b85fdcd20239a52 I just skimmed through boost/detail/quick_allocator.hpp and noticed that quick_allocator causes false sharing on SMP. It happens when several counters are allocated within the same cache line and those counters are used by different processors, thus thrashing processors' cache lines when the counter is written, even when the counter is used by a single processor only. More information about allocators and false sharing can be found in papers included with Hoard allocator sources. http://hoard.org/ -- Maxim Yegorushkin

3 5

[Boost-bugs] [ boost-Bugs-1273836 ] bjam HDRS rule in python tutorial compilation
by SourceForge.net 26 Aug '05

26 Aug '05

Bugs item #1273836, was opened at 2005-08-26 09:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1273836&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Group: None Status: Open Resolution: None Priority: 5 Submitted By: Leon Oostrijk (ljo_) Assigned to: David Abrahams (david_abrahams) Summary: bjam HDRS rule in python tutorial compilation Initial Comment: When I set HDRS to a value it has no effect. It always produces the value -I"bin/boost" or -I"bin/tutorial". When checked with "-d+7" you can see that the original value is overwritten halfway in the process. As far as I can see nobody uses HDRS in a Boost Jamfile. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1273836&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[multi_index] feature request
by Maxim Yegorushkin 26 Aug '05

26 Aug '05

[multi_index] feature request In my code I often use collections of noncopyable objects and yet I need to have them indexed. The usual solution is to store pointers to the objects in the index (be it a std::set/map or boost::multi_index). This leads to two allocations: the first for the object and the second for the index node. For me it would be more natural and effective to embed the index node in the object, so that the container is obviated from allocating nodes and only maintains indexes. This also would make all container operations nothrow, since element insertion and removal requires only node pointer manipulations and using the comparer object which is typically nothrow. In my work I use my own intrusive_list which has proved itself quite useful and effective. The syntax is: struct noncopyable_object; typedef intrusive_list<noncopyable_object> list; struct noncopyable_object : list::node // embed the list node in the class { // ... }; Will such a feature ever make it to multi_index? -- Maxim Yegorushkin <firstname.lastname(a)gmail.com>

2 1

Re: [boost] [statechart] Problems if I make dtorS virtual?
by BRIDGES Dick 26 Aug '05

26 Aug '05

Hi Andreas > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Andreas Huber > Sent: Wednesday, August 24, 2005 2:19 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] [statechart] Problems if I make dtorS virtual? > > Hi Dick > > BRIDGES Dick wrote: > > When compiling the examples (statechart library downloaded from sf 18 > > Aug), I get the following warnings: > > [snip warnings] > > > I changed ~simple_State() and ~state_base() to virtual and the > > warnings disappeared. [snip] > > As a quick, not-definitive check, I built PingPong* with both the > > virtual and non-virtual dtorS using gcc 3.4.2 on an old > > i386-redhat-linux machine. > > I would expect the PingPong examples to deliver the least-dependable > information regarding virtual vs. non-virtual dtors. This is due to the > fact that a lot of stuff is going on besides the destruction of states. > I think BitMachine would make for a better testing platform... > > > The results appear to be the reverse of what I would expect, but I > > checked > > to verify that I have the correct result/config correspendence. > > > > ..................non-virtual.....virtual > > PingPongSingle.... 4.08 ..... 3.71 > > PingPongMulti1.... 6.01997 ..... 5.85999 > > PingPongMulti2.... 19.53 ..... 19.55 > > Hmmm, here's what I get on a 3.2GHz Intel Pentium 4 Windows XP machine > (all numbers in microseconds non-virtual / virtual): > > *** MSVC7.1 *** > > PingPongSingle: 1.06 / 1.07 > PingPongMulti1: 5.41 / 5.43 > PingPongMulti2: 12.34 / 12.26 > > BitMachineCustom3: 0.18 / 0.19 [snip_similar_results] Looks more like what I would expect. BTW: Could I talk you into trading computers? ;) > I.e. no significant difference non-virtual vs. virtual. Two things come > to mind: > 1. At the point where states are destructed (see simple_state.hpp, line > 983) the compiler might know that the type of the pointer matches the > runtime type of the referenced object and therefore call the virtual > destructor non-virtually. However, I'm not sure whether such compiler > magic is implemented in any of the tested platforms nor do I have a clue > whether that's possible at all (it does sound pretty impossible) > 2. There could be little difference on modern processors anyway (as you > have mentioned) > > > Reminds me of the old joke: "I see fine. I just don't understand > > what > > I'm looking at." Two questions: 1) will making the dtorS virtual > > lead > > to adverse consequences I simply haven't encountered yet; > > Given the numbers above I don't see any problems whatsoever. Not on the > tested processors, that is. I can't say whether the picture is the same > for processors used in the embedded world. I may know the answer for some ARM machines soon - I hope. ;) I'll try the BitMachine* tests if I can get the cross compilers to build them. > > and 2) can > > someone help me understand what I did wrong in setting up this test? > > Difficult to say. Could you build with bjam and repeat the test? I followed the instructions to build the examples. Changed to the example directory and ran <<bjam "sTOOLS=gcc">>. I got lazy and only ran the PingPong* progs. Guess I should have mentioned that. %>] Any chance that, in the absence of some future evidence to the contrary, those dtorS can be made virtual in the library? [snip] > Regards, > > -- > Andreas Huber Regards, Dick Bridges "Multithreading is just one damn thing after, before, or simultaneous with another." Scott Meyers and Andrei Alexandrescu

4 5

[futures] Request for Comments
by Thorsten Schuett 25 Aug '05

25 Aug '05

Hi, Hartmut and I wrote a small library which implements futures for C++. I uploaded the code to the boost-sandbox vault. If you find anything odd in there (like e.g. overloading operator T()), you have to blame me, if you find interesting stuff in there, you have to blame Hartmut. The most basic future is simple_future<T>. Its constructor takes a function which returns T and spawns a new thread executing this function. Afterwards you can call operator()() to block until the thread is done and get the result. int slow_fac(int n){ if(n == 0) return 0; if(n == 1) return 1; sleep(1); return n * fac(n - 1); } simple_future<int> f1 = bind(slow_fac, 4); ... cout << f1() << endl; //should print 24 if you have two different implementations of fac and you are only interested in the result of the faster implementation, you can combine two futures using '||'. int fast_fac(int n){ if(n == 0) return 0; if(n == 1) return 1; return n * fac(n - 1); } simple_future<int> f2 = bind(fast_fac, 4); future<int> f3 = f1 || f2; ... cout << f3() << endl; // should print 24 If the result type of the futures given to '||' differ, the result type of the new future is a variant over the types. double fac4(){ return (double)fast_fac(4); } future<variant<int, double> > f4 = f2 || double_[&fac4]; //double_[] creates a simple_future<double> Similarly, the '&&'-operator creates a tuple of the types of the individual futures and blocks until all futures are done. future<tuple<int, double> > f5 = f2 && double_[&fac4]; Warning: I overloaded operator T() for futures to get a nicer syntax. int fac_of_4 = f1; // <- this works! Thorsten

11 37