- Boost - lists.boost.org

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

[function] timing trivia
by Matthew Hurd 12 Feb '04

12 Feb '04

Just a note to say thanks for boost::function ;-) Just completed some timings of the cost of a boost function call using a boost::function<void (void)> and a raw function pointer versus inlining the function's code directly into the source. For my circumstances (your mileage may vary): Calling via raw function pointer = 314 microseconds +/- 1 Calling via boost function variable = 328 microseconds +/- 1 Only 14 microseconds of difference. Nice work, I was expecting much more. Regards, Matt Hurd. Note: Optimised VC7.1 output, winXP 1a, Athlon 2800+ (2.09GHz)

3 5

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

12 Feb '04

> One small addition to the regression presentation that would > help would be a view organized first by library, and then by > OS/compiler. Currently I have to click all over the place to > find the results for a single library. > > Cheers, > Jeremy Second that. Though it will require extra work. Gennadiy.

1 0

<boost/pending/*.hpp> documentation, examples, and bugs.
by Cromwell Enage 12 Feb '04

12 Feb '04

I'm assuming "ground zero" here also means "square one" :) Preliminary documentation and an example program for <boost/pending/indirect_cmp.hpp>, <boost/pending/mutable_queue.hpp>, and <boost/pending/fibonacci_heap.hpp> can be found at: <http://groups.yahoo.com/group/boost/files/pending/> Bugs: The mutable_queue constructor that takes InputIterator arguments is push()-ing each element twice, because the the internal vector c is first initialized with the elements, then each push() in the while loop adds each element into c again. The example program demonstrates this. The fibonacci_heap fails at the first assert() during pop(). More to come! Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

1 0

VTL question (sorry if this is slightly off-topic)
by Matt Verona 12 Feb '04

12 Feb '04

Hello, I was reviewing the View Template Library (VTL) - see http://www.zib.de/weiser/vtl/ ... and have a few questions regarding Views as applied to STL Maps. I was also wondering if Boost was planning to eventually provide a VTL-like framework? I'm looking for a type of View that provides read-only access to an STL map, with only const iterators, but also provides limited insertion and removal access as well (as shown below): This new limited View-like map will only allow clients to iterate using const iterators, and also provides only one public insert(const key&) and one erase(const key&) method. These insert and erase member functions need to be implemented as "Template Method Functions", as follows: (see Design Patterns) * Note: these are shown using the latest SGI STL implementation (i.e., the _M_t.insert_unique and _M_t.erase calls) virtual bool preInsert(const value_type&) { return true; } pair<iterator, bool> insert(const value_type& x) { if(preInsert(x) { return _M_t.insert_unique(x); } return make_pair(end(), false); // make compiler happy } virtual bool preErase(const key_type&) { return true; } size_type erase(const key_type& x) { if(preErase(x) { return _M_t.erase(x); } return 0; // make compiler happy } The preInsert and preErase methods are virtual Hook Methods, and derived classes override these to add behavior to the (non-virtual) insert and erase functions.. Another nice addition to this map view would be a const _Tp& operator[](const key_type& k) const function, implemented something like this: const _Tp& operator[](const key_type& k) const { const_iterator i = lower_bound(k); if(i == end() || key_comp(k, (*i).first)) // if i->first is >= k throw SearchError(k); return (*i).second; } * Note: this simple implementation assumes that the key can be converted to a string in the constructor of the SearchError exception object. I have at least three Manager-like (Mediator) classes that can use this pattern (i.e., derived from this Map View class) as well as others that need a vector view with a similar filtered design... Thanks in advance, ~Matt Verona Houston, Texas USA

3 2

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

12 Feb '04

> What about generating an email to the maintainers of the > corresponding library, which makes sure they will know about > a failed test ... :-) I do not mind. If it will only happened once - when test start failing. Or anytime test status changed. It may be convenient also to notify when kind of error test reports changed, but it's quite difficult to analyze in generic fashion. Gennadiy.

2 1

RE: [boost] Boost Test Framework - log and report files
by Rozental, Gennadiy 12 Feb '04

12 Feb '04

> 1. I need to have the test log and report written to two > separate files in xml format. (It would be nice to have a DTD > of both xml formats) Ok. Will do. Will the schema work? < I did this by instructing the framework > with the command line argument: --output_format=XML. Now that > I had both the log and result report in XML format I needed > to create two file streams to redirect the output of them to > each their own file. This was easy to achieve with the log > using the set_log_stream method, but not so trivial with the > result report. Calling the singleton of the result report > before the test framework has initialized my code first calls > a null pointer crashing the test. How should this be done? > The documentation states that the interface of the > unit_test_result does not need to be used directly, but in my > case where I want a file stream instead of the std::err I > need to have access to the singleton and preferable in the > same place I set up the rest of my test suites. First of all why would you need to do anything? By default log goes to std::out and report goes to std::err. Also as you mentioned log output stream could be reset using set_log_stream method. This should be enough for your purposes As for report output stream it's actually unit_test_main who is responsible for setting specific stream and it not configurable at the moment. > 2. To achieve pt 1 I needed to edit unit_test_framework.hpp > (I think). I wanted to add support for my own command line > argument which would instruct the framework of the two files > I would like to create. So I thought it would be convenient > to use the reteive_framework_parameter method to retrieve my > custom command argument. Sadly enough I noticed that the > method doesn't return the value assigned to my argument > unless it is recognized. Is this fair? Yes. This is true. reteive_framework_parameter only strips parameters from command line that it knows about. The rest you are getting in init function. You could use any method to retrieve the value needed for you. Actually CLA support will be the first thing I am going to rework completely for next release. I think it should address your concern either. See mailing list for updates. > Daniel R. Kåsa > Gennadiy.

1 0