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

date_time: convert std::time_t to printable date in local time
by Andreas Ntaflos 01 Oct '06

01 Oct '06

Hello boost-users, I am quite new to Boost and this is my first post to this list. My problem is quite similar to one posted to this list two years ago [1]. Since there don't seem to be any follow-ups to that message I hope to find an answer by posting here. A program of mine reads a Unix timestamp from a database (the field is simply of type NUMERIC(10,0), written to by PHP's time() [2] function) into a `std::time_t time' object, holding the seconds since the epoch, in UTC. No time zone adjustments are applied as far as I understood. I need to convert this time_t to a ptime (or any other kind of printable, readable string) with time zone adjustments applied. Converting with the from_time_t() method works fine, except that the resulting date and time are still in UTC. What would be the most simple way to have the time_t converted to a ptime with local time zone adjustments? The time zone could be any but it would suffice if it is the one the computer running the program is in. I could even hardcode the time zone into the program. Hopefully I made enough sense to have someone knowing help me out. RTFM answers are most welcome, although I have read much of the docs on the date_time library on the Boost homepage. So if possible please point me to the section in the that is relevant to my problem. If this is not possible with Boost are there any other functions I could use, probably from the standard library? Thanks a lot in advance! Andreas [1] Very long Google cache link: http://www.google.com/search?q=cache:s-MYu63Ev8UJ:lists.boost.org/MailArchi… [2] http://www.php.net/manual/en/function.time.php -- Andreas "daff" Ntaflos Vienna, Austria GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4

4 5

lambda boost::array operator[] error
by Levent Yilmaz 30 Sep '06

30 Sep '06

Hi All, Please take a look these two similar set of statements. One uses vector, the other boost::array : /**/ using std::vector; using boost::array; using std::for_each; using boost::lambda::_1; // This one compiles: typedef vector<int> Vector; Vector v(2); vector<Vector> vv(5,v); for_each( vv.begin(), vv.end(), (_1[0]=10, _1[1]=9) ); // This one doesn't: typedef array<int,2> Array; vector<Array> va(5); for_each( va.begin(), va.end(), (_1[0]=10, _1[1]=9) ); /**/ With MSVC 7.1, I get: ===== d:\boost\include\boost-1_33_1\boost\lambda\detail\operator_lambda_func_base.hpp(237): error C2679: binary '=' : no operator found which takes a right-hand operand of type 'const boost::tuples::cons<HT,TT>::stored_head_type' (or there is no acceptable conversion) with [ HT=const boost::lambda::detail::parameter_traits_<const int,const boost::lambda::detail::IF<false,const int &,const int>::RET>::type, TT=boost::tuples::detail::map_tuple_to_cons<boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>::type ] ====================================================== With gcc 3.4.4, I get a moderately sized novel, whose last line reads: ===== /usr/local/include/boost/lambda/detail/operator_lambda_func_base.hpp:136: error: conversion from `int' to non-scalar type `boost::lambda::detail::unspecified' requested ======================================================= This is boost version 1.33.1. What could be wrong? thx

2 1

BoostCon 2007 Call for Proposals
by Beman Dawes 30 Sep '06

30 Sep '06

The first annual Boost conference will take place in Aspen, Colorado, May 14-18, 2007. BoostCon 2007 is looking for session presenters. We invite you to propose a session. For details on how to become a presenter, see www.boost.org/more/BoostCon07_session_call.html This inaugural Boost conference promises to be the main face-to-face venue for all things Boost, from using libraries to writing them, from evangelizing Boost to deployment within your organization, from infrastructure and process to vision and mission, and from TR1 to TR2. Given the range and interests of the participants, the event is going to be intense and in-depth. For more information about the conference, see www.boost.org/more/BoostCon07.html --The Organizing Committee David Abrahams Beman Dawes Jeff Garland Joel de Guzman Kevlin Henney Howard Hinnant Scott Meyers Eric Niebler Sean Parent Rene Rivera Jeremy Siek Matthias Troyer

2 1

Fwd: boost regex library problem with release build
by Maggie Nguyen 30 Sep '06

30 Sep '06

