- Boost - lists.boost.org

[Range] Not reinventing the wheel!
by Robert Jones 06 Aug '08

06 Aug '08

I came to boost.range looking for, and expecting to find, everything I needed to able to uniformly apply standard algorithms to containers and arrays, and maybe other things too, and that seems to be what boost.range is about. Maybe I've missed something, but it seems to supply only the 'scaffolding' to allow me to do-it-myself? Is this right? Some of the examples show how to do this, but that was what I was expecting the library itself to so. Is there some component I've missed here, or perhaps an 'algorithm' library build on top of boost.range? Thanks, Rob. -- ACCU - Professionalism in programming - http://www.accu.org

3 3

Re: [boost] [operators] euclidean vs euclidian (was: fixed-pt [improved])
by Michael Fawcett 06 Aug '08

06 Aug '08

On Fri, Aug 1, 2008 at 10:17 AM, Hervé Brönnimann <hervebronnimann(a)mac.com> wrote: > This is not related to fixed-point per se, but why did boost.operators > choose the spelling euclidian instead of the more common euclidean? I did > check the Merriam-Webster, and both spellings are accepted (to my surprise), > but I believe that most mathematicians use Euclidean... I'm surprised too - I've never seen it spelled otherwise. I checked the APIs we're currently using and they all use Euclidean. Google pulls up 3,820,000 for euclidean, and 325,000 for euclidian (it also says "Did you mean: euclidean"). In Google Code Search it pulls up 44,600 for euclidean, and 7,000 for euclidian. --Michael Fawcett

3 2

Trying to fix -Wshadow warnings - some help needed.
by John Maddock 06 Aug '08

06 Aug '08

Folks I have a large amount of code that generates warnings of the kind: t.cpp:6: warning: shadowing built-in function `double std::acos(double)' Actually many thousands of these warnings when building with g++ -Wshadow :-( Normally I would just fix the code, but in this case I don't see how, I have code that looks like: #include <cmath> template <class T> T f(T v) { // We want acos found via ADL in case T is a class type: using std::acos; return acos(v); } int main() { f(2.0); return 0; } Which just on it's own produces: $ g++ -I. -Wall -Wshadow -c t.cpp 2>&1 | less t.cpp: In function `void f(T)': t.cpp:6: warning: shadowing built-in function `double std::acos(double)' t.cpp: In function `void f(T) [with T = double]': t.cpp:12: instantiated from here t.cpp:6: warning: shadowing built-in function `double std::acos(double)' t.cpp:12: instantiated from here But I can't see any other way to code this... certainly using a "using namespace std;" in place of the "using std::functionname;" is *not* a valid fix (it can lead to lookup ambiguities). Any ideas folks? Thanks, John.

4 5

[1.36.0 beta] Beta release available on SourceForge
by Beman Dawes 06 Aug '08

06 Aug '08

New libraries: Accumulators, Exception, Units, Unordered. Updated Libraries: Assign, Foreach, Interprocess, Intrusive, Math, Multi-index Containers, PtrContainer, Spirit, Thread, Xpressive, plus a bunch more. Many thanks to Daniel James, Rene Rivera, Marshall Clow, Eric Niebler, the testers, and all the others who helped to get this beta release together. The beta period will be approximately one week. Please post bug reports here, but also let us hear about success stories too! --Beman

3 3

[mpl] doc issues in release beta
by Eric Niebler 06 Aug '08

06 Aug '08

In the reference section of the MPL docs, there are a couple of issues. The biggest is that there is some new CSS wackiness that is making cross-links look like regular text until you hover over the links with the mouse. This is a regression from 1.35. The other issue is a broken link. In the reference section for mpl::for_each, there is a link to the docs for value_initialized that goes nowhere. This problem exists in the 1.35 docs as well. -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 3

Re: [boost] out of date release results?
by Eric Niebler 06 Aug '08

06 Aug '08

