- Boost - lists.boost.org

Re: [boost] Boost Iterable Range Library update (v1.5)
by Richard Peters 16 Nov '04

16 Nov '04

"Robert Ramey" <ramey(a)rrsd.com> wrote in message news:cmrl55$hng$1@sea.gmane.org... > "Thorsten Ottosen" <nesotto(a)cs.auc.dk> wrote in message > news:cmrk1g$f70$1@sea.gmane.org... > > > Here's my general take on it: iterators are important and useful as the > > lower-level > > infrastructure. iterators are, however, not too user-friendly; the > > user-friendly interface > > can be build on top so easy task becomes , well, easy. and that is the > purpose > > of ranges and johns range library. > > without a good iterator library underneith ranges where hard to craft, but > now > > that we have a good iterator library, we should persue > > higher abstractions > > I agree that iterators aren't that easy or intuitive to work with. So our > motivations have much in common. My view is that iterators can be made > easier to work with without changing their fundamental character and without > the need to introduce what I see as a new concept (ranges) that is "almost > the same" as an existing concept - pair of iterators. > > Robert Ramey While iterators are very good at what they do -- provide access to elements in a sequence -- they do not capture the concept of a sequence very well. If I want to access a sequence of elements, I'd like to see a clean front-end, and I believe that John's range library can provide me with such a clean front-end. Using for_each(s.begin(), s.end(), ...) is too low-level, it exposes details of a sequence that I do not want to know. I do not want to for_each on a begin and an end, I want to for_each on a sequence: for_each(s, ...). It's a conceptual layer, admittedly a small one, but it provides a great front-end for the back-end of iterators. std::pair<iterator, iterator> fails at creating a decent front-end. For one thing, the iterator type must by typed twice. This adds quite some text. Secondly, it stays in the 'begin-end' concept, instead of advancing to a real range, of which you can extract an element and advance to the next by shrinking the range. You said before that the STL had a very good reason to use iterators. I agree there, iterators are very effective at what they do, but I'd like a higher-level interface built on top of that. For me, the following example from the Range Adaptors and Composition(s) documentation illustrates that: // [1] print all even elements (not using range adaptors) typedef boost::filter_iterator<array> filter_iterator; rng::for_each( irange<filter_iterator>( filter_iterator(some_array.begin(), is_even), filter_iterator( some_array.end(), is_even), print ); // [2] print all even elements (using range adaptors) rng::for_each( filtered(some_array, is_even), print); [1], while already using ranges, is easily rewritten to an iterator-only version. In [1], two iterators have to be wrapped with a filter_iterator constructor, both containing the same predicate. In [2], a range adaptor is used, and the predicate need only be given once. When I read the second version aloud, I hear exactly what I want to hear: "Take the elements of some_array, filter out the even elements, and print them". With [1], it's much more difficult to read it aloud. It also contains redundancy: is_even is passed twice. While possibly even error-prone, I think this is just ugly. It's not filter_iterator's fault, the filter_iterator is great at what it does, but it is the range adaptor that wraps it up nicely and provides a clean interface to ranges, not just begin-end pairs. best regards, Richard Peters

6 19

Re: MPL compilation speed trade-offs...
by Jaap Suter 16 Nov '04

16 Nov '04

> My advice: use the MPL constructs and optimize later. When > you're done you can measure the compilation speed difference > when using mpl::plus, minus and divides vs. the ugly version at > the bottom. I bet you dollars to donuts that it's not a significant > hit. But if it is, you can make some informed choices. Believe me, I'm better known for premature pessimization then premature optimization. It's no longer a matter of compilation times (I can live with that), but a matter of the compiler no longer being able to handle it (running out of memory, out of keys, etcetera). I've tried many other things first (/Zm, splitting up source files, etcetera), but I'm beginning to believe that meta-C++ is just not quite ready for the algorithmic complexity of some of my meta-code. I've started reaching for the preprocessor a lot lately, and I'm now writing a blend of template code and preprocessor code that is quite elegant, albeit completely unreadable ;). It does compile a lot faster fortunately. Thanks, Jaap Suter

1 0

[MPL] Wiki docs
by David B. Held 16 Nov '04

16 Nov '04

Here: http://www.mywikinet.com/mpl/mpl_1_32_changelog/numeric-metafunctions-proto… I'm guessing that: template< int n > struct my_int { static int const value = n; typedef my_iny type; }; is really supposed to be: template< int n > struct my_int { static int const value = n; typedef my_int type; ^^^^^^ }; And same for the "After" example. Dave

