May 2009 - Boost-users - lists.boost.org

POD 3d vectors
by gtsml owevwr 04 Jun '09

04 Jun '09

Hi, I need fast low dimensional vector (2, 3 and 4 dimension let say). How shall I implement them with boost? Off course ublas is a possibility but I feel it's more designed for higher dimension. Ideally, low dimension vector are better as POD, without any pointer indirection for instance. Maybe there's a way to enforce no indirection with ublas? Off course, boost::array would do the trick but it doesn't have any of the basic arithmetic operators. I could easily add them with the operators library, but maybe there's a better way? And off course, could be great to have POD small matrices as well... I know this request is probably over specialized but maybe I'm missing something already there Thanks, Frank

8 7

[string_algo] replace string with tokens
by Michael Schuster 03 Jun '09

03 Jun '09

Hello, I'm new to string_algo and have the following problem: I have string like a+3*sin(b) and want to replace a by a different string e.g. Alpha and b by Beta and sin by cos so that Alpha+3*cos(Beta) is the result. So tokens would be "+*()" The replace command works with spaces, but I think this should be possible with string_algo, too? Thanks for any hint Michael Schuster

3 2

[BGL] A bug in const bundle_property_map or in Readable Property Map Concept ?
by Dmitry Bufistov 03 Jun '09

03 Jun '09

Hi there, The attached test case fails to compile. If it is a bug I would be happy to open a ticket for it! Could somebody please confirm? Thank you, Dmitry

3 5

[exception] What's wrong with boost::get_error_info?
by Markus Schweiß 03 Jun '09

03 Jun '09

Dear boost community, I'm really new to using the boost library. Whatever, the first part I want to use is boost::exception. But already there start my problems: I'm using 'boost::get_error_info<boost::throw_file>( myBoostException )' to retrieve the file name where my exception was thrown. The problem is that the returned 'const char*' pointer contains several wild characters at its end. It seems that the null-termination get lost somehow, somewhere. The same is with 'boost::throw_function' and the string returned by 'boost::diagnostic_information( myBoostException )'! For example, that is what I get from boost::diagnostic_information: ".\myFile.cppÍýýýý««««««««îþ(134): Throw in function MyClass::DoSomething()ÍÍÍÍÍÍ^ñ6 Dynamic exception type: class MyBoostException" That's really strange because the strings are correctly stored to the boost::exception class attributes 'throw_function_' and 'throw_file_'. So what do I wrong??? I would be so thankful when anyone could help me! Following some detailed information: - plattfrom: Windows XP SP3 - compiler: MS VC++ 8 - character set: multi-byte - boost version: Release 1.37.0 code snippet for throwing my exception: throw MyBoostException() << boost::throw_file( __FILE__ ) << boost::throw_line( __LINE__ ) << boost::throw_function( "MyClass::DoSomething()" ); code snippet for catching my exception: catch( MyBoostException& myBoostException ) { std::string info = boost::diagnostic_information( myBoostException ); const char* string = info.c_str(); } My best regards, Markus

2 5

Boost.Process article: Tutorial and request for comments
by Boris Schaeling 01 Jun '09

01 Jun '09

I've written an article about Boost.Process: http://www.highscore.de/cpp/process/ I've also fixed a few bugs in Boost.Process (which is now 0.31): http://www.highscore.de/boost/process.zip And the latest source code can also be found in the sandbox: https://svn.boost.org/svn/boost/sandbox/process/ For developers not familar with Boost.Process the article is a tutorial to get more easily started. For developers familiar with Boost.Process it is a request for comments. I've been looking at the big picture finally trying to find out where and how Boost.Process should be changed and in which direction it should move to become a complete library one day. As not everyone will read the entire article here are my thoughts: 1) Boost.Process is based on a few concepts like 'process' and 'context'. While those make sense there are other concepts where I wonder if they should be dropped: * 'executable' is the executable name which in practice must be a std::string. I think the original idea was to support numerous string types. This leads to the question how to support different Unicode encodings which I think is still unanswered in the Boost community. Other libraries, eg. Boost.Interprocess, simply stick to one string type (typically std::string). * 'handle' is the underlying native file handle of a stream (file descriptor on POSIX systems, handle on Windows). The concept is based on a class in the detail namespace of Boost.Process. There is just one class and it's not meant to be used by users of the library either. Thus I'm not sure what's the benefit of having an explicit 'handle' concept at all. 2) Environment variables must be sorted on Windows but not on POSIX systems. On Windows the type environment could be a typedef for std::map and on POSIX systems for std::unordered_map. Currently it's always a typedef for std::map. Is that ok? Should it be changed? Should a macro be provided in case developers want to use different typedefs? 3) Currently Boost.Process is really only useful for creating child processes. It's not possible for example to detect and iterate over other processes on a system. I guess Boost.Process should be enhanced here. Then one day the well-known utility 'ps' on POSIX systems could be implemented in Boost C++. Any comments? 4) When a process is created the standard streams (stdin, stdout and stderr) are closed by default. Is this a good choice? If it isn't what should happen otherwise? Inherting standard streams (which is the default behavior with fork on POSIX systems)? 5) Boost.Process requires to specify an absolute path to an executable which should be started. There is a helper function which returns the absolute path for an executable name (it uses the environment variable PATH). The question is if this should be done automatically if no absolute path is given? 6) When a stream of a child process is captured Boost.Process automatically creates a pipe. As pipes don't support asynchronous operations on Windows a named pipe is required (called FIFO on POSIX systems). Currently a macro must be defined to make Boost.Process use a named pipe on Windows. It might make more sense to enable developers to choose either a pipe or a FIFO explicitly - not only on Windows but on all platforms. Any comments? 7) It's possible to capture and access streams of a child process. Those streams are derived from std::istream and std::ostream and thus only support blocking I/O operations. Currently the underlying handle has to be fetched to initialize a generic I/O object from Boost.Asio to use asynchronous I/O operations. How should the library be changed to make it easier to use asynchronous I/O? 8) There is a method wait() which makes it possible to wait for another process to exit. Currently wait() is provided by the class child though. Shouldn't it really be defined by the class process (so you can wait not only for child processes to exit)? 9) As wait() blocks an asynchronous alternative should be provided. 10) The Windows-specific classes all start with win32_ (eg. win32_child). Wouldn't it make more sense to use windows_ instead (like windows_child) or a windows namespace? First other libraries use windows_ (see Boost.Interprocess). Second there should be no reason why a class like win32_child can't be used on a 64-bit Windows. Boris

