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

How to build boost on aix with vacpp ?
by Parmentier Jean-Luc (DBB) 29 Sep '06

29 Sep '06

Hi, I want to use boost on ibm-aix with VisualAge C++ Professional / C for AIX Compiler, Version 6 To do this: - I downloaded the version 1.33.1 of boost on sourceforge - I used the following configure statement to build the makefile configure --with-toolset=vacpp - I launched the make statement to build the libraries. But I encountered the following message during make process xlc-C++-action bin/boost/libs/regex/build/libboost_regex.so/vacpp/debug/cregex.o "/TST/FIED/murex/flex/… [View More]

6 5

Including boost headers with MPL OSS project?
by Moritz Moeller 29 Sep '06

29 Sep '06

Hey, we like to use some of the smart pointer stuff in Liquid (liquidmaya.sf.net) However, we like to avoid a boost dependency as that stuff is just headers. We were thus wondering if there were any problems if we included the resp. headers with the Liquid source. Liquid is released under the MPL. Rather surprisingly, none of us liquid developers has a background in law. :> Hence we are unsure if the boost license permits distributing the headers. I guess if we added the boost license … [View More]

4 5

BOOST_AUTO_UNIT_TEST and command-line options
by Rob Caldecott 29 Sep '06

29 Sep '06

I have a test program that uses the BOOST_AUTO_UNIT_TEST macro (in conjunction with BOOST_AUTO_TEST_MAIN), which has been working well. However, I now need to pass some options to my test program on the command-line and the only way I can see to do this is to drop BOOST_AUTO_TEST_MAIN, add the init_unit_test_suite function and register all my tests "by hand". Is there any way to process my command-line options without losing the AUTO functionality? Thanks in advance.

2 3

Cannot connect to boost repository via TortoiseSVN client
by alexmark 29 Sep '06

29 Sep '06

Hi! What is the actual URL of main boost repository? I need read-only access. Thanks.

5 4

boost message passing
by Levent Yilmaz 29 Sep '06

29 Sep '06

