- Boost - lists.boost.org

[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

Lexical_cast improvement not included in 1_31
by Boost 12 Feb '04

12 Feb '04

| Subject: Lexical_cast improvement not included in 1_31 release | | I proposed some time ago an improvement to lexical_cast to | deal with the corner cases where there were insufficient | decimal digits to deal with some float values. For example, | a 'loopback' test should work for any type T and any value l: | | template <typename T> bool test(T l) | { | cout << l << ' '; | string sl = lexical_cast<string>(l); | cout << sl << ' '; | T ll = lexical_cast<T >(sl); | cout << ll << ' ' | << (l == lexical_cast<T>(lexical_cast<string>(l))) | // Convert type T to string and back to T. | << endl; // eg for long 2147483647 2147483647 2147483647 true | return (l == lexical_cast<T>(lexical_cast<string>(l))); | } // test | | The current version fails this test. | | There seemed no dissent at the time to calculating the | significant digits using std::numeric_limits<Target>::digits10 +1. | | But alas my suggestion (below) has not been included in the | latest release. | | lexical_stream() | { | stream.unsetf(std::ios::skipws); | // was: | /*if(std::numeric_limits<Target>::is_specialized) | stream.precision(std::numeric_limits<Target>::digits10 +1 ); | else if(std::numeric_limits<Source>::is_specialized) | stream.precision(std::numeric_limits<Source>::digits10 +1 );*/ | | Suggested: | | // New calculation to give more accurate number of | significant decimal digits: | // 32 significand bits | digits10 = 6 significant_digits10 = 9 | // 53 significand bits | digits10 = 15 significant_digits10 = 17 | // 64 significand bits | digits10 = 18 significant_digits10 = 21 | // 106 significand bits | digits10 = 31 significant_digits10 = 33 | // 113 significand bits | digits10 = 33 significant_digits10 = 36 | // 128 significand bits | digits10 = 38 significant_digits10 = 40 | | if(std::numeric_limits<Target>::is_specialized && | std::numeric_limits<Target>::radix == 2) { | stream.precision(2 + std::numeric_limits<Target>::digits * | 301/1000); } else | if(std::numeric_limits<Source>::is_specialized && | std::numeric_limits<Source>::radix == 2) { | stream.precision(2 + std::numeric_limits<Source>::digits * | 301/1000); } // Else if not specialized or unusual radix then | use default stream precision, probably 6. // All builtin | types, bool, char, integer and floating point, should be | specialized. } // lexical_stream() | | It is also irritating that current version produces a long | list of spurious 'error' messages which can avoided by | inheriting from boost noncopyable (suggested by Reece Dunn). | | What should I do to progress this? | | Prepare a Boost test for lexical_cast using the Boost Test framework? | | Paul | | Paul A Bristow, | Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB | +44 1539 561830 +44 7714 330204 | mailto: pbristow(a)hetp.u-net.com | |

1 0

[indexed_set] release 9 available
by Joaquín Mª López Muñoz 12 Feb '04

12 Feb '04

For those interested in indexed_set, release 9 is available at: http://groups.yahoo.com/group/boost/files/indexed_set.zip the sandbox version is not in sync, it'll be by tomorrow. New features: * Added a new index type called "sequenced", which sorts the elements in the order they were inserted. In fact, sequenced indices mimic the functionality of std::list, which allows to build, for instance, list-like containers with fast lookup (by combining a sequenced index and a non_unique index.) There're no docs about sequenced yet, but an example of use is provided (example 5 in the examples section.) * Added a new section with performance measurements, showing that in general indexed_set does it better wrt to memory and time than handcrafted compositions of containers. * indexed_set works with Boost 1.31.0 (some fixing had to be made because of changes in Boost.Iterator.) * Some internal improvements that do not affect the library interface. To be completed: * For the moment being, sequenced is not documented (save some scattered references to it.) The task is not trivial, because original docs were strictly focused on set-like indices, and large portions of the material will have to be rewritten. BTW, volunteers with skills at writing are most welcome. * Compiler status is outdated. The library has been confirmed to work in GCC 3.3.1, ICC 7.1 and MSVC 6.5. Reports about other compilers appreciated. As always, I'm very much interested in knowing others' comments about the library. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0