- Boost-users - lists.boost.org

Re: [Boost-users] [BGL] Issue using connected_components
by Nicolas Saunier 16 Dec '11

16 Dec '11

Hi everyone, I finally found a solution by myself to get connected_components from a graph of type adjacency_list<listS, listS, undirectedS> with bundled properties for the vertices and edges. So I will post it here so that others can find it, to get feedback and make sure I am doing it right: #include <boost/graph/adjacency_list.hpp> #include <boost/graph/connected_components.hpp> using namespace boost; using namespace std; struct FeatureConnection { float minDistance; float maxDistance; }; struct VertexInformation { int featureId; int index; }; typedef adjacency_list<listS, listS, undirectedS, VertexInformation, FeatureConnection> UndirectedGraph; int main() { UndirectedGraph g; UndirectedGraph::vertex_descriptor u, v, w, x, y; UndirectedGraph::edge_descriptor e, f; u = add_vertex(g); v = add_vertex(g); w = add_vertex(g); x = add_vertex(g); y = add_vertex(g); bool unused; tie(e, unused) = add_edge(u, v, g); tie(f, unused) = add_edge(x, y, g); cout << num_vertices(g) << " " << num_edges(g) << endl; graph_traits<UndirectedGraph>::vertex_iterator vi, vend; graph_traits<UndirectedGraph>::vertices_size_type cnt = 0; for(tie(vi,vend) = vertices(g); vi != vend; ++vi) g[*vi].index = cnt++; property_map<UndirectedGraph, int VertexInformation::*>::type components = get(&VertexInformation::index, g); int num = connected_components(g, components, vertex_index_map(get(&VertexInformation::index, g))); cout << num << endl; for(tie(vi,vend) = vertices(g); vi != vend; ++vi) cout << *vi << " " << components[*vi] << " " << g[*vi].index << endl; return 0; } Thanks, Nicolas -- Nicolas Saunier, ing. jr, Ph.D. Professeur Adjoint / Assistant Professor Département des génies civil, géologique et des mines (CGM) École Polytechnique de Montréal http://nicolas.saunier.confins.net

1 0

Boost on Mac w/ C++2011
by John M. Dlugosz 16 Dec '11

16 Dec '11

A co-worker reports that on a Mac, turning on the C++2011 dialect (to enable 'auto', lvalue references, etc.) makes the Boost headers choke. The release notes for the latest Boost show an older version of the compiler (Clang) as what is supported. Is there a simple way, like with a #define or a published patch to the config files, to make it work? —John

1 0

Condition Variable and optimization
by John M. Dlugosz 16 Dec '11

16 Dec '11

The example in the documentation for Condition Variables illustrates the implication that these are Mesa-style (non-blocking signals) with this example: boost::condition_variable cond; boost::mutex mut; bool data_ready; void process_data(); void wait_for_data_to_process() { boost::unique_lock<boost::mutex> lock(mut); while(!data_ready) { cond.wait(lock); } process_data(); } This needs to declare data_ready as mutable, so the compiler doesn't reduce the while loop to a no-op and assume the value doesn't change, or just hold it in a register so it doesn't see the change made by another thread. More generally, how do you write it in this case? while ( !collection.empty() ) cond.wait(lock); where the condition is a function of an existing class? The compiler might inline that function and give the same issue. I think a form of wait that takes a predicate ought to be introduced, that prevents this particular issue and ensures correct use. —John

2 2

Parsing statements from ascii files in arbitrary order into hierarchies of structs using boost spirit
by Stefan Zellmann 16 Dec '11

16 Dec '11

Hello! I'd like to parse one-line statements from an ascii file using boost spirit into structs. Statements may be quite different and may occur in arbitrary order. I'm wondering how I can achieve something like the following: /qi::rule<T, Statement(), Skipper> r_statement; qi::rule<T, DerivedStatement0(), Skipper> r_derivedStatement0; qi::rule<T, DerivedStatement1(), Skipper> r_derivedStatement1;/ With: /struct Statement { // empty }; struct DerivedStatement0 : public Statement { // members }; struct DerivedStatement1 : public Statement { // members };/ First thing I'm not sure about is how to adapt (using /BOOST_FUSION_ADAPT_STRUCT/) this hierarchy, since /Statement/ has no members. I've seen some snippets on the internet where inherited members (data members are good for me, no member functions) were adapted using /BOOST_FUSION_ADAPT_STRUCT/, so I'm right to believe that inheritance in my case shell pose no problem? Well, I'm actually not sure if the idea I came up with is the right way to accomplish this in the first place, so I'm grateful for any suggestions on how to do this more appropriately. Thanks in advance! Cheers, Stefan -- Stefan Zellmann Dipl.-Wirt.-Inf. Universität zu Köln RRZK Phone: +49 221 478 86578 Mail: zellmans(a)uni-koeln.de

2 3

[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