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

[StateChart] How to fix "the outer state does not have inner states."
by Zhu Bicen 08 Dec '11

08 Dec '11

Following code can NOT be compiled successfully, according the comment in boost source code I note that the compiler complains the outer state does not have inner state. I want to know how to indicate one state have a inner state, if it didn't have a initial state? Thanks! #include <boost/statechart/state_machine.hpp> #include <boost/statechart/state.hpp> namespace fsm = boost::statechart; class HandlingFileState; class PlayerFsm : public fsm::state_machine< PlayerFsm, HandlingFileState > {}; class HandlingFileState: public fsm::state< HandlingFileState, PlayerFsm/*, PlayingState*/> //if the initial state is uncoment, it can be compiled success. But I don't want this. {}; class NormalPlayingState; class PlayingState: public fsm::state< PlayingState, HandlingFileState, NormalPlayingState > {}; class NormalPlayingState: public fsm::state< NormalPlayingState, PlayingState> {}; int main() { PlayerFsm fsm; } ------ Build started: Project: TestFsm, Configuration: Debug Win32 ------ Compiling... test_fsm.cpp d:\3rd_lib\boost_1_46_1\include\boost-1_46_1\boost\statechart\simple_state.hpp(387) : error C2027: use of undefined type 'boost::STATIC_ASSERTION_FAILURE<x>' with [ x=false ] d:\3rd_lib\boost_1_46_1\include\boost-1_46_1\boost\statechart\state.hpp(30) : see reference to class template instantiation 'boost::statechart::simple_state<MostDerived,Context,InnerInitial,historyMode>' being compiled with [ MostDerived=PlayingState, Context=HandlingFileState, InnerInitial=NormalPlayingState, historyMode=has_no_history ] d:\bzhu\code\trunk\testfsm\test_fsm.cpp(16) : see reference to class template instantiation 'boost::statechart::state<MostDerived,Context,InnerInitial>' being compiled with [ MostDerived=PlayingState, Context=HandlingFileState, InnerInitial=NormalPlayingState ] Build log was saved at "file://d:\bzhu\Code\trunk\TestFsm\Debug\BuildLog.htm" TestFsm - 1 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== and the first error point to : // If you receive a // "use of undefined type 'boost::STATIC_ASSERTION_FAILURE<x>'" or similar // compiler error here then either this state resides in a non-existent // orthogonal region of the outer state or the outer state does not have // inner states. BOOST_STATIC_ASSERT( ( mpl::less< orthogonal_position, typename context_type::no_of_orthogonal_regions >::value ) );

2 1

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

08 Dec '11

Hi Jeremiah, >> Ok, I understand now that vertex_descriptor are integers if one uses a vecS >> for the vertex list. I have changed the type of my undirected graph to >> boost::adjacency_list<boost::listS, boost::vecS, boost::undirectedS, >> VertexInformation, FeatureConnection> and used a simple >> vector<FeatureGraph::vertex_descriptor> for the component map and it works >> nicely. >> >> Another question is about efficiency: what are the advantages/disadvantages >> to use vecS or listS for the list of vertices? > The main difference is the speed of inserting and removing vertices, with > a secondary difference being when vertex descriptors and iterators are > invalidated. Look on the adjacency_list documentation page for more > detail on exactly which operations are affected. > >> Finally, how could I modify my initial code to make it work? > How much of it do you want to keep? The solution I gave you before > requires two changes (to the graph and to the definition of the component > map). If you want to keep the listS vertex container, you could also use > associative_property_map for your components, or add a vertex_index > property to your graph and fill it in before you create your property map. > Are you looking for one of those options? My requirements are a undirected graph, with frequent additions and removals of vertices/edges, and frequent computation of connected components. That is why I thought that listS vextex container was more appropriate. I would expect that the component map could then be some associative map from vertex_descriptors to component id: what is the exact type? Is it necessary to compute a vertex index (what is it exactly), how do I do so and is is computationally intensive? >> I really find it difficult to find the information to use property maps in >> the library: is there a tutorial or a more step by step documentation >> somewhere? > I forgot if the BGL book has any more details, but you can look in > libs/graph/example in the Boost source tree and also in > http://programmingexamples.net/wiki/Boost/BGL for code samples. Thanks for the link and for the help! 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

2 1

[Interprocess] [file_mapping] is there any way to avoid writing a modified file to disc?
by Thorsten Ottosen 08 Dec '11

08 Dec '11

Hi, I'm using file_mapping/mapped_region with Boost 1.45. My idea was to load the memory mapped file in read/write mode and then decrypt the file content in-place (to avoid copying the entire file content). However, this will save a decrypted file :-( Is there any way to avoid the file being saved after in-memory manipulation? -Thorsten

4 9

[GIL] Array to image
by Sapp, Mark 08 Dec '11

08 Dec '11

