- Boost - lists.boost.org

[OT] CPH (Copenhagen) STL
by Hal Finkel 24 Dec '10

24 Dec '10

Hello, I have no connection to the CPH STL project, but I have spent several hours looking over their technical reports, and a number of them are quite interesting. They detail research into different implementation choices for the STL containers and some of the algorithms, and have benchmarks, practical implementation notes, etc. Many of the reports even include full source code in the appendices. http://www.cphstl.dk/WWW/reports.html For example, I recommend looking at: 2004-2 - Mads D. Kristensen: Vector implementation for the CPH STL Even though these are academic in nature, unlike most papers about data structures which I've read, they deal explicitly with the issues associated with actually creating STL-compatible containers (with the associated iterators). This seems to be an active project, with work ongoing through this year. There is also some source code posted, although I was not able to find any licensing details. I hope everyone has an enjoyable holiday season! -Hal

2 1

Re: [boost] Interest in a list comprehension library?
by Brent Spillner 24 Dec '10

24 Dec '10

On 21/12/2010 09:09, Mathias Gaunard wrote: >Can you explain the difference with the Boost.Range adaptors? I think these are the most important ones: * Lazy evaluation of every comprehension. In contrast, boost::filter_iterator applies the filter predicate to the entire wrapped range at construction time (via satisfy_predicate().) * As a consequence, there are several ways to limit the amount of computation based on the amount of output required rather than the length of the input ranges. * Predictable backtracking behavior that allows filter criteria to depend on each other. This enables a number of computations (e.g. looping over the elements within a range of ranges) that are otherwise difficult or impossible to express, and even in straightforward cases permits some efficiency improvements. For instance, your example Pythagorean triple comprehension using Boost.Range evaluates a number of combinations of the three indices equal to the n'th cubic number, while the 'i <<= range(1,n), j <<= range(i,n), k <<=range(j,n)' version evaluates the n'th tetrahedral number's worth of combinations. The ratio of these quantities approaches 6 as n increases, and is in fact greater that 5 by n=16. A factor of 5 speedup is surely worth something. * Somewhat more concise and I believe more readable syntax. My goal was to require fewer characters than a Python comprehension and ideally not many more than Haskell, and I think I'm there in the simple cases. (Neglecting the variable declarations, naturally.) >It is true Boost.Range is quite lacking in terms of range generators, and maybe your solution is what we need. Don't get me wrong; I think Boost.Range is great, and the iterator adapters are a fantastic way to improve the iterator-based algorithms that tend to be somewhat clumsily expressed in a lot of traditional C++ code. I just don't think they're a fully satisfying substitute for the comprehension syntax (and backtracking, etc.) provided or easily defined in most functional languages. >It would be nice however, if it didn't reinvent the wheel and can be based on Phoenix for the functional part. I definitely don't want to reinvent the wheel, and I was a little hesitant to publish this in case it largely duplicated work that someone else had done in Range or Phoenix or somewhere else. I've never used Phoenix; it seems fascinating but I'm a little wary of making it a dependency just to get something simple like a comprehension syntax. I also took a look at using Boost.Proto to provide the expression trees, but it seemed that the syntax was a little more verbose than it needs to be for things that will be evaluated only in the context of a comprehension expression. Either one of those libraries could likely replace most of the boilerplate in my expressions.hpp and operators.hpp; on the other hand, being boilerplate, it wasn't that hard to write or to get it to work exactly as I needed. At this point I'm leaning more toward providing adaptors to permit Proto or Phoenix expressions within a comprehension, rather than absolutely requiring the use of either.

3 3

Re: [boost] [Boost-users] [units] Automatic Physical Units in Mathematica and Boost.Units
by Matthias Schabel 24 Dec '10

24 Dec '10

Alfredo, As one-half of the Boost.Units developer's community (actually I should also give due credit to Torsten Mähne for contributing the lambda component), I'll try to answer your questions : > Does any body have experience with using boost.units quantity with a > underlying type that are not double, e.g. multiple precision, or > vector (geometric) objects? Does it work well? For "well-behaved" types, Boost.Units should work transparently. See the examples for complex and measurement types. I believe there are some users who have applied Boost.Units to vectors in varying coordinate systems as well. > Are there future planned developments for Boost.Units, in terms of > external features (e.g. automatic conversion, better interaction with > boost.phoenix) or internal implementation? Automatic conversion is a much-requested and highly contentious issue that we intentionally did not support in the library, making the decision after much careful consideration. It is difficult to do it correctly - in the situation where you have, e.g., mixed meters and feet : 1.5*meters + 3.7*feet either there must be a specified default set of units to which everything is converted or an arbitrary decision must be made by the compiler. While it probably doesn't matter too much in this case, and for MP numeric types it shouldn't matter at all (excepting execution time), there are possible unit combinations where truncation/ round-off could become a problem. There is no obvious way to determine this at compile-time. Why not just explicitly specify your default units of choice in your code - this is self-documenting and should be consistent and correct. Do you have a use case where the requirement of explicit unit specification is excessively problematic? As far as Boost.Phoenix, what are the concerns? While I can't speak for Steven, I personally do not have a tremendous amount of time or resources to devote to Boost.Units on an ongoing basis; my bread-and-butter work is in medical imaging and, therefore, Boost.Units is a somewhat tangential project. That being said, one of the beauties of the open source model is that other interested parties (you, perhaps) are welcome to extend the work. Going from code that works for your particular application to code that is Boost-ready is non-trivial, but there are quite a number of people who can help provide advice. Boost.Units.Phoenix would be, I'm sure, a great addition to the library. As far as internal implementation, what are the concerns? Best, Matthias

