March 2011 - Boost - lists.preview.boost.org

Re: [boost] Spinal Tap (WAS: Religious sensibility (WAS: RE: [XInt] CoW/Move Timings))
by Troy Straszheim 14 Mar '11

14 Mar '11

On Mon, Mar 14, 2011 at 9:53 AM, Mika Heiskanen <mika.heiskanen(a)fmi.fi> wrote: > > Once I started reading the list of like-minded bands, I kind of expected > to see Spinal Tap in there. > That works remarkably well in the subject line...

1 0

[config] Unable to locate boost main tree
by Belcourt, Kenneth 14 Mar '11

14 Mar '11

Hi John, I have an up to date copy of boost trunk on a new machine (u233) running RHEL 6.0 kernel (Santiago). You can see the results on the trunk page under Ornl-intel-11.1.064. For some reason the configure script is having trouble locating the boost main tree. I tried adding --with-boost=... to no avail. Is this a recent problem or perhaps this is the first attempt under 6.0? Any ideas? -- Noel [bkn@u233 config]$ ./configure *** ./configure: boost configuration utility *** Please stand by while exploring compiler capabilities... Be patient - this could take some time... Note that this test script only gives an approximate configuration - you will need to test the results carefully using the boost regression test suite before using the results. *** Info : .cpp used as extension for tests checking for boost main tree... not found configure: error: The boost main tree was not found. Specify its location by the --with-boost option.

3 8

[design] policy based. Was: [XInt] Review
by Joachim Faulhaber 14 Mar '11

14 Mar '11

2011/3/10 Chad Nelson <chad.thecomfychair(a)gmail.com>: > On Wed, 9 Mar 2011 19:11:31 +0100 > Joachim Faulhaber <afojgo(a)googlemail.com> wrote: > >> This is my review on the XInt library. [...] > > Thank you for the review, and the comments. Thank you for your replies and questions [...] >> 2.3 Policy based design >> ======================= >> >> I think policy based design is a very good and powerful technique that >> is specifically useful to separate implementation variants of class >> templates in clear and flexible ways. Unfortunately I can not see that >> you are actually using policy based design here. Because your design >> lacks typical policy classes that encapsulate implementation variants >> in a way that reduces codereplication and enhances flexibility. [...] > > As I'm not sure what kind of implementation you're thinking of, I can't > respond to this. So far as I can tell, my design is doing what you > describe for policy-based design. > >> There is a great deal of code replication in the current >> implementation of xint::integer_t. [...] This skeleton (and some >> variations of it) occurs over and over again only to propagate the >> call of the function to the implementing class at positions #1 and #2. > > integer_t handles some options, and passes the data to the implementing > class for others. It was the best solution I could find to handle all > options. Trying to be consistent with my own request ... >> "At the same time I'd like to call on the boost community to support >> Chad and to see an Integer library as an opportunity to develop more >> common understanding how a state of the art generic design looks like >> in this specific case." ... I invested some work to make my suggestion about good design more concrete. I will give you a small example of a policy based design that is directly related to some problems of code replication and insufficient separation of concerns in your library. At the same time I hope it'll help to understand policy based design, which includes getting a better understanding for myself. The only source of PDB that I've been using so far is Andrei's book from 2001. [Andrei Alexandrescu 2001, Moden C++ Design] But I found the page on wikipedia informative as well. http://en.wikipedia.org/wiki/Policy-based_design Maybe others can contribute more good sources, I did not research. Andrei's book has been really enlightening for me. I've never read a book about programming with so much delight. I can highly recommend it. As for the example. I picked one aspect of your design, the option for nothrow, that controls the handling of nan. Here I've criticized code replication in your code like if (Nothrow) {if (b.is_nan()) ... if (!is_nan()) { ... }} else {...} that reoccurs a lot in the implementation of integer_t. Using policy based design, we try to encapsulate all aspects of the code that relates to the handling of nans in a policy class. So we try to separate the concern "handling nan" from other parts of a class. In this case aint (not xint ;) //========================================================= // Using policies, we want to handle nan in a "nany" or // a "manly" way (manly: ignore it all together) struct nany; // Takes care for the nasty nan struct manly; // No, we don't want this template<class, class> class aint; // a int with nan policy // Meta function for naniness. template<class Type> struct is_nany { static const bool value = false; }; template<class Rep> // a int with nany policy is_nany struct is_nany<aint<Rep, nany> > { static const bool value = true; }; template<class Type> bool is_nan(Type const& value) { // Not perfect ... ok. for the example return value ==( numeric_limits<Type>::has_quiet_NaN ? (numeric_limits<Type>::quiet_NaN)() : (numeric_limits<Type>::max)() ); } // An int class with NaNPolicy: Rep is supposed to be some // integer implementation, including limitless integers // NaNPolicy encapsulates nan-handling. template<class Rep, class NaNPolicy = manly> class aint // no sunshine when she's gone { public: aint(): _value(){} aint(Rep const& val): _value(val){} aint& operator += (aint const& y) { NaNPolicy::plus_assign(_value, y._value); return *this; } Rep value(){ return _value; } private: Rep _value; }; // Finally two different NaN-policy classes struct nany { template<class Rep> inline static void plus_assign(Rep& x, Rep const& y) { if (is_nan(x)) ; else if(is_nan(y)) x = y; else x += y; } }; struct manly { template<class Rep> inline static void plus_assign(Rep& x, Rep const& y) { x += y; } }; BOOST_AUTO_TEST_CASE(nan_policy_study) { // No NaN protection aint<long> ago; // A no throw int with NaN protection aint<short, nany> sun(2); aint<short, nany> shine(7); sun += shine; cout << sun.value() << endl; // I is generic because it is suitable for all kinds of // integer types Rep including say xint::integer_t types aint<xint::integer, nany> ax_i; } //========================================================= 1. Encapsulation: The code necessary for the handling of nans is either encapsulated in the policy class, or it uses some meta code that is globally available. 2. Non intrusive: This code does not require changes in the class Rep, that implements the basic semantics. 3. Generic: So, apart from very little code around the existence and test of the NaN-element, the policy based design works for all integer implementations Rep that are model of a common integer concept, which is implicitly given in this case. 4. Abstraction: Moreover separation of concerns leads to abstraction here. We discover that this kind of "nan closure" not only works for integers but also for floting point numbers or continuous numbers like e.g. boost::rational. Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