2 1

Member function detection: VC7.1 workaround needed
by Jonathan Turkanis 16 Nov '04

16 Nov '04

Hi All, I'm writing a macro-based interface definition language, which I hope to post soon. For this, I need to be able to detect the presence of member functions with given name and signature. My current formulation generates code like the following to test whether a class has a non-const member function named 'one' with the signature char(int, float): template<typename T> struct has_member_function_one { template<typename U, char (U::*MemFun)(int, float)> struct one_holder { }; static ::boost::type_traits::no_type one_tester(...); template<typename U> static ::boost::type_traits::yes_type one_tester ( ::boost::mpl::identity<U>*, one_holder<U, &U::one>* = 0 ); static const bool value = sizeof(one_tester((::boost::mpl::identity<T>*)0)) == sizeof(::boost::type_traits::yes_type); typedef ::boost::mpl::bool_<value> type; }; This works fine on Comeau 4.3.3, Intel 8.0 for Windows, GCC 3.4.1 and VC8.0 (beta). But on VC7.1, it works only if the member function 'one' is not overloaded. I've tried Terje Slettebø's operator_concept_traits library, some code posted long ago by Brock Peabody, but they all use the same technique and fail on VC7.1. Does anyone have a workaround? Best Regards, Jonathan

3 7

Two points about the Named parameters library
by Joaquín Mª López Muñoz 16 Nov '04

16 Nov '04

Hello, This is not a review of the Named params library. I'd just want to make the following two points about it: 1. Some have considered this library as a means to gain experience about named parameters interfaces for possible inclusion into the standard as a built-in facility. I think this won't happen, since this issue has already been discussed (and rejected) prior to C++98. The library does not raise (AFAIK) any new issue about the suitability of such interfaces, so why should the comittee change their minds. So, we'd better consider named_params as a utility on its own, without hoping for future built-in support. 2. I think the docs miss an important point. Consider a final user exposed to a named_params-powered interface. Of course this user is not concerned about the implementation of the interface, or about the named_params lib, for that matter. Instead, she should be presented the interface as if named params were a built-in facility. A possibility: void foo(int :x:=0,int :y:=0,std::string :msg:="") foo does so and so... :x:,:y: and :msg: are named params that the user can resort to in order to subvert the traditional argument-by-position invokation interface. For instace: foo(msg="hello"); I don't claim this particular documentation example is any good (in fact, I found it rather bad), but I hope you get the idea. named_params docs are the perfect place to propose and "standardize" a general syntax and wording to document named parameter interfaces for the final user. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

MPL compilation speed trade-offs...
by Jaap Suter 16 Nov '04

16 Nov '04

Hello, can any compiler expert give me feedback on whether there should be a noticable difference in compilation speed between the following two meta-functions: template<class N, class M, class Q, class P> struct foo : mpl::plus < N, typename mpl::minus < M, typename mpl::divides < Q, P >::type >::type >::type {}; and template<int N, int M, int P, int Q> struct foo { enum { value = N + (M - (Q/P)) }; typedef boost::mpl::int<value> type; } The second version saves me a lot of template instantiations and many header inclusions, at the cost of losing some genericity. On the other hand, if the calculation becomes complicated, I find myself using many enums to hold intermediate values, resulting in code like the following: template<class T> struct next_number_with_same_num_bits { enum { lowest_bit_set = T::value & (-T::value), lowest_bit_set_index = count_leading_zeroes<T>::type::value, next_t = T::value + lowest_bit_set, next_lowest_set_bit = next_t & (-next_t), mask = next_lowest_set_bit - lowest_bit_set, result_t = next_t | (mask >> (lowest_bit_set_index + 1)) }; typedef boost::mpl::int_<result_t> type; }; which leads MSVC to run out of so-called compiler-keys much quicker than if I reduce the above to the completely unreadable: template<class T> struct next_number_with_same_num_bits { enum { result_t = (T::value + (T::value & (-T::value))) | ((((T::value + (T::value & (-T::value))) & (-T::value - (T::value & (-T::value)))) - (T::value & (-T::value))) >> (count_leading_zeroes<T>::type::value + 1)) }; typedef boost::mpl::int_<result_t> type; }; Does anybody have any thoughts or comments on this technique, and is anybody else using tricks around MPL to make sure your compiler still handles things? Thanks, Jaap Suter

