- Boost-users - lists.boost.org

Re: [Boost-users] boost::filesystem::path operator/= is broken for char[1] in 1.48 (Nat Linden)
by ZNV 21 Apr '12

21 Apr '12

Hi Nat, >> I believe the current operator =/ behavior is outright dangerous and > >> should be fixed. > > Nope, sorry. If you pass a fixed-length array, a proper C++ library > *should* be sensitive to its max. Anything else is unsafe and should > be discouraged. > What if I pass fixed-length array without actually knowing that? There are many C libraries out there assuming char * and char [] are interchangeable. These libraries are well documented. You won't check the source code beforehand if you have the docs, will you? The fact that we're still dealing with legacy C-style APIs is not a > good reason for a modern C++ library to blithely run past the declared > end of a char array. C++ tries very hard to bring type-safety to the > party. It is far more important to try to keep new code from crashing > than it is to accommodate such misleading APIs. > I totally agree with you – type safety is an important C++ feature. It is supposed to help a programmer by eliminating more errors early. But you've achieved just the opposite result with your creative abuse of C++ type system. I would've agreed with your resolution if appending char[1] to boost::filesystem::path resulted in a static_assert. This would allow to apply the proposed workaround immediately (cast to char *). Unfortunately boost::filesystem have chosen to break my code silently instead. I had to hunt the bug in debugger – the same very thing the type safety was supposed to prevent, is not it? So yes technically my program did not crash. But I totally believe that it is not only preventing new code from crashing which is important. Eliminating obscure pitfalls the new code is suffering from is equally important. Every engineering problem is a quest for a better tradeoff. Concerning appending fixed-length array of length one or less to a boost::filesystem::path we are facing the following choices 1) silently treat the operation as a no-op (current) 2) treat it the same way as char * 3) static_assert In my opinion (1) is the worst possible choice since it breaks the code silently in a non-obvious way. When you know you're dealing with code that willfully lies to the > compiler -- even if it's been frozen into an OS API -- use Ovanes's > workaround to pass char* rather than char[size]. > See above.

2 1

Re: [Boost-users] boost::filesystem::path operator/= is broken for char[1] in 1.48 (Ovanes Markarian)
by ZNV 21 Apr '12

21 Apr '12

Hello Ovanes, > This over-allocation is pretty much the same as reserving some space at the > end of the data structure to place data together. Am I right? Why isn't it > possible to just write char[128] or char[16] instead of char[1]? I can't change that code because it lives in a system header. > And if > you know that this buffer represents some special case, why don't you pass > it as such to filesystem? &char[0], than boost::filesystem will not assume > it got char[1] and will be looking to '\0' marker... > How would I know that this buffer represents some special case? FTS(3) library documentation says something like that: struct _ftsent { ... char *fts_name; }; But the structure is really defined another way (Linux, Mac OS X): struct _ftsent { ... char fts_name[1]; }; I believe this discrepancy is pretty much negligible anyway. There are huge number of programs utilizing fts(3) APIs and they don't break. Unfortunately boost::filesystem is another story. It does break and it does break silently.

1 0

boost::filesystem::path operator/= is broken for char[1] in 1.48
by Nick Zavaritsky 21 Apr '12

21 Apr '12

