- Boost - lists.boost.org

libs/iterator/doc/iterator_facade.html typo?
by Angus Leeming 13 Feb '04

13 Feb '04

libs/iterator/doc/iterator_facade.html#tutorial-example In the section "Template Arguments for iterator_facade" is the subsection "CategoryOrTraversal". I suspect that should be "CategoryOfTraversal" (s/Or/Of/). The iterator_adapter docs spell it "CategoryOrTraversal" too. Regards, Angus

3 13

RE: [boost] Re: 1.31.0 regressions
by Rozental, Gennadiy 13 Feb '04

13 Feb '04

> > Say a library now covers 100 test cases spread out among five test > > programs. I'd like to see those five programs refactored into one > > program, still covering the 100 test cases. Or even adding more test > > cases. A single program would cut the overhead, including the human > > overhead. Sorry I missed the beginning of the thread: how would having one program help? > There are at least three drawbacks to this approach: > > 1. "something is wrong" is all the information you get from > a failing test. Esp. you'll likely see only one of several > problems related to a failing test program. The next > problem will only become visible after the first problem > has been fixed. This is not necessarily true. If one uses Boost Unit test framework you most probably get all the errors in one shot. > 2. Some tests are known to fail for certain compilers. > If those tests are joined with other tests then we'll > lose information about these other tests. If it runtime errors you could rely on "expected errors" feature. You are right for compile time errors, though one could try to ifdef part of test program. Gennadiy.

3 3

[boostbook] setup documentation minor nit:
by Ronald Garcia 13 Feb '04

13 Feb '04

Howdy, In the documentation for setting up boostbook located at: http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/boostbook.g… The path "tools/build/new" is mentioned as the location of user-config.jam. It appears that the path has since changed to "tools/build/v2". cheers, ron

2 1

1.31.1 critical update patch?
by David Abrahams 13 Feb '04

13 Feb '04

We need to fix the regressions in 1.31.0 right away. Since I don't have time to manage a release, and nobody else has volunteered to do it, I'd like to suggest that we post a 1.31.1 "critical update" patch for 1.31.0 on the website. This would save us from having to deal with a site update or making new release archives until someone can really devote the attention a full release deserves. Thoughts? -- Dave Abrahams Boost Consulting www.boost-consulting.com

4 3

broken image on the web pages?
by Ronald Garcia 13 Feb '04

13 Feb '04

Howdy, If I go to http://www.boost.org/ and select "Nightly CVS" Under "Documentation", I find a broken image in the top left corner where I would expect to see the Boost logo. I'm presuming that this page is autogenerated from boostbook? Cheers, ron

1 0

Constructing boost::posix_time::ptime from "flat" time?
by charles.crain＠ni.com 13 Feb '04

13 Feb '04