Hi Boosters! In this post I just wanted to throw in my two cents about the newly accepted MPI library, from a luser's point of view. (doc: http://tinyurl.com/fjc9x) It was a great excitement to see the news on boost.org "Message Passing Review Begins"! The C bindings of MPI are a great pain to use -- a fact which is mostly denied by programmers who are unaware of C++'s beauty and content with even good old F77 most of the time. And, as it has been pointed out by Boost.MPI developers, the C+… [View More]+ bindings of standard MPI, though an improvement, are nothing more than simple wrappers on top of the C bindings. Moreover, certain supercomputing centers do not even have these C++ bindings of MPI installed on their otherwise state-of-the-art clusters. So, anyway, it was great to hear that finally MPI will be *boost*ed. There is a lot to what is good about this new boost library. For one, quoting Jeremy: "One particularly nice aspect of Boost.MPI is the way it leverages the Boost serialization library". This indeed appears to be a greatly elegant way to message-pass user types around. There are other features to applaud, such as reduce() via arbitrary functors. Yet, in this post, with the intent of providing constructive criticism, I'd like to point out several design issues related to the user interface; mostly in comparison with other MPI implementations. (hereafter the discussion will assume specific knowledge about MPI) Here is a brief outline of what I'll be talking about, somewhat in the order of importance: 1. Port object 2. Message object 3. Skeleton and content questions 4. MPI-2 bindings *Port Object* Those of you who have actively programmed with MPI certainly have used or at least heard of the OOMPI library (I believe Doug Gregor, one of the two developers of Boost.MPI, is affiliated with the institution OOMPI was born). Its web page, http://www.osl.iu.edu/research/oompi/ , greets you with random (mostly funny) messages, such as "OOMPI- Isn't it time you did something for YOU?" :) Anyway, it was thanks to OOMPI library that I realized that in fact MPI programming could be fun! Especially, there is this *OOMPI_Port* abstraction that literally _enlighten_s the way point-to-point (PTP) and rooted-collective (RC) operations are made. Let's contrast the way PTP is carried out for the three interfaces (Standard MPI, Boost.MPI and OOMPI): //================================================\\ // Standard way int rank; MPI_Comm_rank(MPI_COMM_WORLD, &rank); int msg; int msg_tag = 10; if (rank == 0) { msg = 17; MPI_Send(&msg, 1, MPI_INT, 1, msg_tag, MPI_COMM_WORLD); // (synopsis: http://tinyurl.com/ejmgg ) } elseif (rank==1) { MPI_Recv(&msg, 1, MPI_INT, 0, msg_tag, MPI_COMM_WORLD, MPI_STATUS_IGNORE); // (synopsis: http://tinyurl.com/elkez ) } // Boost.MPI way mpi::communicator world; int msg; int msg_tag = 10; if (world.rank() == 0) { msg = 17; world.send(1, msg_tag, msg); } elseif (world.rank() == 1) { world.recv(0, msg_tag, msg); } // OOMPI way OOMPI_Comm_world& world = OOMPI_COMM_WORLD; world.Init(argc,argv); int msg; int msg_tag = 10; OOMPI_Port to (world[1]); OOMPI_Port from (world[0]); if (world.Rank() == from.Rank()) { msg = 17; to.Send(msg,msg_tag); } else if (world.Rank() == to.Rank()) { from.Recv(msg,msg_tag); } //============================================= The standard C provides global functions for this simplest and most commonly employed Send/Recv commands. These functions require a long list of arguments, which are usually a pain to keep track of (here is another P2P command which is really harsh http://tinyurl.com/mk6dq) Also, such an interface does not provide any conceptual description of what is going on. The design of MPI is indeed mostly object oriented (http://tinyurl.com/qm9hd) however the implementation doesn't realize this fact. Boost.MPI improves two aspects of this: For one the P2P commands are member functions of the communicator (same as the standard C++ bindings); and two, the message's type is templated and the user does not have to repeatedly specify what she is sending. But, as in C-version, one still has to realize the points (P's in P2P) of communication as a bunch of integer values rather than, well, the points of communication, which are an entities by themselves. OOMPI takes this one step further and things kind of fit in place with the whole framework of MPI's design: The points of communication are objects themselves, abstracted as OOMPI_Port class. P2P functions are member functions of OOMPI_Port and OOMPI_Port is in turn a certain piece of a given communicator. Here is how an RC communication looks like: //============================================= // Root-collective communication with OOMPI. // The message will be created at the 4th process and //+ will be broadcasted to everyone in the world communicator. OOMPI_Port root = world[4]; root.Bcast(msg); // or if the Port will not be used for anything else, it is //+ possible to create a temporary: world[4].Bcast(msg); // Here is how this is with Boost.MPI broadcast(world, msg, 4); //============================================= Clearly the OOMPI version is more instructive of the communication process. A more elaborate illustration can be given in the context of communication topologies (a feature that is not yet available in Boost.MPI, unless I am mistaken). For instance: //============================================= // Create a cartesian virtual topology enum {X,Y,NDIM}; int shape[NDIM] = {3,2}; // requires world.size() >= 6; bool is_periodic[] = {true,true}; OOMPI_Cart_comm grid(world,NDIM,shape,is_periodic); // Get nodes of subsequent P2P communication OOMPI_Port left = grid[grid.Shift(X,-1)]; // left neighbor OOMPI_Port right = grid[grid.Shift(X, 1)]; // right neighbor // get cartesian coordinates int mycoords[NDIM]; grid.Coords(mycoords); // create a message int msg = grid.Rank(); // P2P communicate left.Send(msg); // send to left right.Recv(msg); // recv from right //================================================ I wonder why this Port abstraction (or a similar idea) couldn't make its way to Boost.MPI? Is there an underlying design decision to this? Also, why the P2P commands are members of the communicator class but RC commands such as broadcast and gather are global? *Message object* A message in MPI is created by specifiying a data type, data count, data address and finally a message tag. Note the C interface of passing a message in a P2P communication (see first example above). The 4 out of 6 arguments in MPI_Send() is just to specify the message. And for every communication statement of the same kind, this list should be repeated. Boost.MPI (ignoring the skeleton/content idea for a second) reduces this to three arguments (http://tinyurl.com/k2w7q) Reference to the data (from which the type is deduced), data count and the message tag. However, this message is still not a separate entity; and all this information is repeatedly specified as arguments to communication functions. OOMPI provides the convenience of OOMPI_Message object, which is then used in communications. For instance, to pass an array of integers: //============================================= int size = 5; int arr[size]; OOMPI_Tag msg_tag = 10; OOMPI_Message msg(arr1,size,msg_tag); if (world.Rank() == root.Rank()) /* fill up the arr */; root.Bcast(msg); //============================================= *Skeleton and Content - Separating structure from content* Boost.MPI provides this promising functionality which not only simplifies message specifications during communication calls but also helps to easily create more complex data types. But as admittedly a naive user, I am not so sure if this won't actually degrade the performance, or why is this even necessary at all. For instance, let's examine the example given here (http://tinyurl.com/mgwkt) A plain C implementation of the same thing would be something like this: //=================================================== int root = 0; // Create the message type (this section of the //+ code is run by ALL processes in the communicator). int list_len = 10; // size of the message std::list<int> mylist(list_len); std::vector<int*> data_locations(list_len); std::vector<int > block_lengths(list_len,1); using boost::lambda::_1; std::transform( mylist.begin(), mylist.end(), data_locations.begin(), &_1); MPI_Datatype msg_type; MPI_Type_hindexed(list_len, &block_lengths[0], reinterpret_cast<MPI_Aint*>(&data_locations[0]), MPI_INT, &msg_type); MPI_Type_commit(&msg_type); // fill with useful data in the master node if (world.Rank() == root ) std::generate(mylist.begin(),mylist.end(),&std::rand); // distribute the data MPI_Bcast(MPI_BOTTOM,1,msg_type,0,MPI_COMM_WORLD); //==================================================== What is happening here is that, initially each process creates in its own address space, a list of some pre-specified size that is equal in every process. Then a local _definition_ of the container is created as a collection of addresses of every element in the list. A type is then associated with this list to be used in subsequent message passing calls. The root node fills up the list in its own memory space with useful data, and via a broadcast call (a rooted-collective call) message-passes the values to other slave processes. The slave processes gathers the received data into their own list, which is specified by the local type that has just been created. As a matter of fact, the slaves might have gathered the whole data into a vector of ints if they so pleased (and this is usually more efficient since underlying MPI implementation already receives the data as a consequtive chunk of values before processing it with the specified MPI_Datatype). Now, Boost.MPI conveniently reduces the data type definition down to a single statement: mpi::skeleton(mylist); But, then the example has this extra broadcasting statement (indeed, the example is such that the skeleton (MPI_Datatype) is created as a temporary): broadcast(world, mpi::skeleton(mylist), 0); Here, I am not so sure why this is useful. The only thing that is common with the master and slave processes' lists is the list_len, which is already assumed to be known by all. The containers live in totally distinct memory spaces and the elements are located at different addresses. So everybody has to call mpi::skeleton(mylist) separately, but not _receive_ it from the master. The actual data is passed by subsequent possibly multiple broadcast calls: mpi::content c = mpi::get_content(l); broadcast(world, c, root); Now, here is the content anything more than MPI_BOTTOM? What extra information does it carry? Is it possible to apply the same skeleton to a different list<int> of same size? Another point, as I indicated before with the C example, is it possible to create skeletons of different containers of the same value_type (say list<int> on master and vector<int>'s on slaves) and pass the contents around without performance penalty? *MPI-2 Bindings* Somewhere in the documentation a reference to MPI-2 bindings has been made (http://tinyurl.com/jhjo8) Including modern MPI-2 bindings are of course an important provision; however as I indicated previously, there are certain supercomputing centers which do not support MPI-2 yet. Does this resctrict the usage of Boost.MPI in anyway? In other words, would my code still compile and link if I avoid the MPI-2 subset of Boost.MPI? To conclude my rather huge post, I was expecting perhaps Boost.MPI to be a *boost*ed OOMPI implementation (for instance OOMPI does have a lot of disturbing issues especially related to user data types), that amplifies the elegant abstractions while incurring minimum performance penalty. A lot of work has been put into the user type manipulations and it is exciting to see the serialization library in such good use. However, with the essentials such as the communication statements, Boost.MPI does not seem to add much on top of the standard MPI C++ bindings. Also, as indicated by the developers themselves, the current implementation supports only a limited subset of MPI 1.1. Yet, IMHO, given this subset doesn't even include the virtual topology creation, it is perhaps a bit too early to have it in boost. Well, thanks for bearing with me this far. I hope I was able to provide useful feedback for this fresh library. - Levent [View Less]