I fixed the problem. For debug: my project setting as: C/C++ > Code Generation > Runtime LIbrary as "Multi-threaded DLL (/MD)" But in my release setting: C/C++ > Code Generation > Runtime LIbrary as "Multi-threaded (/MT)" When I changed it to "Multi-threaded DLL (/MD)", then it works! As indicated in the boost/boost/config/user.hpp, which needs _DLL flag. Thanks, Maggie ---------- Forwarded message ---------- From: maggie.nguyen(a)gmail.com <maggie.nguyen(a)gmail.com> Date: Sep 29, 2006 9:45 AM Subject: boost regex library problem with release build To: Hi, I use Visual Studios 2005. In my project file, I include the library in linker: "Additional Library Directories: ..\..\boost\lib" I have these libs in the boost\lib directory: libboost_date_time-vc80-mt-1_33_1.lib libboost_date_time-vc80-mt-gd-1_33_1.lib libboost_regex-vc80-mt-1_33_1.lib libboost_regex-vc80-mt-gd-1_33_1.lib libboost_thread-vc80-mt-1_33_1.lib libboost_thread-vc80-mt-gd-1_33_1.lib When I build my project as a debug build. it compiles fine. However, if I change to release build, it gives me this error: Error 1 fatal error LNK1104: cannot open file 'libboost_regex-vc80-mt-s-1_33_1.lib' Please let me know what I need to do to have it point to "libboost_regex-vc80-mt-1_33_1.lib" instead of "libboost_regex-vc80-mt-s-1_33_1.lib". Thanks very much, Maggie

2 1

boost regex library problem with release build
by Maggie Nguyen 29 Sep '06

29 Sep '06

Hi, I use Visual Studios 2005. In my project file, I include the library in linker: "Additional Library Directories: ..\..\boost\lib" I have these libs in the boost\lib directory: libboost_date_time-vc80-mt-1_33_1.lib libboost_date_time-vc80-mt-gd-1_33_1.lib libboost_regex-vc80-mt-1_33_1.lib libboost_regex-vc80-mt-gd-1_33_1.lib libboost_thread-vc80-mt-1_33_1.lib libboost_thread-vc80-mt-gd-1_33_1.lib When I build my project as a debug build. it compiles fine. However, if I change to release build, it gives me this error: Error 1 fatal error LNK1104: cannot open file 'libboost_regex-vc80-mt-s-1_33_1.lib' Please let me know what I need to do to have it point to "libboost_regex-vc80-mt-1_33_1.lib" instead of "libboost_regex-vc80-mt-s-1_33_1.lib". Thanks very much, Maggie

1 0

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/boost_1_33_1/boost/regex/v4/regex_traits.hpp", line 80.1: 1540-1269 (S) The template argument for the non-type template parameter of type "bool" must be an integral constant expr ession. "/TST/FIED/murex/flex/boost_1_33_1/boost/regex/v4/regex_traits.hpp", line 159.36: 1540-0700 (I) The previous message was produced while processing "struct boost::re_detail::has_boost_extensions_tag<bo ost::regex_traits<char,boost::cpp_regex_traits<char> >,mpl_::bool_<0> >". xlc -c -I/TST/FIED/murex/flex/boost_1_33_1 -DBOOST_REGEX_CONFIG_INFO=1 -DBOOST_REGEX_DYN_LINK=1 -qNOOPTimize -qnoinline -g -qfullpath -qnotempinc -qfuncsect -qeh -qrtti -I"bin/boost/libs/reg ex/build" -I"/TST/FIED/murex/flex/boost_1_33_1" -o "bin/boost/libs/regex/build/libboost_regex.so/vacpp/debug/cregex.o" "/TST/FIED/murex/flex/boost_1_33_1/libs/regex/build/../src/cregex.cpp" ...failed xlc-C++-action bin/boost/libs/regex/build/libboost_regex.so/vacpp/debug/cregex.o... Any hints for resolving this would be appreciated. Thanks in advance. -------------------------------------- Dexia Bank disclaimer : http://www.dexia.be/maildisclaimer.htm --------------------------------------

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 and stated that those headers lived under that license that might be ok? Or does the license not permit to distribute any part of boost but only the whole shebang? Thanks in advance for any feedback on this! Cheers Moritz -- moritz moeller bloody german td -- moritz.moeller(a)rsp.com.au ---------------------------------------------------------------- rising sun pictures -- www.rsp.com.au ---------------------------------------------------------------- direct line +61 2 9338 6458 mobile ph +61 405 372 249 ---------------------------------------------------------------- adl ph +61 8 8400 6400 -- fx +61 8 8400 6401 level 1, 133 gouger street, adelaide, 5000 ---------------------------------------------------------------- syd ph +61 2 9338 6400 -- fx +61 2 9338 6401 15/16 charles street, redfern, sydney, 2016 ---------------------------------------------------------------- rising sun research -- www.risingsunresearch.com ----------------------------------------------------------------

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++ 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

2 1