- Boost-users - lists.boost.org

[Units] Un-scaling dimensionless value
by Lindley French 18 Feb '14

18 Feb '14

I am using Boost.Units to try and compute the number of samples in a time interval, given the sample rate. Given this code: typedef make_scaled_unit<si::frequency, scale<10, static_rational<3> > >::type kilohertz_unit; typedef make_scaled_unit<si::time, scale<10, static_rational<-6> > >::type microseconds_unit; <code> template <typename T=unsigned> using Kilohertz = quantity<kilohertz_unit,T>; template <typename T=unsigned> using Microseconds = quantity<microseconds_unit,T>; // Using boost::rational as the value type neatly avoids overflows Kilohertz<rational<unsigned>> sample_rate(125*si::kilo*si::hertz); Microseconds<rational<unsigned>> duration(10*si::seconds); auto total = sample_rate*duration; </code> Now, when I cout these values, I see that everything is technically the correct. The problem is that total is a dimensionless quantity which is scaled----it's 1,250,000,000, when I expect 1,250,000, and it displays as "1250000000 m", where m is "milli", not "meters". What is the correct way to un-scale dimensionless quantities? I tried this: quantity<si::dimensionless,rational<unsigned>> unscaled(total); However, unscaled still has the same value. I also tried typedef make_scaled_unit<si::dimensionless, scale<10, static_rational<0> > >::type dimensionless_unit; quantity<dimensionless_unit,rational<unsigned>> unscaled(total); but this time, unscaled came out zero. Any suggestions?

3 13

[units] slowness dimension
by Michael Powell 18 Feb '14

18 Feb '14

Hello, I've learned about a "new" (or potentially new-to-boost-units, at any rate) dimension this week. TBD whether we'll be using boost or even units, but in the event we would, I'd like to add a slowness dimension. Basically it is the inverse of velocity: where velocity is time per length, slowness is length per time. Taking a gander at the velocity.hpp physical dimension, doesn't seem like a terribly hard thing to do, and with the new Git-module decomp, even less so today? Thank ye... Best regards, Michael Powell

2 3

[fusion][?] a dictionary with compile time (or types as) keys
by Nick Stokes 17 Feb '14

17 Feb '14