3 5

[parameter] Compile-time performance
by Domagoj Saric 14 Mar '11

14 Mar '11

I have an in-house framework a part of which is very similar to Boost.Parameter so I tried to refactor it to use Boost.Parameter and, unfortunately, noticed a big compile-time hit (the project has a very large number instantiations of class templates with 'named non-type template parameters'). With my code (and MSVC++ 10) build time was ~56 seconds with a maximum cl.exe memory allocation size of ~720 MB. After switching to Boost.Parameter build time whent to ~2:24 seconds with a maximum cl.exe memory allocation size of ~815 MB. The most likely suspect is the usage of a forward-sequence for parameter type storage (argument packs) from which you fetch passed parameters using key-based lookup with the value_type<> metafunction. In my code I use an associative container (mpl::map) for the task which has a 'natural'/'efficient' key-based lookup... To confirm this I minimally changed the Boost.Parameter-based version of my code only to use mpl::maps instead of Boost.Parameter ArgumentPacks and built time fell to ~58 seconds...(true, this does not have all the compile-time check for correct usage and concept validation that ParameterSpecs and ArgumentPacks have but I'd expect this to have a much smaller effect than key-based lookup on a forward sequence)... Is there an inherent issue that forbids the use of an associative container for ArgumentPacks or can this be fixed? -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

3 6

xint review is closed
by Vladimir Prus 14 Mar '11

14 Mar '11

Boosters, the formal review of XInt library is now officially closed. Thanks for everybody for comments. Of course, it's fine to let ongoing discussion lead to conclusion, and I'll be watching those discussions. The review was relatively heated, and many experienced folks expressed radically different opinions. Therefore, coming up with yes/no result is not easy, and won't happen overnight. Instead, I plan to summarize on the issues raised by March 21, Monday to see whether we all are on the same page at least about issues, and then come up with final review result by March 28. Thanks, Volodya

2 1

[python] extracting a string and a one-length list containing a string
by Allan Johns 13 Mar '11

13 Mar '11

Hello, Given a boost::python object, how can I the difference between that object containing a string, or a sequence of length 1 whos zeroeth element is a string? Ie: "foo" --vs-- ["foo"] bp::extract<std::string> succeeds in both cases. I can use PySequence_Check to test for a sequence, and then I can test the length of the zeroeth element - if >1 then it's ["foo"] - but then I still can't disambiguate ["X"]. tia! Allan

2 2

[range] Should the result of irange satisfy the BidirectionalRangeConcept?
by Vicente Botet 13 Mar '11

13 Mar '11

Hi, I'm trying to define an enum_range and I based my implementation on the one from irange. While writing my test I started just by checking that my enum_range satisfied the RandomAccessRangeConcept requirements and there were some errors with BidirectionalRangeConcept. I replaced by the result type of the irange function and the errors appear also there. It seems that there is an issue concerning the category tags ..\..\../boost/concept_check.hpp:212:13: error: conversion from 'boost::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::random_access_traversal_tag>' to non-scalar type 'std::bidirectional_iterator_tag' requested Am I missing something? Best, Vicente == Test == #include <boost/range/concepts.hpp> #include <boost/range/irange.hpp> using namespace boost; BOOST_CONCEPT_ASSERT(( BidirectionalRangeConcept < iterator_range< range_detail::integer_iterator > > )); == Result == gcc.compile.c++ ..\..\..\bin.v2\libs\enums\test\enum_range__random_access_range_concept__pass.test\gcc-mingw-4.5.0\debug\enum_range\random_access_range_concept.pass.o In file included from ..\..\../boost/range/concepts.hpp:19:0, from ..\..\../boost/range/algorithm/equal.hpp:14, from ..\..\../boost/range/iterator_range_core.hpp:29, from ..\..\../boost/range/iterator_range.hpp:13, from ..\..\../boost/enums/enum_range.hpp:24, from enum_range\random_access_range_concept.pass.cpp:15: ..\..\../boost/concept_check.hpp: In destructor 'boost::Convertible<X, Y>::~Convertible() [with X = boost::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::random_access_traversal_tag>, Y = std::bidirectional_iterator_tag]': ..\..\../boost/concept/detail/general.hpp:38:28: instantiated from 'static void boost::concepts::requirement<boost::concepts::failed************ Model::************>::failed() [with Model = boost::Convertible<boost::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::random_access_traversal_tag>, std::bidirectional_iterator_tag>]' ..\..\../boost/concept_check.hpp:579:1: instantiated from 'boost::BidirectionalIterator::~BidirectionalIterator() [with TT = boost::range_detail::integer_iterator]' ..\..\../boost/concept_check.hpp:571:1: instantiated from 'static void boost::concepts::requirement<boost::concepts::failed************ Model::************>::failed() [with Model = boost::BidirectionalIteratorConcept<boost::range_detail::integer_iterator<int> >]' ..\..\../boost/range/concepts.hpp:333:1: instantiated from 'boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > >' ..\..\../boost/concept/detail/has_constraints.hpp:42:5: instantiated from 'const bool boost::concepts::not_satisfied<boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > > >::value' ..\..\../boost/concept/detail/has_constraints.hpp:45:31: instantiated from 'boost::concepts::not_satisfied<boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > > >' ..\..\../boost/mpl/if.hpp:67:11: instantiated from 'boost::mpl::if_<boost::concepts::not_satisfied<boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > > >, boost::concepts::constraint<boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > > >, boost::concepts::requirement<boost::concepts::failed************ boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > >::************> >' ..\..\../boost/concept/detail/general.hpp:56:1: instantiated from 'boost::concepts::requirement_ > >)>' enum_range\random_access_range_concept.pass.cpp:27:3: instantiated from here ..\..\../boost/concept_check.hpp:212:13: error: conversion from 'boost::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::random_access_traversal_tag>' to non-scalar type 'std::bidirectional_iterator_tag' requested ..\..\../boost/concept_check.hpp: In destructor 'boost::Convertible<X, Y>::~Convertible() [with X = boost::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::random_access_traversal_tag>, Y = std::forward_iterator_tag]': ..\..\../boost/concept/detail/general.hpp:38:28: instantiated from 'static void boost::concepts::requirement<boost::concepts::failed************ Model::************>::failed() [with Model = boost::Convertible<boost::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::random_access_traversal_tag>, std::forward_iterator_tag>]' ..\..\../boost/concept_check.hpp:551:1: instantiated from 'boost::ForwardIterator::~ForwardIterator() [with TT = boost::range_detail::integer_iterator]' ..\..\../boost/concept/usage.hpp:22:29: instantiated from 'boost::concepts::usage_requirements::~usage_requirements() [with Model = boost::ForwardIterator<boost::range_detail::integer_iterator<int> >]' ..\..\../boost/concept/detail/general.hpp:38:28: instantiated from 'static void boost::concepts::requirement<boost::concepts::failed************ Model::************>::failed() [with Model = boost::concepts::usage_requirements<boost::ForwardIterator<boost::range_detail::integer_iterator<int> > >]' ..\..\../boost/concept_check.hpp:546:1: instantiated from 'boost::ForwardIterator<boost::range_detail::integer_iterator<int> >' ..\..\../boost/concept_check.hpp:573:3: [ skipping 6 instantiation contexts ] ..\..\../boost/range/concepts.hpp:333:1: instantiated from 'boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > >' ..\..\../boost/concept/detail/has_constraints.hpp:42:5: instantiated from 'const bool boost::concepts::not_satisfied<boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > > >::value' ..\..\../boost/concept/detail/has_constraints.hpp:45:31: instantiated from 'boost::concepts::not_satisfied<boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > > >' ..\..\../boost/mpl/if.hpp:67:11: instantiated from 'boost::mpl::if_<boost::concepts::not_satisfied<boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > > >, boost::concepts::constraint<boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > > >, boost::concepts::requirement<boost::concepts::failed************ boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > >::************> >' ..\..\../boost/concept/detail/general.hpp:56:1: instantiated from 'boost::concepts::requirement_ > >)>' enum_range\random_access_range_concept.pass.cpp:27:3: instantiated from here ..\..\../boost/concept_check.hpp:212:13: error: conversion from 'boost::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::random_access_traversal_tag>' to non-scalar type 'std::forward_iterator_tag' requested -- View this message in context: http://boost.2283326.n4.nabble.com/range-Should-the-result-of-irange-satisf… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[range] compile error with extra ; with some compilers and options
by Vicente Botet 13 Mar '11

13 Mar '11

Hi, The extra ";" in has_range_iterator.hpp results in a compiler error on some compilers with -pedantic option. Could this patch be applied on trunk? Thanks, Vicente Index: has_range_iterator.hpp =================================================================== --- has_range_iterator.hpp (revision 69537) +++ has_range_iterator.hpp (working copy) @@ -19,7 +19,7 @@ { namespace range_detail { - BOOST_MPL_HAS_XXX_TRAIT_DEF(type); + BOOST_MPL_HAS_XXX_TRAIT_DEF(type) template struct has_range_iterator_impl -- View this message in context: http://boost.2283326.n4.nabble.com/range-compile-error-with-extra-with-some… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[Track] What's up with track
by Robert Ramey 13 Mar '11

13 Mar '11

I log into track system with my name (ramey). The I select issues and select "my Issues". It seems that now the list includes all the issues previously closed so the count is 254 going back to 2004. The actual number should be on the order of 15. Can someone fix this or tell me what to do differently? Robert Ramey

2 1

boost::mpi::scatterv and boost::mpi::gatherv fixed versions
by Júlio Hoffimann 13 Mar '11

13 Mar '11

Hi, I did some changes in attachments. (ticket #5292) Regards, Júlio.

1 0