- Boost - lists.boost.org

[numeric][ublas] please add vector constructor from boost::range
by Jochen Wilhelmy 20 Jul '12

20 Jul '12

Hi! is it possible to add a constructor for ublas::vector from boost::range? this would it make easier to construct from pain data (e.g. float*). something like boost::numeric::ublas::vector<float> v(boost::iterator_range<const float*>(myDataBegin, myDataEnd)); -Jochen

4 3

[optional] reduce need for operator ==
by Jochen Wilhelmy 20 Jul '12

20 Jul '12

Hi! currently boost::optional<Type> requires an operator == for Type. If I only want to check if the optional is present or not, then this is not necessary. e.g. struct Foo {int i;}; boost::optional<Foo> foo; if (foo == boost::none) ... is it possible to change this? for example by template<class T> inline bool operator == ( optional<T> const& x, none_t ) { return !x; } -Jochen

3 2

[TypeErasure] Composing Concepts & some notes
by Fabio Fracassi 20 Jul '12

20 Jul '12

Hi Steven, I am going through the documentation and simultaneously try out some things that weren't immediately obvious to me. When I came to the paragraph about composing concepts the last sentence "We can even specialize concept_interface for it." tripped me up. My thought was "but do I have to? and how do composed concepts interact with manually composed any's?" so I gave it a try: I used your push_back concept and defined a size concept like this: template<class C> struct size { static size_t apply(C& cont) { return cont.size(); } }; namespace boost { namespace type_erasure { template<class C, class Base> struct concept_interface< ::size<C>, Base, C> : Base { size_t size() { return call(::size<C>(), *this); } }; } } which works fine: std::vector<int> vec; typedef any<push_back<_self, int>, _self&> any_push_back; any_push_back pb(vec); pb.push_back(10); pb.push_back(2); typedef any<size<_self>, _self&> any_size; any_size s(vec); std::cout << "Size = " << s.size() << std::endl; Now I wanted to try composition first manually: typedef any< mpl::vector< push_back<_self, int>, size<_self> >, _self& > any_manual_vecconcept; any_manual_vecconcept alvec(vec); alvec.push_back(13); alvec.push_back(11); std::cout << "Size = " << alvec.size() << std::endl; and then via "named composition": template<class T, class C> struct vecconcept : mpl::vector< push_back<T, C>, size<T> > {}; typedef any<vecconcept<_self, int>, _self&> any_vecconcept; any_vecconcept acvec(vec); acvec.push_back(15); acvec.push_back(17); std::cout << "Size = " << acvec.size() << std::endl; great everything works as expected, and no, I did not have to define a concept_interface for the composite interface. Now the first question is why would I want to? now the main reason for the exercise was how do these interact with each other and while I am at it how do they interact with the concepts they are composed of? Well I can freely interact as I hoped: any_vecconcept acvec2(alvec); any_manual_vecconcept alvec2(acvec); any_push_back pb3(alvec); any_push_back pb4(acvec); any_size s2(alvec); any_size s3(acvec); This is great! I might have missed it in the documentation, but I think this is really an important feature that deserves special mention. Now I gather that there is no way to do the opposite, something along the lines of any_vecconcept acvec3 = dynamic_any_cast<any_vecconcept>(s3); Well over the next days I will dive a bit deeper into the internals to see if implementing such a feature would be feasible. (because I need it before I could replace my current solution with type erasure) Steven, let me finish by saying thank you for the great work. regards Fabio

2 2

[pool] Calling all library designers: The future of Boost.Pool???
by John Maddock 19 Jul '12

19 Jul '12