2 1

[BGL] binary heap
by moritz Hilger 29 Sep '06

29 Sep '06

hi, what happend to the binary-heap implementation in the bgl? as i can tell from older posts on the mailinglist there used to be one which was replaced by the relaxed-heap-implementation for performance reasons. nevertheless afaik the theoretical advantage of fibonacci heaps (and, probably, the relaxed heap) does not hold for some real-world problems. any chance of re-integrating alternative heap-structures for comparison reasons? cheers moritz

2 1

Failed building Boost using MinGW
by Andre Tampubolon 29 Sep '06

29 Sep '06

So here's the scenario : - My MinGW directory is C:\mingw (don't put it at the PATH, because of Cygwin) - My Boost directory is C:\mingw\msys\1.0\home\Administrator\boost_1_33_1 So I put the bjam.exe in the Boost directory then invoke : bjam -sMINGW_ROOT_DIRECTORY=c:\mingw\ stage And an error message box "bjam.exe has encountered a problem and needs to close..." appers. Any solution ? --------------------------------- All-new Yahoo! Mail - Fire up a more powerful email and get things done faster.

2 2

create threads from within a class
by Monica Gretzer 29 Sep '06

29 Sep '06

Hi, I want to use boost::thread to create threads that are member functions within a class. In all the examples I have seen, the thread function is defined globally. I explain it with code. The following test code works: // code 1: example program that works ----------------------------------------------- #include <boost/thread/thread.hpp> #include <iostream> using namespace std; void testing() { cout << "I'm a thread." << endl; }… [View More]