2 1

performance using accumulate, bind, and make_transform_iterator
by Richard Newman 16 Nov '04

16 Nov '04

I'm a newbie to the list; if an answer to my question is in a FAQ I'm not aware of, please let me know; but I've googled the documentation and don't see it. In fact, I see little regarding performance factors to consider when using boost, so I may not be looking in the right places. We're running a performance-sensitive application and so I've begun to find points to optimize the code. The following is a digest of our experience bringing boost functionality into this effort (forgive the generic code; it was sanitized for intellectual property perservation, etc.): I am posting this experience in hopes that someone can confirm our reasoning and perhaps point us in the right direction for information, etc., for thinking through these kind of issues in the future. Any advice is appreciated. You'll see that, in part, my woes came from violating the cardinal rule of only optimizing that code which is most expensive; nonetheless, this specific instance is an involved enough example that I thought it worth pursuing... ============== During the writing of an interface, a function was added to a templated class, that has-a stl vector, to sum SomeValue of its contained elements: const unsigned allElementsValue() const { unsigned result = 0; std::vector<T>::const_iterator thisElement(sequence_.begin()); const std::vector<T>::const_iterator endElement (sequence_.end()); while (thisElement != endElement) { result += thisElement->getSomeValue(); } } At the time this interface was being written, it was a departure from an prior approach and so it was important that performance was not significantly affected. During this effort, we used KCachegrind and found out that this call was (relatively) more expensive than hoped. Since std::accumulate was supposed to be a quicker way to walk through elements, that approach was tried and the following function resulted: const unsigned allElementsValue() const { unsigned result = 0; return std::accumulate ( boost::make_transform_iterator (sequence_.begin(), boost::mem_fn(&T::getSomeValue) ), boost::make_transform_iterator (sequence_.end(), boost::mem_fn(&T::getSomeValue) ), 0 ); } We now note the use of make_transform_iterator and the use of a 0-ary member function of the constituent element objects. This code is semantically equivalent and yet yielded an relatively significant performance improvement. The performance increase can be taken in part to considering that STL and boost use templates and so some of what why otherwise have to be done at run-time can now be done at compile-time. So we naively took the moral of the story to be that std::accumulate is Good and walking through elements manually with a loop is Bad. The following code was later examined. Note that this particular code happens to be executed many, many times in our run. So any performance change to this code will have a major effect to the overall performance of the program. Certainly a ripe and ready candidate for applying this new conclusion. The code was changed from this... ----------- // Note that a and b (referred to in calcSomeValue below) are // references to other objects passed into the function that // has this code float result = 0.0; // SomeObjectPtrCont is a typedef for a stl vector that contains // boost::shared_ptrs managing pointers to SomeObject. // SomeObjectPtrs_ is an instance of SomeObjectPtrCont SomeObjectPtrCont::const_iterator thisIter(SomeObjectPtrs_.begin()); const SomeObjectPtrCont::const_iterator endIter (SomeObjectPtrs_.end()); while (thisIter != endIter) { result += (*thisIter)->calcSomeValue(a, b); ++thisIter; } ----------- ...to this: ----------- // Note that a and b (referred to in calcSomeValue below) are // references to other objects passed into the function that // has this code float result = 0.0; // Use a typedef so that we can handle overloading of calcSomeValue typedef float (SomeObject::* calcFunct)(const T&, const OtherObjB&) const; // Use stl accumulate to do same thing as the while loop result = std::accumulate ( boost::make_transform_iterator ( SomeObjectPtrs_.begin(), boost::bind(static_cast<calcFunct>(&SomeObject::calcSomeValue), _1, a, b) ), boost::make_transform_iterator ( SomeObjectPtrs_.end(), boost::bind(static_cast<evalFunct>(&SomeObject::calcSomeValue), _1, a, b) ), float(0.0) ); ----------- Note that this is a significantly more sophisticated use of std::accumulate with boost::make_transform_iterator and boost::bind. Indeed, now bind must take an argument, marked by the _1, to link the function being called, evaluate, with each element in the collection being walked through. The evaluate() function itself is binary and not a member of the constituent elements. Nonetheless, it is semantically equivalent to the more conventional while loop form. Remembering our earlier simplistic conclusion that std::accumulate is Good and that while-loops are Bad, this change was made, checked in, and pride swelled within the author (silly me) for so cleverly using boost, et al. The expectation at the time was that since templates would be involved more, then much of the logic would be resolved at compile-time rather than run-time giving us a performance increase just like with the simpler accumulation approach (basically since one form of accumulation is good, than all are better). We discovered that the revised code now ran 4 times SLOWER. KCachegrind showed the problem was the above code. So what the *&^% gives? Rather than analyze the situation, it's always better to tinker :), so the next attempt involved an approach that std::accumulate also allows: ----------- // Note that a and b (referred to in calcSomeValue below) are // references to other objects passed into the function that // has this code float result = 0.0; // Use a typedef so that we can handle overloading of calcSomeValue typedef float (SomeObject::* calcFunct)(const T&, const OtherObjB&) const; // Alternate accumulation approach result = std::accumulate ( SomeObjectPtrs_.begin(), SomeObjectPtrs_.end(), float(0.0), boost::bind (std::plus<float>(), _1, boost::bind(static_cast<calcFunct>(&SomeObject:calcSomeValue), _2, a, b) ) ); ----------- This sped up the code but now it was measured to be 3 times slower than the original form, though now not 4 times as slow. Hardly a ringing endorsement for the use of std::accumulate. Our best conclusion so far is that involving boost::bind in this kind of operation causes accumulate to go through additional function redirection at run-time to access the final evaluate() function desired. This more than offsets any potential gain that might have been realized by the std::accumulate because now its use of templated compilation is thwarted by all of this run-time redirection. Note that because of the arguments involved, the compiled code under boost::bind must now move variables onto the stack so that when the underlying accumulate calls this implicit functor, those values are part of its state. All of this is now done at run-time where as before, without having to move such variables, it was really just a change of a function pointer's value. So, the new current thinking is that std::accumulate is Better than simple while-loops that walk through elements which is still Bad. However, boost::bind under std::accumulate is Worse. At this point, the best advice is that one should use std::accumulate whenever simple accumulations are needed. However, once one has to start involving boost::bind on 1+-ary functions or anything else that requires new run-time function redirection, then retreating back to while-loop is a better performance solution. Thank you all for reading this far... Kind regards, Richard Newman Crowley Davis Research richard(a)nospam.cdres.com (take out the nospam. to email me directly)

