February 2004 - Boost - lists.boost.org

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

any smart pointer alternative suggestions?
by Trey Jackson 12 Feb '04

12 Feb '04

All, I'm loving the shared_ptr class, however we have one issue that doesn't seem to be addressed by any of boost's smart pointers, and I'm looking for a work-around/alternative. Any help? The issue is that the smart pointers assume the pointer type to be 'T*', which is fine on a 32-bit system, but means that we get a near doubling of run-time size on our application when we move to a 64-bit application. As a result, we're using the standard technique to have a custom heap, and use our own 'pointers' into that heap that are smaller (typically 32-bits). But of course our ClassOnHeapPtr type does not match a 'ClassOnHeap *', so a boost::shared_ptr<ClassOnHeap> won't work. Are there any other libraries you boosters would recommend? thanks for any info... TJ -- Trey Jackson tjackson(a)ichips.intel.com "This is gonna cost me." -- Homer

5 5

Passing value safely to functions
by Michael D. Borghardt 12 Feb '04

12 Feb '04

This started with looking at sign/unsigned interfaces and how to handle range problems. Now this looks to me to handle any numeric conversion problems. Comments, and criticisms welcome. #include <boost/numeric/cast.hpp> template<typename Target> class numeric_class { public: template<typename Source>numeric_class(numeric_class<Source> &s) { value_ = boost::numeric_cast<Target>(s); } template<typename Source>numeric_class(Source s) { value_ = boost::numeric_cast<Target>(s); } numeric_class(Target s) { value_ = s; } template <typename Resultant> operator Resultant() { return boost::numeric_cast<Resultant>(value_); } operator Target() { return value; } private: Target value_; }; void Bar(numeric_class<unsigned long> ul) { // we know that value in ul is in range if we get here } numeric_class<float> Foo(numeric_class<unsigned long> ul) { // we know that value in ul is in range if we get here return numeric_class<float>(ul); } int main () { try { float f = 5.5; numeric_class<unsigned long> ul(f); char c1 = ul; // function interface converts float to unsigned long AND checks to make sure it is in range Bar(f); // function interface converts char to unsigned long AND checks to make sure it is in range // return float that is in range f = Foo(c1); // if we get here we have a valid f } catch(std::exception const &ex) { std::cerr << "EXCEPTION: " << ex.what() << "\n"; } return 0; }

1 0