As one of the last people to try and do any maintenance of Boost.Pool I feel I should try and start some discussion here on it's future. First off some random thoughts based on my last experiences with this library: * It should be simple, but it's confusing. In particular the difference between ordered and unordered pools is not particularly intuitive, but IMO the distinction between the various components, and what should be used where is also poor. * I believe the decision to support both ordered and unordered pools in the same interface was a mistake. At the very least it's potentially error prone in use, but it's also inefficient. It looks to me that this, along with the allocators provided, were a classic case of feature creep post-review. I'm sure they sounded like good ideas during the review, but in practice a smaller more tightly focused library might actually be better. * It's not clear that the claimed performance improvements are actually there in practice (any more). This is partly due to compiler and std lib improvements, partly due to feature creep in Boost.Pool. Some bug fixes have had a negative effect too - however needed they may have been for correctness. * Many of the existing bug reports were deliberately left "in limbo" because there was no obvious/easy way to fix them without compromising Boost.Pool's core mission (providing fixed size blocks of memory really fast). * There have been many changes to the standard, compiler technology, and to Boost's best practices since the library was designed, many of which would result in a different design today, but also different requirements today (per instance allocators in containers for example). * In no way do I want to be lumbered with maintaining Boost.Pool and in any case I don't believe it's really fit for purpose any more [1]. So..... in an ideal world, I'd like someone to step up to the plate and design it's replacement.... yes a whole new Pool2. Off the top of my head, here's my wish list: * There should be a very small, very focused (i.e. fast) core that provides fixed sized blocks of memory. Nothing more. * Thread synchronization when needed (template param?) should be via lockfree programming wherever possible. Indeed a simple pool like this, is pretty much the poster child for lock-free-programming. And of course we have Boost.Lockfree now. * There should probably be a heap implementation for variable sized allocation requests. I'm assuming that this can't be done lockfree(?). * Allocators: both singleton and stateful allocators should be provided (templated on pool type?). But there's a trick here: many containers only allocate fixed size blocks, but we have no way of knowing what that size is upfront at compile time. Connecting the allocation request to the correct pool interface in an efficient manner is pretty tricky here, especially if 99% of allocations are of fixed sized, but there are a few odd-sized control blocks also allocated. In any case, all allocations should come from the same underlying block of memory, even if they're for different types/sizes. * Both pools and allocators, should be able to accept a single fixed sized block of memory (from wherever) and divide it up to clients. A good example for this use case is an arena-allocator: a stateful allocator whose memory all comes from the stack, no thread synchronization required. Containers using such types can be blisteringly fast compared to regular allocators, particularly when using a scoped container for just a few manipulations. Ideal for use with C++11 containers or Boost.Container. Hopefully others will chime in here with their requirements as well. Cheers all, John. 1) This doesn't preclude applying *trivial* fixes to Boost.Pool, but I genuinely believe that big changes are more likely to be counterproductive at this point.

11 19

[website] Build & link field in library list
by Daniel James 19 Jul '12

19 Jul '12