4 8

1_32_0 final test python issue
by Russ Gibson 16 Nov '04

16 Nov '04

The latest 1_32_0 (downloaded today - 2004-11-15 at around 13:30 PST/-0800) failed to build the python libs because of "python22.lib" references in a link. I have python 2.3 installed, and have the python environment variables set like this: PYTHON_ROOT=C:\python23 PYTHIN_VERSION=2.3 PYTHON_LIB_PATH=C:\Python23\libs My WinXP system is brand newly set up (from major crash), so there aren't any strange things going on (i.e. no other python's in path, etc.). I have cygwin installed, but none of the cygwin stuff is in my path (or any other environment variables for that matter), so I'm confident that isn't a problem. Besides, it also has python 2.3, not 2.2. I actually used vsvars32.bat to get the build environment for boost. Everything else (that wasn't dependant on boost python) build fine. Anybody know anything about this? (Be sure to reply-all if you reply to this, unless you don't mind long delays for a response). --> Russ

2 1

Ideas for logging/tracing
by Alexander Nasonov 15 Nov '04

15 Nov '04

I have a couple of ideas about making function traces nicer: 1. Use of PP_SEQ interface to "parse" function name and arguments int X::foo(char* buf, size_t len) { BOOST_TRACE_MEM_FUN( (foo)(buf, len) ); // ... } Function name can be extracted with BOOST_PP_SEQ_ELEM(0, fn), the arguments with BOOST_PP_SEQ_POP_FRONT(fn). BOOST_TRACE_MEM_FUN macro could expand to: tracer tracer_line_N(this, "foo", "(buf, len)", resolve_args (buf, len)); 2. In addition to text format, produce XML output. This opens up a possibility for XSLT convertion to UML sequence and collaboration diagrams (XMI). -- Alexander Nasonov

4 15

[iterator] Why no assignment operator for filter_iterator?
by David M. Jones 15 Nov '04

15 Nov '04

Is there a reason why filter_iterator has no assignment operator? I have a place in my code where I want to perform an assignment of filter_iterators. Can anyone suggest a work-around? Thanks in advance, David Jones

2 2