4 5

indirect_iterator,symmetric_matrix and ptr_vector
by Archie14 01 Jun '09

01 Jun '09

Following test fails to compile. Errors start with the first call to make_indirect_iterator. On the first glace on the error output it looks that indirect_iterators cannot be used together with ptr_vector and matrix. Is that correct? If I need to calculate the sum of all matrices in a vector - what is the right way to do it? void test() { typedef symmetric_matrix<double, lower> matrixofdoubles; boost::ptr_vector<matrixofdoubles> lst; boost::make_indirect_iterator(lst.begin()); // testing ind.iter. matrixofdoubles totalsum (10); std::accumulate( boost::make_indirect_iterator(lst.begin()), boost::make_indirect_iterator(lst.end()), totalsum, std::plus<matrixofdoubles>()); } Errors are: c:\Libraries\boost\boost_1_39_0\boost/pointee.hpp(30) : error C2039: 'element_type' : is not a member of 'boost::numeric::ublas::symmetric_matrix<T,TRI>' with [ T=double, TRI=boost::numeric::ublas::lower ] c:\Libraries\boost\boost_1_39_0\boost/mpl/eval_if.hpp(41) : see reference to class template instantiation 'boost::detail::smart_ptr_pointee<P>' being compiled with [ P=boost::numeric::ublas::symmetric_matrix<double,boost::numeric::ublas::lower> ] c:\Libraries\boost\boost_1_39_0\boost/pointee.hpp(69) : see reference to class template instantiation 'boost::mpl::eval_if<C,F1,F2>' being compiled with [ C=boost::detail::is_incrementable<boost::numeric::ublas::symmetric_matrix<doubl e,boost::numeric::ublas::lower>>, F1=boost::detail::iterator_pointee<boost::numeric::ublas::symmetric_matrix<doub le,boost::numeric::ublas::lower>>, .. etc.

2 1

google.stringencoders vs (boost.string_algo & boost.lexical_cast)
by Roman Shmelev 01 Jun '09

01 Jun '09

Hi! stringencoders are told to be 2x faster than std approaches. But what about boost? Has somebody tested the performance of both libraries? I mean toLower, toUpper, itoa, dtoa functions. Thank you

4 3

multi_array_ref (lack of) default constructor
by gtsml owevwr 01 Jun '09

01 Jun '09

Hi, Does anybody know why multi_array_ref doesn't have a default constructor? I'm asking because I wanted to make a multi_array of multi_array_ref and that doesn't seem to be possible because multi_array expect the element type to be default constructible. Thanks, Frank

3 6

Re: [Boost-users] boost::serialization and PHP websites
by Brian Wood 01 Jun '09

01 Jun '09

Pascal Kesseli writes: > Currently, I consider the > boost serialization a de-facto standard for C++ serialization issues. In 2007 it wasn't a stretch to say that General Motors was a de facto standard in the automobile industry. Now they want 70 billion from taxpayers. Oh my G-d! -- Brian Wood Ebenezer Enterprises www.webEbenezer.net "Then Samuel took a rock and set it up between Mizpah and Shen. He named it Ebenezer [Rock of Help] and said, 'Until now the L-RD has helped us.'"

5 15

Vector types in dynamic_properties used by write_graphml
by Richard Vock 31 May '09

31 May '09

He Folks, I'm using bundled properties in order to attach multiple attributes to graph nodes. Using only basic data types like integers, strings etc. the following example code works well. However I would like to also use vectors or similar containers (like in the example about bundled properties at http://www.boost.org/doc/libs/1_39_0/libs/graph/doc/bundles.html) However I don't know how to use this field for my dynamic_property map. In the following code the single commented-out line is the point where I most probably didn't understand some kind of vital concept. Maybe you could enlighten me or at least point me in the right direction, thanks in advance Richard Vock --- Here's the example code: #include <iostream> #include <boost/graph/adjacency_list.hpp> #include <boost/dynamic_property_map.hpp> #include <boost/graph/graphml.hpp> struct NodeProperties { int test; std::vector<int> ints; }; int main(int argc, char* argv[]) { typedef std::pair<int,int> Edge; std::vector< Edge > connections; // create simple edge loop for testing purposes for (int i=0; i<10; ++i) connections.push_back( Edge(i,(i+1)%10) ); typedef boost::adjacency_list< boost::vecS, boost::vecS, boost::undirectedS, NodeProperties> Graph; Graph g(connections.begin(), connections.end(), 10); boost::graph_traits<Graph>::vertex_iterator v, v_end; for (tie(v,v_end) = vertices(g); v != v_end; ++v) { Graph::vertex_descriptor desc = *v; g[desc].test = 10; for (int i=0; i<5; ++i) g[desc].ints.push_back(i); } boost::dynamic_properties dp; dp.property("test", get(&NodeProperties::test, g)); //dp.property("testInts", get(&NodeProperties::ints, g)); boost::write_graphml(std::cout, g, dp, true); }

1 0