- Boost - lists.boost.org

[boost numeric binding] patch
by Michael Gauckler 07 Sep '08

07 Sep '08

Hi, I have a little patch (a three-liner, given below) that allows the boost numeric bindings to be parsed by GCCXML. Can somebody with write-access to the sandbox please apply this little patch? Thanks. Best regards, Michael 21a22,23 > #elif defined(__GCCXML__) >

1 0

What's up with the trunk test summary?
by Emil Dotchevski 07 Sep '08

07 Sep '08

This link doesn't quite work for me: http://beta.boost.org/development/tests/trunk/developer/summary.html Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

3 2

[threadpool] determining whether a Threadpool type uses a priority/attribute
by Stjepan Rajko 07 Sep '08

07 Sep '08

Hello, Suppose I have a Threadpool type, which could for example be either of the following: tp::pool< tp::fixed, tp::unbounded_channel< tp::priority< int > > > -or- tp::pool< tp::fixed, tp::unbounded_channel< tp::fifo > > How do I find out whether Threadpool involves a priority/attribute, and what the type of it is? For example, I am looking for something that would give me: // returns something like mpl::true_ for the first case // returns something like mpl::false_ for the second case has_priority<Threadpool>::type // returns int for the first case priority_type<Threadpool>::type Thanks in advance, Stjepan

3 4

lifetime of ranges vs. iterators
by Arno Schödl 07 Sep '08

07 Sep '08

Hello, some adaptor ranges need certain constant information about their underlying ranges. For example, iterating over a forward "difference_range", the difference between two sorted ranges, requires access to the ends of the underlying ranges. These two additional iterators are constant, they do not change when the difference_iterator is incremented. Now, where should this additional constant information be stored? a) In the difference_range, and each iterator holds a reference to the difference_range? That requires the difference_range to be alive as long as its iterators are alive. This may be difficult to ensure if the difference_range is a temporary. b) In the iterators, so the lifetime of adaptor iterators is independent of the adaptor range. Of course, one can use shared_ptrs and so on, but still the iterators are ultimately responsible to keep that information available. This initially seemed more natural to me, but if implemented naively by storing the additional iterators in the iterator itself, it leads to storage bloat: each difference_iterator needs 4 instead of 2 of its underlying iterators. When stacking difference iterators, the difference in required storage grows exponentially: instead of 2^N, you need 4^N storage... I feel that in order to solidify the range concept, one needs to make a choice whether a) or b) is "standard", because any user of ranges would need to know. Any thoughts on this? Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229

7 118

Re: [boost] Mentoring students
by Chris De Vries 07 Sep '08

07 Sep '08

> on Thu Sep 04 2008, "Chris De Vries" <cdevries-AT-ieee.org> wrote: >> Hi, >> >> My name is Chris De Vries and I am involved with the IEEE student branch at >> the Queensland University of Technology in Brisbane, Australia [1]. I am >> organizing a program that encourages students to become involved with open >> source. I am looking for projects that are interested in taking on students. >> The branch will be running an information session and I am hoping to list >> some projects that are willing to mentor students. Is Boost interested? >> >> Thanks, >> Chris De Vries > > Hi Chris, > > I think you'll probably hear something like this from many projects... > Boost is already involved in Google Summer of Code, which on the face of > it seems like a similar program, and takes a great deal of time from > those participating. I can't speak for others, but it seems unlikely > that anyone would have the resources to support two such programs. > > Maybe you have already thought about how to compete with GSoC and have > designed it to be more attractive? If so, it would be good to know the > details. > > Thanks! > > -- > Dave Abrahams > BoostPro Computing > http://www.boostpro.com Hi Dave, My idea is that students will become involved with a project by making some small contributions and then go onto participate in Google Summer of Code. It is still uncertain if GSoC will run in Australia this year. Hopefully we will hear soon. I assume this will not fit in well with the Boost development model where entire modules are proposed, evaluated then developed. Is this assumption correct? I think that working together with other programs (GSoC, etc) will work best, rather than competing against them. I see the IEEE as a means to assist, inform and encourage students to become involved. This will be effective because we can do it in person and on campus. We are also providing free pizza to encourage attendance at our information session. If this program succeeds I hope that it will spread to other student branches. As you have suggested it might be too much load for already strained projects. I will have to wait and see how it goes. Thanks for your feedback. Chris De Vries

2 1

[exception] Incompatibility between boost::throw exception and throw prototype declarations
by vicente.botet 06 Sep '08

06 Sep '08

Hi, As boost::throw_exception can now throw un unspecified exception throgh the use of enable_current_exception, do it is no more possible to use throw declaration in the prototype of any function calling functions that directly or indirectly calls throw_exception. See enable_current_exception declaration in the documentation. namespace boost { template <class T> ---unspecified--- enable_current_exception( T const & e ); } Does it means that we have a interface change of the boost::throw function since it was implemented by the Boost.Exception library on 1.36.0? Best, Vicente

4 8

[interprocess] Just a note of thanks to the developers :)
by Faisal Vali 06 Sep '08

06 Sep '08

I Have been working on some COM components in the windows environment that have required communication across processes. The abstractions the interprocess library provides have greatly simplified my life (as have many of the other libs in boost, and i have been negligent in my thanks). Thank you so much! Faisal Vali, MD, MSc Radiation Oncology Loyola p.s. If this is the incorrect forum for showing appreciation, I apologize

3 5

possible bug introduced in boost function
by Emil Dotchevski 06 Sep '08

06 Sep '08

I have strong suspicions that the changes in boost::function made today introduce a serious bug in the lifetime management of the contained object. I don't have a simple test case to demonstrate it, but a rather complicated use of boost::function which contains shared_ptr in a boost::bind results in incorrect refcount which leads to a crash. Reverting to revision 48607 makes the shared_ptr refcount correct. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

4 5

[review] FSM Library review result
by Martin Vuille 06 Sep '08

06 Sep '08

This is a brief report of the results of the review of Andrey Semashev's Finite State Machines (FSM) library. I want to do justice to the discussions that took place, and will follow-up with a complete summary next week. In spite of a good amount of discussion and an extension of the review period, the number of reviews was smaller than I had hoped for. Nonetheless, I believe that the library received an adequate review and, based on the review comments and other discussions, the FSM library cannot be accepted into Boost at this time. A total of four reviews were submitted, as follows: Andrea Carbone: YES Phil Endecott: NO Jeff Flinn: NO Chris Knight: NO Darryl Green also submitted a mini-review, which did not include an explicit yes or no vote, but expressed doubt about whether the library should be accepted. On the positive side, several people noted that the goals of the library (simplicity and greater performance than Boost.StateCharts) were valid and that such a library was needed in some applications. I personally support this view. I would like to thank Andrey for his efforts in developing the library. I would like to encourage him to pursue the discussions that were begun during this review and perhaps try again with an updated submission. MV

4 3

BOOST_CURRENT_FUNCTION
by Emil Dotchevski 06 Sep '08

06 Sep '08

It appears that BOOST_CURRENT_FUNCTION returns '(unknown)' on sun-5.7, sun-5.8 and sun-5.9, I'm looking at http://www.boost.org/development/tests/trunk/developer/output/Sandia-sun-bo…. Is this a bug, or is BOOST_CURRENT_FUNCTION not possible on that compiler? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

6 12