Hi All, Can anyone point me in the right directions for copying or assigning an array in memory to an image? I'm reading an frame out of an AVI file using Microsoft's vfw32.lib/vfw.h and the function that grabs the frame returns a pointer to a bitmap in memory, like this: BYTE* pDIB = (BYTE*) AVIStreamGetFrame(pFrame, index); And I need to transfer that information into an image. I have extracted the bitmap header and have a pointer to the first pixel, so I suppose I could iterate over each pixel and channel and populate the image by hand, but I imagine there is a better way. Thanks, Mark Sapp Notice: This e-mail is intended solely for use of the individual or entity to which it is addressed and may contain information that is proprietary, privileged, company confidential and/or exempt from disclosure under applicable law. If the reader is not the intended recipient or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If this communication has been transmitted from a U.S. location it may also contain data subject to the International Traffic in Arms Regulations or U.S. Export Administration Regulations and cannot be disseminated, distributed or copied to foreign nationals, residing in the U.S. or abroad, without the prior approval of the U.S. Department of State or appropriate export licensing authority. If you have received this communication in error, please notify the sender by reply e-mail or collect telephone call and delete or destroy all copies of this e-mail message, any physical copies made of this e-mail message and/or any file attachment(s).

3 5

[filesystem] filesystem::absolute() doesn't work with ../relative_path or ./relative_path
by Sachin Garg 08 Dec '11

08 Dec '11

In boost 1.47.0 filesystem v3, boost::filesystem::absolute only appends the relative path to base path. It should also remove "./" from relative paths and "backtrack" on base path if relative path contains "../../" etc. For example, Input: "d:\current\path" ".\..\relative\path" Result obtained: "d:\current\path\.\..\relative\path" Desired result: "d:\current\relative\path" I have created a trac ticket for the same: https://svn.boost.org/trac/boost/ticket/5988 SG

4 5

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

08 Dec '11

Hi, >> Thanks for replying. The problem, and that may seem too simple or silly to >> people familiar with the library, is that I have no idea what should be the >> type of the component map to pass. I tried to declare the components variable >> as: >> >> vector< graph_traits<FeatureGraph>::vertices_size_type > >> components(num_vertices(g)); >> >> And it does not work either. What is the type of the component map, the >> second argument of connected_components? Can you give me an example of a type >> that would work (compile and return the correct results)? > > Try: > > shared_array_property_map< > ...::vertices_size_type, > property_map<FeatureGraph, vertex_index_t>::const_type >> > components(num_vertices(g), get(vertex_index, g)); > > This requires a vecS vertex container, though. > > -- Jeremiah Willcock Ok, I understand now that vertex_descriptor are integers if one uses a vecS for the vertex list. I have changed the type of my undirected graph to boost::adjacency_list<boost::listS, boost::vecS, boost::undirectedS, VertexInformation, FeatureConnection> and used a simple vector<FeatureGraph::vertex_descriptor> for the component map and it works nicely. Another question is about efficiency: what are the advantages/disadvantages to use vecS or listS for the list of vertices? Finally, how could I modify my initial code to make it work? #include <boost/graph/adjacency_list.hpp> #include <boost/shared_ptr.hpp> #include <boost/graph/connected_components.hpp> using namespace boost; using namespace std; struct FeatureTrajectory { int id; }; struct FeatureConnection { float minDistance; float maxDistance; }; struct VertexInformation { shared_ptr<FeatureTrajectory> feature; }; typedef adjacency_list < listS, listS, undirectedS, VertexInformation, FeatureConnection> FeatureGraph; int main() { FeatureGraph g; FeatureGraph::vertex_descriptor u, v; FeatureGraph::edge_descriptor e; u = add_vertex(g); v = add_vertex(g); bool unused; tie(e, unused) = add_edge(u, v, g); g[e].minDistance = 0.; g[e].maxDistance = 1.; g[u].feature = shared_ptr<FeatureTrajectory>(new FeatureTrajectory()); g[u].feature->id =11; g[v].feature = shared_ptr<FeatureTrajectory>(new FeatureTrajectory()); g[v].feature->id =12; cout << num_vertices(g) << " " << num_edges(g) << endl; vector_property_map< graph_traits<FeatureGraph>::vertices_size_type > components(num_vertices(g)); int num = connected_components(g, &components[0]); return 0; } I really find it difficult to find the information to use property maps in the library: is there a tutorial or a more step by step documentation somewhere? Thanks again! 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

2 1

Re: [Boost-users] Boost-users Digest, Vol 2928, Issue 3
by Nicolas Saunier 07 Dec '11

07 Dec '11