I am having a hard time figuring out how to construct a ptime from a "flat" time (i.e., some number of time units since some epoch) other than a time_t. For instance, we have a lot of software here at work that represents time as a double-precision floating point number of seconds since 1/1/1904 00:00:00 GMT. As you can imagine, any sensible number is bigger than a 32-bit integer. I would like to be able to construct a ptime something like this: ptime p(date(1904, Jan, 1), microsec(boost::int64_t(float64_time * 1000000.0)); ...or even better... ptime p(date(1904, Jan, 1), float64_time); Problem is, it seems the constructors to most time_duration types use longs, even if they use int64's internally. I can't get the above example to work with any time past 12/31/1904 23:24:12, which just happens to be 0x80000000 microseconds past 1/1/1904. Another thing I would like to do is construct a ptime from a Win32 FILETIME, which is an int64 number of 100ns intervals since 1/1/1601. Something like this: ptime p(date(1601, Jan, 1), nanosec(100 * fileTime)); Is there a better way to do this? I am using MSVC 6.0 SP5 with Boost 1.31.0. -Charles

3 5

boost::function & gcc 2.96 problem
by Ralf W. Grosse-Kunstleve 13 Feb '04

13 Feb '04

Because of a problem in boost/function/function_template.hpp Boost.Python in the current CVS HEAD does not compile with gcc 2.96 under RedHat 7.3. Attached is a suggested workaround (tested with gcc 2.96 and EDG 245). Ralf Index: function_base.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/function/function_base.hpp,v retrieving revision 1.72 diff -u -r1.72 function_base.hpp --- function_base.hpp 11 Feb 2004 18:16:55 -0000 1.72 +++ function_base.hpp 12 Feb 2004 22:01:42 -0000 @@ -188,8 +188,10 @@ // The trivial manager does nothing but return the same pointer (if we // are cloning) or return the null pointer (if we are deleting). template<typename F> - inline any_pointer - trivial_manager(any_pointer f, functor_manager_operation_type op) + struct trivial_manager + { + static inline any_pointer + get(any_pointer f, functor_manager_operation_type op) { switch (op) { case clone_functor_tag: return f; @@ -209,6 +211,7 @@ // Clears up a warning with GCC 3.2.3 return make_any_pointer(reinterpret_cast<void*>(0)); } + }; /** * The functor_manager class contains a static function "manage" which Index: function_template.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/function/function_template.hpp,v retrieving revision 1.70 diff -u -r1.70 function_template.hpp --- function_template.hpp 24 Jan 2004 23:31:40 -0000 1.70 +++ function_template.hpp 12 Feb 2004 22:01:42 -0000 @@ -508,7 +508,7 @@ invoker_type; invoker = &invoker_type::invoke; - this->manager = &detail::function::trivial_manager<FunctionObj>; + this->manager = &detail::function::trivial_manager<FunctionObj>::get; this->functor = this->manager( detail::function::make_any_pointer( @@ -529,7 +529,7 @@ >::type invoker_type; invoker = &invoker_type::invoke; - this->manager = &detail::function::trivial_manager<FunctionObj>; + this->manager = &detail::function::trivial_manager<FunctionObj>::get; this->functor = detail::function::make_any_pointer(this); } __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

4 6

Any news about the formal review process re-animation?
by JOAQUIN LOPEZ MU?Z 12 Feb '04

12 Feb '04

Some weeks ago it was discussed in the mailing list how to boost the review process which seemingly had stuck for quite a while. Unfortunately the discussion seemed to fade away with no definitive conclusions. Could it be possible to know what the status of the review queue is? The review schedule page does not seem to have changed since the discussion took place. I'm interested myself because I applied for formal review some time ago. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] Re: 1.31.0 regressions
by Robert Ramey 12 Feb '04

12 Feb '04

Beman Dawes wrote >It comes down to resources. I suppose if people really care about older >compilers, they will be willing to contribute testing. I still think a platform guru would be a useful function. This Person would run the tests on his local resources for a particular Platform and help with issues on that platform. Such a person would Have similar status to that of a library maintainer. >Say a library now covers 100 test cases spread out among five test >programs. I'd like to see those five programs refactored into one program, >still covering the 100 test cases. Or even adding more test cases. A single >program would cut the overhead, including the human overhead. I would strenuously disagree with this idea. In some cases it would result in a truly humongous program. When I included a test of this nature with my submission last year it was criticized for the above reason - rightly so in my opinion. There are lots of other problems besides. Suppose a test case doesn't compile - then none of the other tests are run. I'm still convinced that the problem with the release process is rooted In developer's desire to include features directly into release "heaven" Without having spent time in development "purgatory". Is_abstract and Autolib come to mind. The branch was announced approx 1 november. The autolib document is dated 26 November. Can't someone just monitor the state Of the development tree and when it looks pretty good say "We're branching today - nothing but bug fixes in the release". The current process is so Painful and takes so long that developers feel under pressure to get the Latest great feature in now because if not its going to take 6 months for The next one. Under this proposal, releases could be more frequent and In smaller increments. After all what's the point of running the tests on The development tree on a daily basis if its going to be more or less Bypassed under pressure for a release? Robert Ramey

1 0

A VC6 bug in const_reverse_iterator implementation?
by RGProlog＠aol.com 12 Feb '04

12 Feb '04

I tried to createa const_reverse iterator for the Dynamic Multi Array Library non constant object. It did not work. I then tried the same thing for Boost.Array with the same result. Which made me suspect it was the const_reverse_iterator implementation problem. Any answers? Roman Gitlin

2 1