- Boost-users - lists.preview.boost.org

[Geometry] 3D Oriented Bounding Box
by Jérémy Coulon 15 Dec '11

15 Dec '11

Hi All, Boost.Geometry looks promising for my personal projects. Reading the doc, I couldn't figure if it is possible to create a 3D oriented bounding box (OBB). I read that axis aligned bounding box (AABB) is supported but nothing on OBB. I need to use it in usual algorithms like intersetion, distance, ... Can anybody tell me if it is possible with the current Boost version and how I can achieve that ? Thanks. Jérémy

3 4

Boost Threads on Android
by John M. Dlugosz 15 Dec '11

15 Dec '11

I've heard that there are some issues with using Boost libraries that are not header-only on the Android platform. Where might I find some real information on that?

2 1

no thread pool?
by Jeff Graham 15 Dec '11

15 Dec '11

Hello, I do not see a thread pool in current boost. Has one never been accepted? Thanks.

2 1

[gil] Project Link
by Dan Bloomquist 15 Dec '11

15 Dec '11

I have put my adventure with gil on the web, this is just the start. If I have any stuff that needs attention about gil, I'd like to hear it. I'm thinking this will help others that have not started with gil yet. <http://lakeweb.net/test/codeproject.html> Best, Dan.

2 1

Re: [Boost-users] [Units] Temperature conversion problem
by Pieter 14 Dec '11

14 Dec '11