Hi, In the library list (http://www.boost.org/doc/libs/) I don't think the 'build & link' field is very accurate. There's a recent bug report about pool, which apparently isn't header only. I suspect it's wrong for some other libraries as well, and for some libraries the situation is a bit more complicated. So, I'm thinking about removing it. Incorrect and misleading information can be worse than no information at all. Does anyone have an attachment to it? Daniel

1 0

[TypeErasure] assignment operator of any references
by Vicente J. Botet Escriba 19 Jul '12

19 Jul '12

Hi, The References section constains this example: int i, j; any<typeid_<>, _self&> x(i), y(j); x = y; // error The following basic c++ code int i=1, j=0; int& x(i); int& y(j); x = y; // [1] works and the expected value of x after [1] is 0. Which concept requirements should I add to make the following work? assignable? int i, j; any<mpl::vector<typeid_<>, ...>, _self&> x(i), y(j); x = y; // no error Best, Vicente

2 3

How to find all paths with a length in a certain range
by J Birch 18 Jul '12

18 Jul '12

I am fairly new to Boost, and not the greatest at C++, but I do have a bit of experience in dealing with graphs in other languages. We currently have some very ugly and inefficient code that effectively builds up a graph structure (DAG), and must calculate all paths with a length between a certain range, say 3-7. I have seen the question asked a few times via Google, but I have seen no solution. I have been tinkering around with different examples, but have yet to come up with anything useful. Would anyone be able to point me in the right direction? Thanks! Birch

3 3

Merging to release
by Marshall Clow 18 Jul '12

18 Jul '12

The deadline for bug fixes for 1.51 is tomorrow; and I'd like to merge the changes I made to the following libraries to release: * Config - reorganized the c++11 macros * Unordered - changed #ifdefs to use non-deprecated macros * functional/hash - changed #ifdefs to use non-deprecated macros * Random - changed #ifdefs to use non-deprecated macros * Regex - changed #ifdefs to use non-deprecated macros * Math - changed #ifdefs to use non-deprecated macros I've been watching the test results; and it turns out I broke two of the C++11 tests, which only affects people running the tests on C++11 compilers. I fixed those this morning. Any objections? -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

9 11

Re: [boost] Boost.config limits_test testcase and qnan checks
by Matthew Markland 18 Jul '12

18 Jul '12

Extra text elided below: > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost- > bounces(a)lists.boost.org] On Behalf Of boost-request(a)lists.boost.org > Sent: Friday, July 13, 2012 10:51 PM > To: boost(a)lists.boost.org > Subject: Boost Digest, Vol 3701, Issue 4 >----- <elided> > Message: 5 > Date: Fri, 13 Jul 2012 18:07:45 +0000 > From: Thomas Klimpel <Thomas.Klimpel(a)synopsys.com> > To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> > Subject: Re: [boost] Boost.config limits_test testcase and qnan > checks. > Message-ID: > <4468C9C2AE594745A32DC93C799A224A01D0FB(a)DE02WEMBX2.inte > rnal.synopsys.com> > > Content-Type: text/plain; charset="us-ascii" > <elided> MARKLAND> My question is whether it is valid to test the qnan behavior when a MARKLAND> platform MARKLAND> > does not claim compliance? > > I wonder how you measure "claim compliance"? I once had a long debug > session with gcc-4.5.2 before I found out that the builtin "is_nan" was > returning wrong results. Isn't compiling the code that uses "is_nan" without > warning also some sort of "compliance claim"? I know you are probably > referring to "numeric_limits<double>::is_iec559", but on which floating point > functionality can I still rely as a programmer if (is_iec559 == false)? > > Regards, > Thomas I've now been trying to come up with a good answer to this for days and have yet to get there. So I'm going to just comment and see if the discussion continues. These are my interpretations and should not be construed as the opinion of my employer. In the case of this particular test, from a language perspective, I think the check for is_iec559 makes sense. The part of the test in question is testing a behavior that is only defined for certain if the platform is using an IEEE compliant implementation. Now this doesn't mean that it won't work for a platform that sets is_iec559() to false, but to me it is only guaranteed if is_iec559() is true. As for what you can rely on if is_iec559() is false, that is a good question. Most of the items in numeric_limits<> appear to require explicit checks for availability if is_iec559() is false. My readings of the Standards (C/C++) seem to show them to be silent on what happens with a function like isnan() if is_iec559() is false. Most of what I've seen on the web is that these functions are of dubious usefulness due to optimizations performed. Clearly one would like to expect that if the compiler is being used at an optimization level that breaks floating-point compliance then is_iec559() would be set to false, but from what I've read that isn't a safe expectation. I guess you're at the mercy of your compiler vendor to describe their levels of support and what these functions may mean. Does anyone else have insight into this situation? Matt

3 2

conversion review report
by Gordon Woodhull 18 Jul '12

18 Jul '12