Hi, On 11-12-07 02:21 PM, boost-users-request(a)lists.boost.org wrote: > Message: 6 > Date: Wed, 7 Dec 2011 14:19:46 -0500 (EST) > From: Jeremiah Willcock<jewillco(a)osl.iu.edu> > To:boost-users@lists.boost.org > Subject: Re: [Boost-users] [BGL] Issue using connected_components > Message-ID:<alpine.LRH.2.00.1112071418120.25335(a)flowerpot.osl.iu.edu> > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Wed, 7 Dec 2011, Nicolas Saunier wrote: > >> > Hi, >> > >> > here is a simplified code sample that I cannot get to work. I use bundled >> > properties for an undirected graph and I do not find what should be the type >> > of the component map (or property map) that should be passed as the second >> > argument of the connected_components function. The sample is useless since >> > only integers are for vertices. > The normal vector_property_map class does not work for adjacency_list > graphs with a listS vertex container unless you define a vertex_index_map. > Is there a reason you can't use vecS as the vertex container in your > graph? If you truly need listS, you will need to create a vertex index > map, fill it in before you create the property map, and pass it to the > vector_property_map constructor (and as a type argument to that class). > > -- Jeremiah Willcock Thanks for replying. The problem, and that may seem too simple or silly to people familiar with the library, is that I have no idea what should be the type of the component map to pass. I tried to declare the components variable as: vector< graph_traits<FeatureGraph>::vertices_size_type > components(num_vertices(g)); And it does not work either. What is the type of the component map, the second argument of connected_components? Can you give me an example of a type that would work (compile and return the correct results)? 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

2 1

[BGL] Issue using connected_components
by Nicolas Saunier 07 Dec '11

07 Dec '11

Hi, here is a simplified code sample that I cannot get to work. I use bundled properties for an undirected graph and I do not find what should be the type of the component map (or property map) that should be passed as the second argument of the connected_components function. The sample is useless since only integers are for vertices. #include <boost/graph/adjacency_list.hpp> #include <boost/shared_ptr.hpp> #include <boost/graph/connected_components.hpp> using namespace boost; using namespace std; struct FeatureTrajectory { int id; }; struct FeatureConnection { float minDistance; float maxDistance; }; struct VertexInformation { shared_ptr<FeatureTrajectory> feature; }; typedef adjacency_list < listS, listS, undirectedS, VertexInformation, FeatureConnection> FeatureGraph; int main() { FeatureGraph g; FeatureGraph::vertex_descriptor u, v; FeatureGraph::edge_descriptor e; u = add_vertex(g); v = add_vertex(g); bool unused; tie(e, unused) = add_edge(u, v, g); g[e].minDistance = 0.; g[e].maxDistance = 1.; g[u].feature = shared_ptr<FeatureTrajectory>(new FeatureTrajectory()); g[u].feature->id =11; g[v].feature = shared_ptr<FeatureTrajectory>(new FeatureTrajectory()); g[v].feature->id =12; cout << num_vertices(g) << " " << num_edges(g) << endl; vector_property_map< graph_traits<FeatureGraph>::vertices_size_type > components(num_vertices(g)); int num = connected_components(g, &components[0]); return 0; } The final error is: /usr/include/boost/graph/connected_components.hpp:46: error: no matching function for call to ‘put(long unsigned int*&, void*&, long unsigned int&)’ Can someone help me get it to work and to understand property maps? 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

2 1

Boost.Math and Math Constants
by Paul A. Bristow 07 Dec '11

07 Dec '11

Boost.Math has always had an inconspicuous collection of useful math constants, mainly those that are used internally. The presentation of these was as a function-template, called for example, as pi<double>(). using namespace boost::math::constants; return pi<Real>() * r * r; This leads to some rather ugly equations and is most unpopular with scientific and engineering users. John Maddock has now added a new cunning feature that allows the vast majority of users who just want a built-in double to get the constants quickly as plain variables. So in non-template code, users can write using boost::math::double_constants; double area = pi * r * r; and users can read the equations easily. (Float and long double are similarly available in their own namespaces). The original mechanism which can be used for higher multiprecision user-defined floating-point types appears unchanged but has been improved to work better with UDTs and high precision types. Some draft detailed docs about just these new proposals are at http://boost-sandbox.sourceforge.net/libs/math_constants/doc/html/index.html We would like to be sure that 1 This additional mechanism of presenting constants is acceptable. 2 It is acceptable to add more constants (current new list is about 60 constants). Are there important constants that you think we have missed? Do we need a mini-review? Other views? Paul PS 1 Are there important constants that you think we have missed? 2 Please tell me of mistakes and typos in the draft docs. --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

1 0

[range] discrepancy between size and vector ::size
by giecrilj＠stegny.2a.pl 07 Dec '11

07 Dec '11

The following code gives me a warning: void trigger (::std ::vector < int > const &v) { ::boost ::size (v) == v. size (); } and the warning is "signed and unsigned in comparison". I understand that (size == end - begin) and that the latter expression is a difference; however, isn't the difference guaranteed to be positive? Also note that no range function ever uses range_size ::type. I suggest that ::boost ::size should return range_size ::type. Chris

2 1