Beman Dawes wrote: > Eric Niebler wrote: >> >> Beman Dawes wrote: >>> Eric Niebler wrote: >>>> Just spoke with Rene about this ... >>>> >>>> Eric Niebler wrote: >>>>> How come the "report time" on nearly every page of release >>>>> test results is dated July 15th? >>>>> >>>>> For example: >>>>> http://www.boost.org/development/tests/release/developer/summary_release.ht… >>>>> >>> >>> AFAIK, that's the wrong page to be looking at. The page I use to >>> make decisions is >>> http://beta.boost.org/development/tests/release/developer/summary.html >>> >>> >> >> Whew, thanks Beman! How do you get to that page? I go to boost.org, >> click on "Development", and then on "Release Summary". > > I don't look at www.boost.org, because I assume it applies to the > current release. > > Instead I look at beta.boost.org, because I assume it applies to the > release under development. Then why does www.boost.org have results for Boost.Accumulators (some of which are quite out of date), when Accumulators is new in 1.36. In particular, I never saw your response to this exchange from yesterday. I think this is a serious problem: Rene Rivera wrote: > Eric Niebler wrote: >> >> Oh whoa. Something really strange is going on with these pages. >> >> These results are old: >> http://www.boost.org/development/tests/release/developer/accumulators_relea… >> >> These results are new: >> http://www.boost.org/development/tests/release/developer/accumulators.html >> >> I can reach either page via different sequences of clicks. At first >> I thought that maybe one page represents results from 1.35, but >> that's not possible because accumulators wasn't in 1.35. >> >> What's going on? > > This sounds like the release view of the results is not getting > generated, on Beman's machine, and it's using some old set of > results. Hence only the developer view has the current results. Thoughts? <snip> >> >> OK, but that doesn't address the concern about test reporting. >> Currently, it takes a human (you, Rene, people on the boost-testing >> list) to manually verify that the results are being updated. > > Say we had a tool that looked at web pages to see if they had been > updated, and sent email if not. We would point it at > http://beta.boost.org/development/tests/release/developer/summary.html, > and set the required update frequency to say 24 hours. The email > address could be set to either the testing list, the site admins, > release managers, or whoever else was interested. That would not be good enough unless it checked every web page with test results on it. For instance, checking summary.html as you suggest would reveal nothing amiss, however this page on beta.boost.org is out of date: http://beta.boost.org/development/tests/release/developer/summary_release.h… -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

[atomic count] boost on apple gcc 4.2
by David Abrahams 06 Aug '08

06 Aug '08

Well, first, I think you prolly ought to be posting to the developers' list, and second I think you need a tag in the subject like "atomic count" so that the right people will look at it :-) on Thu Jul 31 2008, "Mat Marcus" <mat-lists-AT-emarcus.org> wrote: > On Mon, Apr 28, 2008 at 3:22 PM, Peter Dimov <pdimov(a)pdimov.com> wrote: >> Daniel Oberhoff: >>> Hi, >>> >>> Has anyone successfully used boost with the "new" apple gcc 4.2? I >>> would like to since gcc42 has openmp, but I cant seem to be able to use >>> boost. I compiled and installed boost with apple gcc 4.2 by directly >>> using bjam with --toolset=darwin-4.2. When I try to use it I get an >>> error (detailed output of gcc below) which hints towards problems with >>> inline assembly. Actually, to get it compiled at all I had to set >>> -fasm-blocks. Am I missing a flag of sorts? Or is it "just" another woe >>> with apple's modified assembler? >> >> Is the new Apple GCC documented somewhere? I wasn't able to find anything >> related to a new assembler syntax or -fasm-blocks. Can you ask Apple to >> explain the issue? Stock g++ 4.2.x compiles the code, so the problem must be >> Apple-specific. > > Ok, I've got a little bit more information on the Apple gcc 4.2 > situation. Here is a snippet from an email dialog between a user and > an apple compiler engineer: > > user appears below with with prefix ">>" > apple compiler engineer appears below with with prefix ">" > >>> Thank you very much for the detailed reply. >>> Based on your information I deduce: >>> >>> 1) Using gcc 4.2 with 4.0 (c++) libraries is a supported >>> configuration by Apple >> >> Right. >> >>> I then conclude that the C++ ABI is fully compatible between 4.0 and >>> 4.2 >> >> Right. > > [snip, then user hypothesizes as to why there are problems with boost > under gcc 4.2/libstdc++ 4.0 on current Apple systems] > >>> This is the case because boost assumes that a 4.2 compiler implies >>> 4.2 libraries in flies such as boost/detail/atomic_count_gcc.hpp: >>> >>> #if (__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 2)) >>> # include <ext/atomicity.h> >>> #else >>> # include <bits/atomicity.h> >>> #endif >> >> Yes, this is a bug or faulty assumption in boost. > > [snip] > >> The 4.2 library issue is a bug in Boost, not a problem with >> our compiler. I'd suggest raising the issue on one of the boost >> mailing lists and see what they say. > > Comments? > Mat > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users > -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 0