The problem is the following: class TypeDictionary { public: // implementation be here -- and the question is about this }; struct Foo; struct Bar; void userOfTypeDictionary() { TypeDictionary td; td.insert( Foo() ); td.insert( Bar() ); td,insert( double(3.14) ); // and other unknown (to TypeDictionary) // list of types attached // later on, in a different scope perhaps Foo& f = td.get<Foo>() ; Bar& f = td.get<Bar>(); double pi = tg.get<double>(); // ... } Now the question so far seems like right up in the alley of Boost.Fusion, perhaps with a boost::fusion::set, but I am unsure how to manipulate a set of types unknown ahead of time as in code above, and with a -- rather obvious -- extension whereby different instances of TypeDictionary would be used to contain a different set of types, potentially in different compilation units. As for a realistic motivating use case, think of a plugin manager. At any given time of its life an arbitrary heterogeneous set of objects are attached to it, and the it is the manager's job to manage the life time of the attached objects and return (a reference) to them when queried in a type-safe manner. Any ideas on whether such a thing is possible, and how, would be deeply appreciated. Thanks many, Nick

4 5

Boost or Standard when there is the choice?
by Paolo Bolzoni 17 Feb '14

17 Feb '14

Dear list, I was wondering, what is the best pratice when you can select between a standard solution or a boost one? For example, std::tie or boost::tie? std::unordered_map or boost::unordered_map? Personally I tend to use std solutions, but does it make sense? Yours sincerely, Paolo Bolzoni

9 19

[move] differences between results in C++03 and C++11 modes
by Adam Romanek 15 Feb '14

15 Feb '14

Hi! Some time ago I encountered a problem with assigning the return value of boost::move() to a non-const reference in C++11 mode, but not in C++03 mode. See [1] for a StackOverflow question that I created for this issue. It contains all the details so for brevity I won't repeat them here. Could anyone explain this issue? Is this a limitation of C++03 emulation or a defect in the implementation? Best regards, Adam Romanek [1] http://stackoverflow.com/questions/21138869/why-does-assigning-the-return-v…

5 5

[boost.format] another compilation error with VC 2013
by Olaf Krzikalla 14 Feb '14

14 Feb '14

Hi boost, I've encountered another VC 2013 problem. alt_sstream doesn't compile, since its base class std::basic_streambuf has an explicitely nonthrowing dtor. I actually had to fix it at two places: - virtual ~basic_altstringbuf() + virtual ~basic_altstringbuf() BOOST_NOEXCEPT_OR_NOTHROW and + virtual ~basic_oaltstringstream() BOOST_NOEXCEPT_OR_NOTHROW + { } Please, can anyone explain the second place: why doesn't the compiler-generated dtor inherit the nothrow clause? Is it due to the other base class (base_from_member< shared_ptr<...> >)? The weird thing is that MS even advocates the usage of boost.format with MSVC 2013: http://msdn.microsoft.com/en-us/library/hh438469.aspx So I am not 100% sure, whether the problem is boost/MSVC-related or my configuration is wrong. Google is surprisingly quiet regarding the issue. Best Olaf

1 0

Fwd: boost::unique_lock throw a exception
by shada 13 Feb '14

13 Feb '14

I use boost1.52 on windows2003sp2, boost::unique_lock throw a exception, please help me. stack is: *RaiseException_CxxThrowExceptionboost::throw_exception<boost::lock_error>[e:\library\boost_1_52\boost\throw_exception.hpp：67] boost::shared_mutex::timed_lock[e:\library\boost_1_52\boost\thread\win32\shared_mutex.hpp：430]boost::shared_mutex::lock[e:\library\boost_1_52\boost\thread\win32\shared_mutex.hpp：382]boost::unique_lock<boost::shared_mutex>::lock[e:\library\boost_1_52\boost\thread\locks.hpp：510]* ------------------------------------------------------------------------ *bool timed_lock(boost::system_time const& wait_until){ for(;;) { state_data old_state=state; for(;;) { state_data new_state=old_state; if(new_state.shared_count || new_state.exclusive) { ++new_state.exclusive_waiting; if(!new_state.exclusive_waiting) { boost::throw_exception(boost::lock_error()); } new_state.exclusive_waiting_blocked=true; } else { new_state.exclusive=true; }*

3 3

Minimum perfect matching
by Paolo Bolzoni 13 Feb '14

13 Feb '14

Dear list, I am using boost graph and I need to solve a variant of the classic TSP. Boost providess a function (metric_tsp_approx) to get a Halmintonian cycle over a full connected metric weighted graph. However I need something slightly different. I need a path that visits all vertices starting and ending to two well known vertices (let be s and d). Seeking around, I found the suggestion of adding a node connected to s d and with the weight of the edge (s,d). The TSP solution of the new graph is the solution, just removing the new node. The problem is that now the graph is not complete anymore so the metric_tsp_approx's approach does not work anymore. Another possiblity is using a variant of Christofides algorithm, but one of the passages of that is the minimum weight perfect matching. I am a little confused by the documentation of the functions about Maximum Cardinality Matching(1), it is possible to use them to find the a maximum cardinality matching so that the total weight of all selected edges is minimal? Otherwise, is there an alternate approach to my problem? Yours faithfully, Paolo (1) http://www.boost.org/doc/libs/1_55_0/libs/graph/doc/maximum_matching.html

2 3

Re: [Boost-users] intrusive data structures with custom pointer class
by Matei David 12 Feb '14

12 Feb '14

On Fri, 07 Feb 2014 16:00:31 -0500 boost-users-request(a)lists.boost.org wrote: > Message: 6 > Date: Fri, 07 Feb 2014 22:00:23 +0100 > From: Ion Gazta?aga <igaztanaga(a)gmail.com> > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] intrusive data structures with custom > pointer class > Message-ID: <52F54967.9020704(a)gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > El 06/02/2014 23:52, Matei David escribi?: > > Hi, > > > > > > I would like to use some boost::intrusive data structures (lists and > > trees) in a project I'm working on, but I ran into trouble trying to > > customize the existing classes to my needs. I decided to post my > > problem here, in case somebody knowledgeable of boost::intrusive > > *implementation details* can assist me. Thank you in advance. > > Hi Meti, > > You have a lot of questions, I hope I can answer most of them. > > > Background: > > > > In the project I'm working on, I need to manage a large number of > > objects in memory. The data is dynamic, so I need to be able to > > alloc&dealloc objects, in addition to keeping the objects in various > > lists&trees (for which I'm trying to use boost::intrusive). The RAM > > usage is large (think, >100GB), but the number of objects is smaller > > than 2^32. So one thing I'd like to do is to replace 8-byte raw > > pointers with 4-byte offsets into a deque. Doing this would solve > > the alloc/dealloc part. However, I now need to customize > > boost::intrusive containers to work with these 4-byte offsets > > instead of raw pointers. > > I guess the deque is a global object, right. What do you mean with > "offset" into a deque? It's the offset passed to "deque::operator[]"? Hi and thanks for the reply. Contrary to some of the things you said, I found a way to (partly?) implement my specific use case with boost::intrusive. However, I have some concerns: - I only tested a small part of the boost::intrusive functionality with my customizations, so my success might be superficial. Could you have a look and make an informed guess as to how stable this is? - I am concerned that further boost updates might inadvertently break my customizations, and I would hate to list =1.55 as a specific dependency (as opposed to >=1.55). I understand this can never be fully avoided, but I'm hoping you could decide to support my use case, either officially by including it in the code base and the docs, or at least non-officially by being aware of it. I found and fixed this along the way: https://svn.boost.org/trac/boost/ticket/9650 Let me restate my specific use-case: I have several types A, B,..., and I want each object a1 of type A to be kept in a tree (say) along with other A objects (not all A objects go in the same tree). Since there are so many A objects, I care about their memory usage. Specifically, I want to replace 8-byte pointers (A*) by 4-byte handles (which I call Ptr<A>). An A-handle is really an uint32_t offset into the array of type A objects. A B-handle is also an offset, but into another array, holding B objects. Thus: - The transformation handle-to-object_address is O(1). - The transformation object_address-to-handle is prohibitive. - I can only use A-handles for A objects stored in a unique A-object array. If I construct an A object elsewhere, I can refer to it with a raw pointer, but not with an A-handle. - Objects of type B are stored in a different array than objects of type A. This means, in particular, that handles are not freely re-interpretable as real/smart pointers are with casts. So, dereferencing the A handle 42 gives me the A object number 42 from the A object array; but dereferencing the same handle reinterpreted as a B handle gives me the object number 42 from the B object array. NOTE: These pointer casts are my primary source of concern. I will come back to this below. My goal is to make boost::implicit structures work with these handles instead of raw/smart pointers. Intuition tells me there isn't a serious reason why they shouldn't, and that this type of scenario is general enough to be of interest to others, and therefore to boost maintainers. My (partial) success is here: https://github.com/mateidavid/sga/raw/matei-dev/src/Dev/factory.hpp https://github.com/mateidavid/sga/raw/matei-dev/src/Dev/test-i_list-orig.cpp https://github.com/mateidavid/sga/raw/matei-dev/src/Dev/test-i_tree-orig.cpp The code is a work in progress. You'll need a few more included files. I'm compiling with, e.g.: $ [g++|clang++] [-DNONSTATIC_VALUE_TRAITS] -I <path_to_1_55> -g -O0 -std=c++0x -pedantic -Wall -Wextra -o test-i_list-orig test-i_list-orig.cpp common.cpp globals.cpp For lists with nonstatic traits, you need the bug fix mentioned earlier. > > - Given a type T, I rolled out pointer-replacement class Ptr<T> > > which holds a 4-byte int, and upon operator*, it produces a Ref<T> > > object. > > - A reference-replacement Ref<T> class similarly holds a 4-byte int, > > it implements operator& which produces the associated Ptr<T> > > object, and it also provides an operator T& () conversion which > > dereferences the object from the deque. > > - With these, I tried a custom traits struct looking like this: > > value_type = node := T > > node_ptr = pointer := Ptr<T> > > reference := Ref<T> > > Boost.Intrusive models (or tries to model) a pointer type that can be > modeled with std::pointer_traits (more precisely > boost::intrusive::pointer_traits). In that model the reference type > must be a type that implements the dot operator. Sadly in C++ there > is no way to implement a class that overloads this operator. That's > why your pseudo-reference type will not work. I thought about this. There are 2 different perspectives. From the point of view of the boost::intrusive data structures (e.g., list), I think these structures should never ever dereference any object they store. So, e.g. inside list.hpp, if we have somewhere an object val of type "reference" (such as in insert()), the code should never use "o.<field> = 42". Instead, whatever fields the data structure needs to access (like r/w access to parent pointers), they should access them through the traits class methods (e.g. traits::set_field(o,42)). However, this already seems to be the case today. From the POV of the traits classes, indeed, these need to dereference values. First of all, there is a problem with the function signatures. In http://www.boost.org/doc/libs/1_55_0/doc/html/intrusive/value_traits.html the signature of to_node_ptr should be changed from: static node_ptr to_node_ptr (value_type &value) to: static node_ptr to_node_ptr (pointer_traits<pointer>::reference value) This just involves changing the docs; you can change the signature (as I did in my customization) and it compiles just fine. Also, even with the right signature, the function should never do: { return value.get_node_ptr(); } but instead: { return (&value)->get_node_ptr(); } because both reference::operator& and pointer::operator-> are overloadable. However, the concern about traits classes is not as serious as the one about the data structures because users are given the option to write their own traits classes anyhow. So overall, I think the problem with the dot operator isn't serious enough to make this use case unattainable. > > A. The traits classes seem to be there to support 2 existing > > customization types, namely the situation where "node" is a base > > class of "value" (implementing "base hooks") and the situation > > where "node" is a member of "value" (implementing "member hooks"). > > My situation represents a 3rd customization type. > > You can use function_hook, the hook does not need to be a member or > base class. The hack I used seems to work for now. In the future, I think it would be nice to have the option to explicitly specify the header node (so the container would just use a pointer) in the interest of clearly separating any type of node/value allocation from the containers. But I wouldn't say that's a priority. > > B. Even though the traits classes allow one to specify pointer > > types, it's possible (?) that under the hood the classes were > > designed to support only raw pointers and smart pointers, not the > > indirect offset-like pointers I need. > > See previous answer about supported reference types. > > > Given A&B, it seems to me that in my customization I would need 2 > > different hacks. In the interest of code stability, I started > > wondering whether it is feasible to adapt existing boost::intrusive > > data to my needs (my first instinct) as opposed to simply rolling > > out my own rbtree. > > I don't know the impact of supporting smart reference types. It might > be impossible, I haven't tried it. > > > 0. Obviously: Have you seen a similar situation being dealt with > > before? Maybe there's an existing solution out there. My reluctance > > to rolling out my own intrusive rbtrees is due to the fact I'd have > > to test them, as opposed to using a known implementation. > > > > 1. Are boost::intrusive data structures supposed to support custom > > pointer classes (neither real pointers nor smart pointers)? For > > instance, in 1.46 I found this code in > > boost/intrusive/detail/tree_algorithms.hpp > > Yes, boost::interprocess::offset_ptr (but a raw reference can be > converted to a smart pointer easily). > > > static node_ptr uncast(const_node_ptr ptr) > > { > > return node_ptr(const_cast<node*>( > > ::boost::intrusive::detail::boost_intrusive_get_pointer(ptr))); > > } > > However, intrusive lists worked just fine in 1.46, which suggests > > this was simply a bug. > > This was fixed in recent Boost releases using pointer_traits to > implement this function. You can customize pointer_traits to > implement your own version. > > > 2. Can you point me to an example of defining and using custom > > pointer class with boost::intrusive? To enable compilation (of > > lists only) in 1.46, I had to customize std::iterator_traits (that > > part I understood), but then also boost::pointer_to_other and > > boost::intrusive::detail::smart_ptr_type. Even though the code > > compiled, I don't know what those are doing exactly, so I'm weary of > > them. > > See the example in libs/intrusive/example/doc_offset_ptr.cpp and > boost/interprocess/offset_ptr.hpp. See the most recent boost version > for fixed bugs. A dumb smart pointer is used in boost intrusive > tests, and it's found in libs/intrusive/test/smart_ptr.hpp, but it's > a bit oudated. Anyway I think pointer requirements for > Boost.Intrusive might no be correctly specified and it might require > some fixes. Recent versions uses pointer_traits, and I recommend you > this approach. > > > 3. In 1.55, I have a few more pages of errors, I think mainly due to > > these pointer customization issues I don't fully understand. > > Something seems to have changed from 1.46 to 1.55. Is there a > > reference about what changed? Or is there a portable way of rolling > > out such a custom pointer class? > > pointer_traits was specified and all code was ported to use this > customization point. The reference type is assumed to be a raw > reference (as there is no way to overload operator dot to implement a > working smart reference). > > The only why to use Boost.Intrusive would be to implement a smart > pointer (of any pointee type) that can be fastly obtained from raw > reference. If this is your case, Boost.Intrusive might already have > all that you need. If you need a "smart reference", then > Boost.Intrusive is not prepared for this and I don't know how many > effort would require adding support for this (even if this approach > is feasible). > > The problem with "node" objects embedded in the container could be > solved with an option that allows external allocation of these nodes. > > Best, > > Ion Empirically, since I got the containers (at least partially) working with non-standard references, they must be already prepared to handle those. Theoretically, as I described above, the containers themselves should never have to dereference specific fields anyhow, and therefore should be immune to reference type changes. The more serious concern, ***and the reason I wrote all this***, is with pointer casts. Unlike raw or smart pointers, these handles are type-specific. So casting them to something else and then dereferencing that object should be done with care. Take bstree, for instance. Its base class (bstbase3) inherits from node & Value_Traits. The way you obtain access to the Value_Traits struct (used with stateful traits) is through a pointer which you later want to dereference: typedef typename pointer_traits<node_ptr>::template rebind_pointer<const real_value_traits>::type const_real_value_traits_ptr; const_real_value_traits_ptr real_value_traits_ptr() const { return pointer_traits<const_real_value_traits_ptr>::pointer_to( this->get_real_value_traits()); } With handles, the only way I see for this to work is to eventually transform handles into real pointers. So, Ptr<T>::rebind<U>::type should be U* except for U in {T, const T} and possibly {void, const void}. I initially tried to wrap voids as well, but I get errors. (Try adding -DWRAP_VOID when compiling test-i_list-orig.cpp) The problem are these casts: - In iiterator_members: const_void_pointer := pointer_traits<NodePtr>::rebind_pointer<const void> - In iiterator: void_pointer := pointer_traits<node_ptr>::rebind_pointer<void> - In list_iterator: const_real_value_traits_ptr := pointer_traits<void_pointer>::rebind_pointer<const real_value_traits> - iiterator_members ctor takes as 2nd argument a const_void_pointer - list_iterator ctor calls iiterator_members ctor, passing as 2nd arg a const_real_value_traits_ptr When I wrap voids: const_void_pointer := Ptr<const void> void_pointer := Ptr<const void> const_real_value_traits_ptr := value_traits* which means the container code is trying to cast: Ptr<T> -> value_traits* -> Ptr<const void> -> value_traits* -> deref, and the 2nd cast fails. However, things seemed to work ok if I don't wrap voids. So the main concern with my use case is that: ***intrusive containers should not cast node_ptr objects into other types of pointers (not even void*), and then attempt to cast them back***. They can cast other pointers (such as value_traits*) to void* and back, but not node_ptr-s. Please have this use case in mind when further developing boost::intrusive. The files I linked above can serve as a basic test case. I can help writing up this use case in slightly more detail if you think that would be useful for others. Thanks, Matei

2 1

[boost.tr1] compilation errors with VC 2013
by Olaf Krzikalla 12 Feb '14

12 Feb '14

Hi, I have encountered plenty of compilation errors with VC 2013 caused by including <boost/tr1/memory.hpp> or <boost/tr1/functional.hpp>. The errors happen with all versions tried (1.40, 1.53 and 1.55). Is boost.tr1 deprecated for newer compilers? Best Olaf

3 3