1 0

[move] Review result pending since May !!!
by Vicente Botet 23 Dec '10

23 Dec '10

Hi, The Boost.Move library is a important library that will allow to adapt a lot of libraries to a common Move semantics. The review result is pending since May 2010. I want to request the review manager Overmind1 to give the result of the review as soon as possible. If you think that you can not do it in a short time, I think that we will need a volunteer to make the result report (of course if there is one) Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/move-Review-result-pending-since-May-tp3… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[Bug Sprint] Final report for the (late 2010) Bug Sprint
by Marshall Clow 23 Dec '10

23 Dec '10

Well, the bug sprint is over. [ But that doesn't mean you have to stop fixing bugs if you don't want to! ] There were 25 changes to the trac database yesterday - not counting all the spam. [ I'd like to say "25 tickets were changed", but some tickets were changed more than once. ] In this sprint, we looked at (and modified) a couple hundred tickets, resulting in a net drop of 16 tickets from the start of the Bug Sprint. General information about the bug sprint is here: https://svn.boost.org/trac/boost/wiki/BugSprintNov2010 General information about how the Trac system works is here: https://svn.boost.org/trac/boost/wiki/TicketWorkflow Overall bug count: November 26: 946 November 27: 939 November 28: 930 November 29: 934 (whoops, that's the wrong direction!) November 30: 931 (better, but the delta is too small) December 1: 929 December 2: 930 December 3: 933 (ouch!) December 4: 931 December 5: 934 (ouch, again!) December 5: 930 Activities on the trac system yesterday: New tickets 4 Tickets closed 5 Tickets reopened 1 Tickets changed 15 [ Some other changes happened after midnight; hence the difference between the deltas and the total # of tickets ] marshall 8 rleigh@ 3 jwellico 2 andysem 2 altsysreq@ 2 --others-- 8 So - what did people think went well during the bug sprint? What went poorly? What can we do better next time (assuming that there is a next time)? -- Marshall

16 25

svn.boost.org is down
by Mateusz Loskot 23 Dec '10

23 Dec '10

Hi, The svn.boost.org (http and https) is not responding. I confirmed it with a few people on the IRC channel. Could anyone resurrect it? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

1 0

Proposed changes to page running_regression_tests.html
by Jim Bell 22 Dec '10

22 Dec '10

I propose these changes to boost's web-page <http://www.boost.org/development/running_regression_tests.html> I've attached the full file. My change is at the beginning: how to run regression tests locally. The previous contents follow, under "Running Boost's Automated Regression and Reporting." Comments welcome. Who would actually make the change?

3 2

[PATCH 2/2] Fixed warning: use of logical && with constant operand; switch to bitwise & or remove constant [-Wconstant-logical-operand]
by Vasyl' 21 Dec '10

21 Dec '10

--- boost/uuid/name_generator.hpp | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-)

2 1

[OT] Open Source Forking and Boost (was Re: [SQL-Connectivity] Is Boost interested in CppDB?)
by Dean Michael Berris 21 Dec '10

21 Dec '10

On Wed, Dec 15, 2010 at 7:35 AM, Mateusz Loskot <mateusz(a)loskot.net> wrote: > Hi, > I will only refer to complain on the slow SOCI release schedule. > So, instead of deciding to join an existing project, which N.B. you have used with some degree of success, and help > to speed its release process, help with fixing bugs and propose to add features you are missing, you decide to fork it, tweak it and release it. I'm not sure but is CppDB a fork of SOCI? If that was the case, then the original copyright holders of the original code would have to be consulted if the fork was going to be released under a different license. IANAL, but there may be some issues with forking a BSL-licensed project to be an LGPL project. > > This is not how FOSS works to make a project healthy and sustainale in long term. Your observable disappointment about > software here makes me asking, what's next? Boost libraries forked? > Well... actually... forks are a valid means of diversification in FOSS projects. Whether it's successful in what the fork is supposed to achieve is a different issue altogether. About Boost Libraries being forked, I don't think that's inherently a bad idea -- especially since there's already a number of Boost libraries that seem "unmaintained". The only issue I see with forking Boost libraries at this time is the infrastructure used to host the code; SVN wasn't meant to encourage forking compared to say how Git or Mercurial allow forking to be as trivial as branching and merging. I'll leave my comment on SVN at that at risk of inciting the SCM debate yet again. ;) > Anyways, I'm just disappointed how much FOSS is ego-driven > where it should mean collaboration. Just pity. > +1 in general. -- Dean Michael Berris deanberris.com

11 34

Boost Users Map
by Dean Michael Berris 21 Dec '10

21 Dec '10

Good day everyone! Thanks to the great idea that some people on the #boost IRC channel in FreeNode proposed, (thanks to heller, mjcaisse, for the prodding and the ideas) I've started a Google Map to show where in the world Boost Users are -- please feel free to add yourself and your location and maybe connect with other Boost Users in your area! You can add yourself to the map from here: http://goo.gl/RbmNq -- it might require that you log in using your Google account for you to add your location to the list. Please add yourself to the map and be counted -- show how well Boost is used around the world! Thanks in advance and I definitely look forward to seeing users of Boost around the world at least in the map! -- Dean Michael Berris about.me/deanberris

1 0