[sandbox][move] Regular requirement
by Michael Marcin 06 Aug '08

06 Aug '08

I'm using the current move library in the sanbox by daniel james (which I believe is the 4th move emulation library I've used now). It seems to be very good so far and makes writing code that handles both move and copy a breeze. I hope this gets finalized and ready for review soon because a consistently used move emulation library would be a great aid to writing efficient libraries that work well together. However the documentation says that objects have to model the Regular concept in order to model the Movable concept. This seems unfortunate as Regular puts a lot of requirements on types that don't seem necessary to gain moving. It requires Assignable which requires a copy constructor and it requires EqualityComparable which seems unnecessary. As a matter of fact I'm currently using the library with types I derive from boost::noncopyable on msvc 2008 and it is working wonderfully. Can the Movable concept be relaxed to require only what is truly necessary? Thanks, Michael Marcin

3 3

fixed pt binary lib
by Neal Becker 06 Aug '08

06 Aug '08

I have the beginning of a fixed-pt binary lib. Fixed-pt is popular in DSP applications. It is integer arithmetic, but keeping track of the binary pt. It is built on top of constrained_value. It is small, so I include it here:

8 22

Re: [boost] out of date release results?
by Eric Niebler 06 Aug '08

06 Aug '08

Beman Dawes wrote: > Eric Niebler wrote: >> Just spoke with Rene about this ... >> >> Eric Niebler wrote: >>> How come the "report time" on nearly every page of release test >>> results is dated July 15th? >>> >>> For example: >>> http://www.boost.org/development/tests/release/developer/summary_release.ht… >>> > > AFAIK, that's the wrong page to be looking at. The page I use to make > decisions is > http://beta.boost.org/development/tests/release/developer/summary.html Whew, thanks Beman! How do you get to that page? I go to boost.org, click on "Development", and then on "Release Summary". That takes me to: http://www.boost.org/development/tests/release/developer/summary.html That page *was* dated July 15, but Rene fixed something and now it seems to be up to date. Which is the correct site for results? Why do we have two? And why was boost.org directing me to stale results on www.boost.org instead of the fresh results on beta.boost.org? Rene? > The date on that is Sun, 3 Aug 2008 10:16:33 +0000. That's the last run > before I shut the machine down for maintenance. It is back up now and > should produce an updated report in an hour or two. > >> We should *all* be checking the release test results, especially the >> release manager. > > I look at the results several times a day during critical times, such as > when when preparing the beta. Glad to hear you're on top of this! >> How did this happen? Here are some hard questions. > > No clue. I have no idea how the results on the www.boost.org web site > get updated from the beta.boost.org web site. IMO, the test results should live in *one* place, and all the links should point to it. >> On what basis did we release the beta? > > The beta was released on the basis of a release report that was only a > few minutes old. > >> (That is, do we have release criteria? Written down?) >> Do those criteria have anything to do with the test results? > > Of course. The results speak for them; most of the remaining failures > are minor nits or even false positives. > >> Is anybody in charge of the test infrastructure? > > Rene works on the scripts, but a lot of the responsibility is > distributed or ill-defined. Hmm... >> Does that person look at the test results? >> What can we do to make sure this doesn't happen again? > > Take a look at ticket #2150. http://svn.boost.org/trac/boost/ticket/2150 > > That's one attempt at automatic tools to look for things that have gone > wrong and report them quickly. It will work on files, from the > repository or generated by the doc process. > > A similar tool that looked at web sites would be a nice QA addition. It > would check for the presence of specified files and verify their date > was recent, for a definition of recent specific to each file. Maybe > check file size, too, or even some content. OK, but that doesn't address the concern about test reporting. Currently, it takes a human (you, Rene, people on the boost-testing list) to manually verify that the results are being updated. >> Clearly, we need to delay 1.36 until we can get some fresh test results. > > The test results are currently being updated several (up to eight) times > each day. > >> And probably reopen the release branch for bug fixes. > > I posted a message several days ago indicating that the release branch > was open to bug fixes that are stable on trunk. OK. But I wonder if there are other people like me who were looking at stale results. :-P -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 3