- Boost - lists.boost.org

[type_traits] Is it possible to test for an explicit conversion?
by John Maddock 20 Jul '12

20 Jul '12

OK, so we don't have such a trait at present, but one of the requests from the multiprecision review was "make conversions explicit in the front end if they are in the backend". Which to do it nicely (and semi-automagically) requires a trait that tests whether A is explicitly convertible to B. Which would obviously make a useful type trait in it's own right, but.... anyone have any ideas on how such a trait could be implemented? At present it looks "impossible" to me, but I've learned never to say never ;-) Thanks, John.

2 2

Proposal: Linear map
by Amir Ansari 20 Jul '12

20 Jul '12

Hi, In my work I have repeatedly had the need to create a sorted array in which I can insert/lookup from using a key. This is like a map except that it uses an array. The contention is that in some cases, it is faster to insert/remove from a sorted array rather than traversing a tree (the underlying data structure for a map) which involves pointer de-referencing. I would like to call the class linear_map. Looking forward to feedback from everyone. Many thanks, - Amir

5 11

[array] - array_vector
by Hite, Christopher 20 Jul '12

20 Jul '12

I've a got a small utility class that is a cross between boost::array and std::vector for when I only have a compile time constant max things. This is beats to complexity of fighting with custom allocators/pools. const unsigned n=100; Thing array[n]; unsigned count=0; goes to: array_vector<Thing,100> things; It's stl compliant and should drop in anywhere you've got a vector. Like vector and unlike boost::array (or regular array) 100 Things are not constructed. Have I reinvented something in boost? Should I submit it? Also related to this. There are a class of problems where n is known only on runtime, but you still only need it in a certain scope. gcc (C99 standard) allows variable length arrays on the stack. Does anyone know if that is allowed in C++11? What would think about something like this? unsigned n=readInt(); placeholder<Thing> bufffer[n]; //variable length data on stack buffer_vector<Thing> v(buffer,n); Chris

1 0

[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