>>>> If 'f' is 212ÂºF, why, when converting it to ÂºC, do I end up at 117 and change? Is this really what we should expect? It seems that this very simple use case produces unexpected, and to a casual user wrong, results. I understand the need for complexity but it seems to show up very early in the user experience. >>> >>> Because a temperature change of 212ÂºF is equal to a temperature change of 117.778ÂºC = (5/9)*212. What would you expect the following to do: > > >> [ snipped a very complete response ] > >> Hi Matthias, > > Sorry, I didn't explain myself very well. I was merely surprised that quantities of temperature are, by default, temperature differences not absolute temperatures. With my rusty engineering hat on, I'd have expected quantities of temperature to be absolute so they're consistent with the published literature. I think of temperature differences as needing explanation such as outputting a Celsius temperature difference as Âºâˆ†C (delta ÂºC, ÂºdC, ...) rather than expressing a temperature difference with just ÂºC. Operating under the principle of least surprise, I found the default temperature behavior surprising, that's all. I don't know how useful temperature difference by itself really is but I'd guess it's less common than absolute temperatures or normalized temperatures though differences are useful, for example, in temperature gradients. >Don't mean to come across as prickly - there was just a lengthy debate on this topic during review. Basically, while the first order "principle of least surprise" is probably for temperatures to be absolute, this would make quantities of temperature an anomalous special case relative to all other quantities and would immediately cause problems when someone wanted, e.g., to implement something like the Planck radiation law, etc... In any case, we do appreciate feedback and try to incorporate suggestions for improvements wherever possible. >Cheers, >Matthias Dear Matthias, In the example given by you earlier: quantity<fahrenheit::temperature> f(32*fahrenheit::temperature()); quantity<celsius::temperature> c(0*celsius::temperature()); std::cout << f+quantity<fahrenheit::temperature>(c) << std::endl; std::cout << quantity<celsius::temperature>(f)+c << std::endl; would give different outputs 32+32 = 64 and 0+0 = 0 if the temperature were to be interpreted as being absolute. As far as I see it, it is in fact not ‘the order of conversion, but rather the scale that is used to do the addition in is what matters: in the Fahrenheit scale, taking twice the absolute temp. means something different than taking twice the absolute temperature in the Celsius scale (due to the affine relation between the scales). This does not make it meaningless to allow such additions (or other arithmetic operations). To give an example: take Plank’s radiation law which computes radiation of a body as a function of the temperature T in K, which is of the form (for appropriate constants a1 and a2): B(T) = a1*(1-exp(a2*T))^-1 As arithmetic is not allowed on absolute temperatures, my implementation would have to define T as a relative temperature, something like (in admittedly non-compiling 'code'): quantity<intensity> BodyRadiation(const quantity<si::temperature>& T) { // define a1 and a2 here return a1*(1/(1-std::exp(a2*T))); } Suppose the radiating body is at room temperature which I measure using my thermometer on the wall as 20.0 degrees Celsius. When I would define this as a relative temperature: quantity< celsius::temperature> TRoomInCelcius(20.0); and plug it into the radiation law: Intensity = BodyRadiation(quantity<si::temperature>(TRoomInCelcius)) This would give wrong results (without any warning) as the value T = 20K would be used unintentionally. I know it is the intent of the library to emphasize safety over convenience but I fail to see a problem with my abstraction here, while I don't regard this safe behavior. To get correct results I would need to define my room temperature as being absolute: quantity< absolute<celsius::temperature> > TRoomInCelcius (20.0); then translate it into an absolute temperature in K: quantity<absolute< si::temperature> > TRoomInK(TRoomInCelcius); and then ‘somehow’ translate this into a relative temperature to be plugged into the model, maybe like: quantity<absolute<si::temperature> > TZero(0*si::kelvin) ; quantity<si::temperature> T(TRoomInK – TZero); Intensity = BodyRadiation(T) which is far from elegant of course. Core of the matter is that I need the temperature to be converted using the ‘absolute’ notion, while I need it to be interpreted as ‘relative’ to be able to use it in the radiation law. This while the underlying numerical value of the ‘relative’ and ‘absolute’ temperature is the same and in both cases represents the same measured value. If arithmetic on the absolute type was allowed, this could all be avoided as the model could be specified in ‘absolute’ temperature – I don’t really understand why you say that would not make sense. I am not sure whether there is an elegant solution to allow this in natural manner. Maybe conversion for units with affine relations between scales should only be allowed to be explicitly done in either the absolute or relative manner, which could possibly also relieve the need for two different 'types' of temperature; as the example shows a single measurement can have both 'relative' and 'absolute' interpretations in the current system depending on the context in which it is used and the type of conversion that the context requires. Does this make any sense to you? Kind regards, Pieter

1 0

b-tree merge
by Jeff Ramsey 14 Dec '11

14 Dec '11

As an example, I've the following b-tree model with each node containing tag/value pairs. The tree indicates precedence (or priority), with the root being highest, down to the leaves as lowest (but this is application specific). I want to merge a new tree section into the parent, with the new section containing potentially common tag/value pairs all the way down to the node just above a leaf node (a completely duplicate new tree section would just not be merged). E.g. Existing tree (tag,value) pairs indicated: A,0 ,----------,----|--------, B,1 B,2 B,3 ,------|------, C,1 C,2 New tree to merge: A,0 | B,3 ,------|------, C,1 C,2 Final merged tree: A,0 ,----------,----|--------------, B,1 B,2 B,3 ,------|------, ,-----------, C,1 C,2 C,1 C,2 Question: is there a boost solution to this b-tree merge, and if not any suggestions? Thanks.

1 0

[Ref] unwrap_ref and TR1
by Krzysztof Żelechowski 14 Dec '11

14 Dec '11

The following code is valid: #if 1 #include <boost/ref.hpp> int const & (&b_unwrap_ref) (int const &) ((::boost ::unwrap_ref)); #endif The following code, however, is not (as of libstdc++ 4.5.1): #if 1 #include <tr1/functional> int const & (&tr1_unwrap_ref) (int const &) ((::std ::tr1 ::unwrap_ref)); #endif With the following diagnostic: > error: ‘unwrap_ref’ is not a member of ‘std::tr1’ So I started to ask myself: WTF? * It turns out that unwrap_ref did not make it to TR1, although reference_wrapper did. But why? * Because ref.hpp did not provide it when TR1 was formed? [1] Implication: * unwrap_ref (std:: reference wrapper) is a mismatch. #if 1 void test () { unwrap_ref (::boost ::cref (0)); unwrap_ref (::std ::tr1 ::cref (0)); // error: ‘unwrap_ref’ was not declared in this scope ::boost ::unwrap_ref (::std ::tr1 ::cref (0)); // error: error: invalid initialization of non-const reference } #endif Shouldn't we do something about it? Like, e.g., extend the scope of unwrap_ref to cover the corresponding standard class? This would at least allow expression #3. Chris ___ [1] <URL: https://svn.boost.org/svn/boost/!svn/bc/16384/trunk/boost/boost/ref.hpp >

1 0

challange to MPL gurus
by Robert Ramey 14 Dec '11

14 Dec '11

I am trying to implement concept checking for a couple of MPL concepts as part of a large project. I've having a heck of a time with some aspects of this. The example below illustrates one of the problems I'm having. The intent is to test the concept. for next<I>, the concept check is invoked recurrsively until the end of iteration is encountered. (I'm assuming it's a list in this test). But the is_end<false_> branch is always invoked leading to failure on both MSVC 9.0 and gcc 4.5.3 compilers I'll be quite impressed with anyone who can figure out how to make this work. Robert Ramey template<typename I> struct ForwardIterator { template<typename B> struct is_end {}; template<> struct is_end<false_> { typedef typename deref<I>::type t1; typedef typename next<I>::type t2; BOOST_CONCEPT_ASSERT(( ForwardIterator<t2> )); }; typedef typename boost::mpl::print< I >::type t1; typedef typename is_end< typename boost::is_same< boost::mpl::l_iter<boost::mpl::l_end>, I > > type; BOOST_MPL_ASSERT(( is_convertible< typename I::category, forward_iterator_tag > )); }; template<typename S> struct ForwardSequence { typedef typename end<S>::type t2; BOOST_CONCEPT_ASSERT(( ForwardIterator<t2> )); }; #include <boost/mpl/list.hpp> void test_list_sequence(){ BOOST_CONCEPT_ASSERT(( boost::mpl::ForwardSequence< boost::mpl::list<int, char> > )); }

4 15

Re: [Boost-users] Removing a vertex and adding another one with the same id causes segmentation fault?
by Alper Aydemir 14 Dec '11

14 Dec '11

The formatting went bad with the previous email. Sorry about that. Here it is once again. Hello, I'm using a labeled graph typedef boost::labeled_graph<boost::adjacency_list<boost::listS, boost::listS, boost::undirectedS, Room, RoomEdge>,std::string> MyGraph; which lets me access vertices with string ids. I add a vertex and set it's relevant fields this way: MyVertex u = boost::add_vertex(id, g); g[id].category = category; //crashes here g[id].vertex_id = id; Here id is an std::string. And remove them like so: // First we remove all edges from this vertex BGL_FORALL_VERTICES(v, g, MyGraph){ if (QString(g.graph()[v].vertex_id.c_str()).compare(roomIdToBeRemoved) == 0){ ve = v; BGL_FORALL_OUTEDGES(v, e, g, MyGraph) { ev.push_back(e); } } } foreach(MyEdge e, ev){ remove_edge(e,g); } // Then we remove the vertex itself remove_vertex(roomIdToBeRemoved.toStdString().c_str(),g); This so far seems to work. The trouble is, if I want to add a removed vertex once again with the same id, I get the following: Exception Type: EXC_BAD_ACCESS (SIGSEGV) while setting the fields of the newly added vertex (above commented "crashes here"). What might be the reason? I'm using boost functions for removing/adding things.

1 0

Error in accessing label of an edge, urgently need help.
by Amanullah Yasin 14 Dec '11

14 Dec '11

Hello, I want to put edge label but facing an error. Please share any better idea. Thanks in advance. YASIN ======================= My graph is: namespace boost { struct computable_object_t { typedef vertex_property_tag kind; }; } typedef boost::property<boost::vertex_index_t, unsigned int, boost::property<boost::computable_object_t, plComputableObject*> > slVertexProperty; typedef boost::property<boost::edge_weight_t, slScoreValueType, boost::property<boost::edge_name_t, std::string>> slEdgeProperty; typedef boost::adjacency_list<boost::vecS, boost::listS, boost::bidirectionalS, slVertexProperty, slEdgeProperty> slGraph; slGraph graph; .... ... //Now i want to add edge name boost::property_map<slGraph, edge_name_t>::type labelmap = get(edge_name, graph); for(tie(ei, ei_end) = edges(graph); ei != ei_end; ++ei){ string label = "unknown"; put(labelmap, *ei, label); cout<<"\nUndirected s: "<<vertex_id[source(*ei, graph)] <<" T: "<<vertex_id[target(*ei, graph)]<<" LABEL: "<< get(labelmap,*ei); } ////////////But it gives me an error//////////////// E:\ProBT22\boost_1_46_1\boost/property_map/property_map.hpp(361): error C2679: binary '=' : no operator found which takes a right-hand operand of type 'const std::string' (or there is no acceptable conversion) 1> E:\ProBT22\boost_1_46_1\boost/pending/detail/property.hpp(21): could be 'boost::detail::error_property_not_found &boost::detail::error_property_not_found::operator =(const boost::detail::error_property_not_found &)' 1> while trying to match the argument list '(boost::detail::error_property_not_found, const std::string)' 1> MMHC\ResultAnalysis.cpp(558) : see reference to function template instantiation 'void boost::put<boost::adj_list_edge_property_map<Directed,Value,Ref,Vertex,Property,Tag>,Ref,boost::detail::edge_desc_impl<Directed,Vertex>,std::string>(const boost::put_get_helper<Reference,LvaluePropertyMap> &,K,const V &)' being compiled 1> with 1> [ 1> Directed=boost::bidirectional_tag, 1> Value=boost::detail::error_property_not_found, 1> Ref=boost::detail::error_property_not_found &, 1> Vertex=void *, 1> Property=boost::property<boost::edge_weight_t,slScoreValueType>, 1> Tag=boost::edge_name_t, 1> Reference=boost::detail::error_property_not_found &, 1> LvaluePropertyMap=boost::adj_list_edge_property_map<boost::bidirectional_tag,boost::detail::error_property_not_found,boost::detail::error_property_not_found &,void *,boost::property<boost::edge_weight_t,slScoreValueType>,boost::edge_name_t>, 1> K=boost::detail::edge_desc_impl<boost::bidirectional_tag,void *>, 1> V=std::string 1> ]

2 2