Hi! Please consider the code below: === BUG === boost::filesystem::path some_path("first"); char path_component[1]; /* = "second" */ some_path /= path_component; Some_path value is expected to be "first/second" but it is "first". I.e operator /= had no effect. === END BUG === Concerning a longer string in a char[1] buffer. Actually path_component is the *last* field in a heap-allocated structure. The structure is over-allocated to enable storing a longer string in a char[1] buffer. This technique is often used in C code. Here is operator /= callstack. #0 boost::filesystem3::path_traits::empty<char const, 1ul> () at path_traits.hpp:89 #1 0x0000000100001e7e in boost::filesystem3::path::append<char [1]> (this=0x7fff5fbff910, source=@0x100100270, cvt=@0x100100280) at path.hpp:655 #2 0x0000000100001f77 in boost::filesystem3::path::operator/=<char [1]> (this=0x7fff5fbff910, source=@0x100100270) at path.hpp:235 The relevant excerpt from boost::filesystem3::path_traits::empty follows: namespace path_traits { ... template <typename T, size_t N> inline bool empty(T (&)[N]) { return N <= 1; } ... } It appears that boost::filesystem::path treats char[1] as an empty path regardless of the actual content. This is definitely wrong due to so many C libraries storing long strings in char[1] buffers. In particular on Mac OS X fts(3) FTSENT::fts_name is char[1]. I believe the current operator =/ behavior is outright dangerous and should be fixed. By the way the only code currently benifiting from the boost::filesystem::path being overly smart is the code appending "" (empty string literal) to pathes.

4 3

MSM: Separating templatized on_entry/on_exit into cpp/h
by ev_mp 20 Apr '12

20 Apr '12

Hello, I'm trying to modify the Player example and to separate the on_exit/on_entry template function definition from declaration so I can hide the actual implementation details. "My.h" ... namespace myNamespace { ... // Concrete FSM implementation struct player_state_machine : public msm::front::state_machine_def { ... struct Playing : msm::front::state<> { template void on_entry(event const &, player_state_machine & ); // { "My Secret Code } } ...... } } "My.cpp" namespace myNamespace { ... template void myNamespace::player_state_machine::Playing::on_entry(Event const &, player_state_machine & ); { Here I want to put the actual implementation... } Is this feasible ? If not - what are the alternatives ? As I previously said - putting the implementation into the header is not an option. Any help will be appreciated. Evgeni -- View this message in context: http://boost.2283326.n4.nabble.com/MSM-Separating-templatized-on-entry-on-e… Sent from the Boost - Users mailing list archive at Nabble.com.

2 3

boost mpi and mvapich
by Cornelius Steinhardt 20 Apr '12

20 Apr '12

Hi, have somebody compiled the boost_1.48 with a mvapich compiler? The test from boost mpi get started, which tests the mpi installation works fine. Than i installed the whole library, with adding using mpi : path_to/mpiCC ; into the user-config.jam After this i run ./bootstrap --prefix=where_to_install and ./bjam --prefix=where_to_install install My next step was to test the installation with the first program code from the boost mpi tutorial. ("I am process " << world.rank() << " of " << world.size()) But i get a deadlock in the line mpi::environment env(argc, argv); Can somebody explain me why? or where my failure is? Regards Cornelius

1 0

How to send list from Python to boost python
by Guruswamy B M 20 Apr '12

20 Apr '12

Hi, I have been using boost python for one of my application. In the same I have to send list from python to boost wrapper. Ex:. >From python. a = [1, 2, 3, 4] test(a); In wrapper my C++ fucntion should be like below: void test(list a) { list processing. } I tried similar way, but getting an signature error. I need a help on how to send list from the python, so that can access each element of list in C++ wrapper. Thanks and Regards, Guru

2 2

How to send python list to c++ function
by Guruswamy B M 20 Apr '12

20 Apr '12

Hi, I have been using boost python for one of my application. In the same I have to send list from python to boost wrapper. Ex:. >From python. a = [1, 2, 3, 4] test(a); In wrapper my C++ fucntion should be like below: void test(list a) { list processing. } I tried similar way, but getting an signature error. I need a help on how to send list from the python, so that can access each element of list in C++ wrapper. Thanks and Regards, Guru

2 2

Re: [Boost-users] Timeout on read/write using Boost.Asio
by boost 20 Apr '12

20 Apr '12