Hi Vicente, all, Profuse apologies for the long delay in writing this report. Cheers, Gordon Report on Boost Conversion Library Review, August 20-29, 2011. I want to thank Vicente Botet Escriba for submitting the Conversion library for review and for his general good nature in receiving criticism and alternate designs. The Conversion library presents a general framework for plugging in conversion operations between arbitrary types, providing a consistent interface for type-to-type conversions. The library is unfortunately rejected. During the review, there were two votes for acceptance and two against, and some interesting conversation from about a dozen participants. The major reason the library can't be accepted in its current form is that there was near consensus that there is no universal conversion domain, especially when the source or destination type might be a string. Much of the review focused on possible One Definition Rule (ODR) violations, which are a consequence of having a universal customization point using template specializations or function overloads. Many solutions were offered, which will make up the second part of this report, "How to Avoid Universality." I. Concerns about the library Conversions Are Not Generic? While some reviewers didn't see the need for a generic conversion library (and I was a little surprised at the vehemence of their opinions), I don't see this in itself as a reason to reject the library. The library's stated purpose is to provide a common interface for general type <-> type conversions, like lexical_cast does for string <-> type conversions. However, it was interesting that seemingly no one could come up with applications of truly generic conversion, although Jeffrey Lee Hellrung and Antony Polukhin alluded to their existence. Also, some reviewers pointed out that you often need to choose what kind of conversion to do, and a generic library can get in the way here. Strings are the most obvious example: if you are converting from a string representing a binary value it would not work to use a decimal converter. Antony Polukhin pointed out a more subtle example: "lexical_cast<char>(1) and numeric_cast<char>(1) will produce different output." Jeff Hellrung summed this point up nicely: "I think it's certainly possible for different clients using the same generic component to want different conversion implementations for a given pair of types, and that point, Boost.Conversion's universally-defined conversion implementations become useless. One wants the conversion operation to be parametrized as well as the types involved in the conversion." Multi-Client Specialization Concerns Leaving aside possible ODR violations, which we'll return to in Part II, some reviewers questioned the scalability of using template specialization and overloads when many clients (i.e. independent headers) may be customizing the behavior. Vladimir Batov claimed that a system which allows partial specializations on both Source and Target can't be made to work generally. Jeroen Habraken said SFINAE/enable_if "does make code fragile". I'm not clear if these conversations were resolved (or resolvable ;). Non-Generic Solutions Some reviewers objected that conversions should just be defined within individual libraries, but of course this begs the question (as came up recently on the ML between DateTime and Chrono), "which library should house the conversions?" Others (such as Phil Endecott) thought that simple c-style functions such as rgb_to_cmyk() were more explicit and direct. Why is this so complex? Kevlin Henney, initially excited about a general solution to the problem which lexical_cast first set out, commented on the documentation: "Based on casual reading, it feels a little more complex and requires a higher-entry level of knowledge than would be appropriate for many of the people who actually need this functionality." II. How to Avoid Universality One of the positive results of this review was a small catalog of alternatives to a universal customization point involving template specialization or overloaded functions. a. Avoid the Problem In the strictest sense, any library which allows either kind of universal customization can be prone to ODR violations. But many reviewers particularly thought that a customization point involving two UDTs was especially dangerous. To his credit, Vicente was very up-front about the limitations of his design, and attempted to formulate rules for how the library could be used safely. In the documentation, he suggests (IIUC) that header-only libraries could use generic conversions as long as they don't define them, or define them as long as they don't use them. http://tinyurl.com/cmbgyfk b. Inherited tags John Bytheway suggested a tag-dispatch system where conversions are tagged with their source library, and any library which depends on conversions from two libraries would define a tag which inherits from the tags of both libraries. Thus ODR violations are avoided at the expense of having to specify an extra tag (effectively a sort of global conversion domain). http://lists.boost.org/Archives/boost/2011/08/184836.php c. Conversion Domains and Overloaded Function Objects Going on the consensus that there is no universal conversion domain, your humble review manager suggested a metaprogramming solution that defines conversion domain objects which combine a set of conversions within an object. http://lists.boost.org/Archives/boost/2011/08/185259.php A more general solution would be to create an overloaded polymorphic function object, much like a polymorphic-source version of Lorenzo Caminiti's OverloadedFunction library (http://tinyurl.com/72nolyj) However, I have been warned (by Daveed Vandevoorde) that the rules for function overloading are too dangerously complicated to implement in a metaprogram. d. Boost.Dispatch Matthias Gaunard announced that he is working on a library particularly to "solve the problem of specializing a function template for a category of types with best-match selection." http://lists.boost.org/Archives/boost/2011/08/185286.php e. Abuse of Unnamed Namespaces Emil Dotchevski suggested that "It might be possible to abuse unnamed namespaces to avoid violating ODR". I'm not clear if this was a serious suggestion as it wasn't spelled out. :) f. GIL's solution (?) Christian Henning wrote: "GIL has such functionality. I like their way of structuring conversion." However, I was not able to find a description of this mechanism for the report. Thanks to everyone who participated in the review!

2 1