5 4

Re: [Boost-users] [serialization] How to serialize an object usingareference to its base class ?
by x y 29 Sep '06

29 Sep '06

#include <string> #include <sstream> #include <iostream> #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/archive/binary_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/serialization/string.hpp> #include <boost/serialization/access.hpp> #include <boost/… [View More]serialization/is_abstract.hpp> #include <boost/serialization/export.hpp> using namespace std; class base_class { friend class boost::serialization::access; public: base_class() : my_string("") { }; base_class(string s) : my_string(s) { }; virtual ~base_class() {}; virtual void foo(void) = 0; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & BOOST_SERIALIZATION_NVP(my_string); } public: string my_string; }; BOOST_IS_ABSTRACT(base_class); BOOST_CLASS_EXPORT(base_class); class derived_class : public base_class { friend class boost::serialization::access; public: derived_class() : base_class(), my_int(0) {}; derived_class(string s, int i) : base_class(s), my_int(i) {}; virtual ~derived_class() {}; void foo(void) {}; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(base_class) & BOOST_SERIALIZATION_NVP(my_int); } int my_int; }; BOOST_CLASS_EXPORT(derived_class); void serialize(const base_class* src, std::ostream& dest) { // boost::archive::xml_oarchive oa(dest); boost::archive::binary_oarchive oa(dest); oa << BOOST_SERIALIZATION_NVP(src); } int main(int argc, char** argv) { try { stringstream ss; derived_class d("aaa", 5); cout << "before: " << d.my_string << " " << d.my_int << endl; serialize(&d, ss); derived_class d2; // boost::archive::xml_iarchive ia(ss); boost::archive::binary_iarchive ia(ss); ia >> BOOST_SERIALIZATION_NVP(d2); cout << "after: " << d2.my_string << " " << d2.my_int << endl; } catch (const std::exception& ex) { cout << "std exception: " << ex.what() << endl; } catch (...) { cout << "unknown exception" << endl; } return 0; } ----- Original Message ---- From: Robert Ramey <ramey(a)rrsd.com> To: boost-users(a)lists.boost.org Sent: Thursday, September 28, 2006 3:12:45 PM Subject: Re: [Boost-users] [serialization] How to serialize an object usingareference to its base class ? Without seeing your program I couldn't suggest much. Robert Ramey "x y" <nosferatu_1_1(a)yahoo.com> wrote in message news:20060928094242.89373.qmail@web31010.mail.mud.yahoo.com... It works now, but only with XML archives. When I serialize into a binary archive I get a std::exception "bad alloc exception thrown". I forgot to mention that I'm working with Borland C++ Builder 6, boost 1_33_0 I also tried with gcc 3.2.3 on linux with boost 1_33_1 and it also works only with xml archives. With binary archive I get a "basic_string::resize" exception. Robert Ramey <ramey(a)rrsd.com> wrote: This works for pointers - not references. - the following - along with compatible changes - should work. Robert Ramey void serialize(const base_class * src, std::ostream& dest) { boost::archive::binary_oarchive oa(dest); oa << BOOST_SERIALIZATION_NVP(src); } "x y" <nosferatu_1_1(a)yahoo.com> wrote in message news:20060927081505.10666.qmail@web31012.mail.mud.yahoo.com... Hi, I'm new to boost and I'm having some trouble serializing an object using a reference to its base class. Although there are a lot of messages related to this topic in the newsgroups and the doc, I did not find a workable answer to my proplem. In the following code, the function serialize takes a reference to base_class as parameter. But the serialize method of derived_class is never called. Did I miss something ? Thanks for your help Marc #include <string> #include <sstream> #include <iostream> #include <boost/archive/binary_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> #include <boost/serialization/string.hpp> #include <boost/serialization/access.hpp> #include <boost/serialization/is_abstract.hpp> #include <boost/serialization/export.hpp> using namespace std; class base_class { friend class boost::serialization::access; public: base_class() : my_string("") { }; base_class(string s) : my_string(s) { }; virtual ~base_class() {}; virtual void foo(void) = 0; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & BOOST_SERIALIZATION_NVP(my_string); } public: string my_string; }; BOOST_IS_ABSTRACT(base_class); BOOST_CLASS_EXPORT(base_class); class derived_class : public base_class { friend class boost::serialization::access; public: derived_class() : base_class(), my_int(0) {}; derived_class(string s, int i) : base_class(s), my_int(i) {}; virtual ~derived_class() {}; void foo(void) {}; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(base_class) & BOOST_SERIALIZATION_NVP(my_int); } int my_int; }; BOOST_CLASS_EXPORT(derived_class); void serialize(const base_class& src, std::ostream& dest) { boost::archive::binary_oarchive oa(dest); oa << BOOST_SERIALIZATION_NVP(src); } int main(int argc, char** argv) { try { std::stringstream ss; derived_class d("aaa", 5); cout << "before: " << d.my_string << " " << d.my_int << endl; serialize(d, ss); // deserialize derived_class d2; boost::archive::binary_iarchive ia(ss); ia >> d2; cout << "after: " << d2.my_string << " " << d2.my_int << endl; } catch (const std::exception& ex) { cout << "std exception: " << ex.what() << endl; } catch (...) { cout << "unknown exception" << endl; } } Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users [View Less]

2 1

[Filesystem] File Rename issue
by Andrei Danaila 28 Sep '06

28 Sep '06

Hi, I have some trouble with a file renaming program i wrote. The program is supposed to recursively traverse a folders in search for a file, and rename the file to the name of the folder. The program, traverses all the folders successfully, but when i try the rename command i get the following compile error "error C2039: current_path is not a member of 'path', see declaration of path. c:\boost\include\boost-1_33_1\boost\filesystem\path.hpp I am aware that the current_path() … [View More]

1 0