So, it implies that it is a bad idea to implement timeout read/write using timer and "cancel". Is there any better solution? Best Regards Zhanwei Wang ----- Original Message -----From: Igor R <boost.lists(a)gmail.com> To: boost-users(a)lists.boost.org > What if I cancel all the async operation, is there any partial data which has been read from or write to socket after the cancelation? > If partial data has been read from or write to socket, how can I issue both async read/write again? Right, some data might have been sent/received, and you have to re-synchronise somehow your client and server. Even if it's possible, it would be pretty complicated. Besides, cancellation is not quite portable: http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/reference/basic_st… That's why it's usually a bad idea to cancel operations on a socket. Instead, you can just close the socket and then re-establish connection from scratch. > I cancel the read/write on a tcp connection because the current node I connected to may be too busy to response, so I can try another node. I do not want cancel all async request because the other pending operations may finish successfully, the workload on peer node is very heavy instead of failure. Well, I don't know what you application does, but I'm afraid it's not the right way to go. First of all, why can't you connect all the "nodes" you need? Anyway, you should decide for every particular connection whether it's ok or "faulty" (returned error, takes too much time, no ping, no heartbeat, etc...): if it's ok - wait for response, if it's faulty - just close it. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [Boost-users] Timeout on read/write using Boost.Asio
by boost 19 Apr '12

19 Apr '12

hi, Thanks for your reply. I cancel the read/write on a tcp connection because the current node I connected to may be too busy to response, so I can try another node. I do not want cancel all async request because the other pending operations may finish successfully, the workload on peer node is very heavy instead of failure. Anyway, I can cancel all request, but I still have the question about the cancel. What if I cancel all the async operation, is there any partial data which has been read from or write to socket after the cancelation? If partial data has been read from or write to socket, how can I issue both async read/write again? Best Regards Zhanwei Wang ----- Original Message -----From: Igor R <boost.lists(a)gmail.com> To: boost-users(a)lists.boost.org > My question is: > the "cancel" call acutely cancel all the pending async operation, but only one of them is timeout. > For example, there is a pending async read and a pending async write operation, only read is timeout, I do not want cancel write any way. Yes, you're right. You'll have to issue both async read and write again. But usually "timeout" means that something goes wrong with the connection (i.e. you expected something, but it failed to happen). _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

Questions about using "mcregor_common_subgraphs" algorithm in Boost Graph Library
by Bin Ren 19 Apr '12

19 Apr '12

