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

[Format] boost 1.48.0, vs2010 runtime check triggered by cast to smaller type in feed_args.hpp
by david x callaway 09 Dec '11

09 Dec '11

running the code below triggers a runtime crash due to casting to a smaller type in feed_args.hpp if -RTCc is given. we turn on this runtime check for debug builds as shown in the sample code. so far the only remedy I've found is to turn off runtime checks for the entire module, not a nice solution. microsoft's suggestion, to use a pragma to turn off the check, doesn't work (not your problem I know). the same issue exists in boost 1.47.0. thx dxc // ----- cut ---- // boost 1.48.0 // visual studio 10.0, service pack 1, windows 7/64 // using this pragma, per microsoft, does not solve the problem // #pragma runtime_checks( "", off ) #include <string> #include <boost/format.hpp> // compile: cl -EHsc -W4 -I /path/to/boost -MDd check.cp // runs fine with no runtime check, output as expected // if you include -RTCc, runtime size checks, it goes into the debugger // compile: cl -EHsc -W4 -RTCc -I /path/to/boost check.cpp // static_cast triggers runtime error at feed_args.hpp:168 int main() { std::string documenttype("1"); std::string key(boost::str(boost::format("name[documenttype:%1%]")%documenttype)); std::cout << key << "\n"; // expected output: name[documenttype:1] return 0; } // #pragma runtime_checks( "", restore )

2 2

[boost][chrono] time_since_epoch different on windows and linux
by Ralf Globisch 09 Dec '11

09 Dec '11

Hi, I've run into a bit of a funny one and I'm not sure if I'm missing something or whether I've encountered a bug. The following code excerpt *seems* to have 2 different results on windows 7 (VS2010) and linux (gcc4.6) using boost version 1.47. #include <iostream> #include <cstdint> #include <boost/chrono.hpp> int main(int argc, char** argv) { boost::chrono::duration<double> sec = boost::chrono::system_clock::now().time_since_epoch(); uint32_t uiSeconds = sec.count(); double dMinutes = uiSeconds/60.0; double dHours = dMinutes/60.0; double dDays = dHours/24.0; double dYears = dDays/365.0; std::cout << "Sec: " << uiSeconds << " Min: " << dMinutes << " Hours: " << dHours << " Days: " << dDays << " Years: " << dYears << std::endl; return 0; } This outputs the following: Linux: Sec: 1323362917 Min: 2.2056e+07 Hours: 367601 Days: 15316.7 Years: 41.9636 Windows: Sec: 82934819 Min: 1.38225e+006 Hours: 23037.4 Days: 959.894 Years: 2.62985 The linux results is the expected result: 1970 + 41 years = ~2011. Why does the windows result differ? I've run the windows version on two different windows machines with the same result. Am I using the library incorrectly? I'm trying to obtain seconds since 1970 so that I can from there calculate seconds since 1900 to calculate an NTP timestamp. Thanks for any help/suggestions! Ralf

4 5

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

08 Dec '11

Hi, thanks again for replying. I may sound stupid, but again, I cannot find what is the type of the component map to pass to connected_components when the graph is of type adjacency_list<listS, listS, undirectedS>. The following does not work (see previous email for the whole code): map<FeatureGraph::vertex_descriptor, graph_traits<FeatureGraph>::vertices_size_type> vertex2component; vertex2component.insert(make_pair(u, 0)); associative_property_map< map<graph_traits<FeatureGraph>::vertex_descriptor, graph_traits<FeatureGraph>::vertices_size_type> > components(vertex2component); Can someone please give me the declaration of the component map, and how to pass it to connected_components? Thanks, Nicolas On 11-12-08 02:08 PM, boost-users-request(a)lists.boost.org wrote: > If you use an associative property map, you will not need a vertex index > map. See > http://www.boost.org/doc/libs/1_48_0/libs/property_map/doc/associative_prop… > for documentation on how to create one. > > -- Jeremiah Willcock -- 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

[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