Hi, I am a beginner of C++ Boost Library. I am doing a project about "Maximum Common Subgraph" Algorithm, and I found there is an implementation in Boost Graph Library: "boost/graph/mcgregor_common_subgraphs.hpp" I use it like this: (and my question is marked as red) ---------------------------------------------------------------------------------------------------- //Compare the input graphs against the Graph Forest for (int i = 0; i < graphInputs.size(); ++i){ graph_t * pInputGraphi = graphInputs[i]; for (int j = 0; j < graphForest.size(); ++j) { std::cout << "Common Sub graph of input graph" << i << " and graph" << j << " :" << std::endl; //Compare one to one among graphi and graphj graph_t * pGraphj = graphForest[j]; //Here I am using the callback function from the example code: "mcgregor_subgraphs_example.cpp" example_callback<graph_t> my_callback(*pInputGraphi); property_map<graph_t, vertex_name_t>::type vname_mapi = get(vertex_name, *pInputGraphi); property_map<graph_t, vertex_name_t>::type vname_mapj = get(vertex_name, *pGraphj); property_map<graph_t, edge_name_t>::type ename_mapi = get(edge_name, *pInputGraphi); property_map<graph_t, edge_name_t>::type ename_mapj = get(edge_name, *pGraphj); //Print out Maximum connected Common Subgraphs between graphi and graphj mcgregor_common_subgraphs_maximum_unique(*pInputGraphi, *pGraphj, true, my_callback, //edges_equivalent(make_property_map_equivalent(ename_mapi, ename_mapj)), //Here is my problem: if I use both edges_equivalent and vertices_equivalent, the code can not be compiled //However, if I only use vertices_equivalent, I doubt whether the maximum common subgraph result is correct. //If I use edges_equivalent only, the code can be compiled, however, it runs into an infinite loop. vertices_equivalent(make_property_map_equivalent(vname_mapi, vname_mapj))); } } ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Is there any way to use both the edges_equivalent and the vertices_equivalent (Or it is not necessary at all)? BTW, it seems the performance of this algorithm is not perfect; for a small test case below, it needs around 5 seconds by vertices_equivalent, while it loops for a very long time for edges_equivalent (it might be a infinite loop...). Looking forward to your feedback. Thanks and have a good night, Bin ----------------------------------------------------------------------------------------------- Small Test Case: For test, I only use one graph for "graphInputs", and one graph for "graphForest": graphInputs: (v: vertex, 1st number: the vertex id, 2nd number: the vertex name; e: edge, 1st: source vertex, 2nd: target vertex, 3rd: edge name) t # 0 v 0 0 v 1 0 v 2 0 v 3 0 v 4 0 v 5 0 v 6 1 v 7 1 v 8 1 v 9 1 v 10 2 v 11 0 v 12 0 v 13 2 v 14 0 v 15 0 v 16 0 v 17 0 v 18 1 v 19 1 v 20 1 v 21 3 v 22 3 v 23 4 v 24 5 v 25 5 e 0 1 3 e 1 2 3 e 2 3 3 e 3 4 3 e 4 5 3 e 5 0 3 e 0 6 0 e 1 7 0 e 4 8 0 e 5 9 0 e 2 10 0 e 10 11 0 e 11 12 3 e 12 13 0 e 13 3 0 e 11 14 3 e 14 15 3 e 15 16 3 e 16 17 3 e 17 12 3 e 14 18 0 e 15 19 0 e 17 20 0 e 13 21 1 e 10 22 1 e 16 23 0 e 23 24 0 e 23 25 0 graphForest: t # 1 v 0 0 v 1 0 v 2 0 v 3 0 v 4 0 v 5 0 v 6 1 v 7 1 v 8 1 v 9 1 v 10 1 v 11 4 v 12 4 v 13 6 v 14 5 v 15 3 e 0 1 3 e 1 2 3 e 2 3 3 e 3 4 3 e 4 5 3 e 5 0 3 e 0 6 0 e 1 7 0 e 2 8 0 e 3 9 0 e 5 10 0 e 4 11 0 e 11 12 0 e 11 13 0 e 13 14 0 e 12 15 1 If we only use vertex_equivalent, we can get some result like this: This is input Graph 0 <--> 1 5 6 1 <--> 0 2 7 2 <--> 1 3 10 3 <--> 2 4 13 4 <--> 3 5 8 5 <--> 4 0 9 6 <--> 0 7 <--> 1 8 <--> 4 9 <--> 5 10 <--> 2 11 22 11 <--> 10 12 14 12 <--> 11 13 17 13 <--> 12 3 21 14 <--> 11 15 18 15 <--> 14 16 19 16 <--> 15 17 23 17 <--> 16 12 20 18 <--> 14 19 <--> 15 20 <--> 17 21 <--> 13 22 <--> 10 23 <--> 16 24 25 24 <--> 23 25 <--> 23 This is the Graph in Forest: 0 <--> 1 5 6 1 <--> 0 2 7 2 <--> 1 3 8 3 <--> 2 4 9 4 <--> 3 5 11 5 <--> 4 0 10 6 <--> 0 7 <--> 1 8 <--> 2 9 <--> 3 10 <--> 5 11 <--> 4 12 13 12 <--> 11 15 13 <--> 11 14 14 <--> 13 15 <--> 12 Start to do Maximum Common Subgraph Search: Found common subgraph (size 10) 0 <--> 1 5 6 1 <--> 0 2 7 2 <--> 1 3 3 <--> 2 4 4 <--> 3 5 8 5 <--> 4 0 9 6 <--> 0 7 <--> 1 8 <--> 4 9 <--> 5 ....

2 4