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

Converting epoch(long) to ptime in Boost.Date_Time
by gdprosch＠micron.com 23 Aug '06

23 Aug '06

I would like to convert epoch(long) time values to boost ptime and vice versa. On the surface this seems relatively easy but some of the functions needed are missing and there is an issue ensuring that the local time is properly applied. Has someone come up with an easy way to do this? I can convert to ptime like this... long epoch_in = 1140411002; // 2006-Feb-19 21:50:02 std::time_t stdtime ( epoch_in ); ptime = from_time_t( stdtime ); To convert from ptime back to epoch(long) there is no conversion provided the other way. I found some code the author supplied a few years ago here: http://lists.boost.org/MailArchives/boost-users/msg07254.php Unfortunately, the result does not correctly apply local time. The following code... std::time_t to_time_t(ptime t) { ptime start(gregorian::date(1970,1,1),time_duration(0,0,0)); return (t-start).total_seconds(); } ... produces a date with the value: 2006-Feb-20 04:50:02 and not 2006-Feb-19 21:50:02 (I am in US MST). I've played around with applying the local offset but I end up with a lot of lines of code that leave me wondering if there is a better way. It would be nice if it were simple like this (assuming local time adjustment is correctly applied)... long epoch_in = 1140411002; // 2006-Feb-19 21:50:02 ptime pt = from_epoch( epoch_in ); long epoch_out = to_epoch( pt ); Many thanks, > Greg Prosch > Micron Technology, Inc.

2 1

Building boost for 64-bit on AIX
by Patrik Jonsson 17 Aug '06

17 Aug '06

Hi, I'm trying to build boost (1.32.0) on an IBM SP2 under AIX5, using the 64-bit ABI. This is troublesome. I do: bjam "-sTOOLS=gcc" "-sGXX=g++ -maix64 -pthread" --prefix=$HOME --libdir=$HOME/lib64-gcc --includedir=$HOME/include-gcc install But it doesn't work. I get loads of errors like: gcc-Link-action bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true/libboost_date_time-gcc-d-1_32.so ld: 0711-738 ERROR: Input file bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true/greg_month.o: XCOFF32 object files are not allowed in 64-bit mode. collect2: ld returned 8 exit status set -e LIBPATH=bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true:$LIBPATH export LIBPATH "g++" -maix64 -pthread -g -fPIC -shared -o "bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true/libboost_date_time-gcc-d-1_32.so" "bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true/greg_month.o" "bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true/greg_weekday.o" "bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true/date_generators.o" ...failed gcc-Link-action bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true/libboost_date_time-gcc-d-1_32.so... ...skipped <@boost!lib64-gcc>libboost_date_time-gcc-d-1_32.so for lack of <@boost!libs!date_time!build/libboost_date_time.so/gcc/debug/shared-linkable-true>libboost_date_time-gcc-d-1_32.so... It seems it's using -maix64 ok when trying to build the library, but not when compiling... Can anyone tell me what the proper way of building boost under these conditions are? Thanks, /Patrik Jonsson

5 16

Re: [Boost-users] [boost] [Announce] Boost Installer for Visual C++ 7.1/8.0
by Trent Nelson 05 Jul '06

05 Jul '06

> Boost Consulting is pleased to announce the availability of a Windows > installer for the current Boost release (1.33.1). See: > > http://www.boost-consulting.com/download.html Any plans to make the .nsi file you're using public? There may be a few of us out there that have experience with Nullsoft and could contribute to the installer in some way, shape or form. Trent.

4 4

[Review][PQS] Physical Quantities System review (May 31 through June 9)
by fred bertsch 09 Jun '06

09 Jun '06

The review of Andy Little's Physical Quantities System begins today, May 31, 2006, and continues through June 9, 2006. Download: pqs_3_1_0 is the Official Boost Review version of pqs. (Please note that pqs_3_1_0 has a bug in one header. This can be either patched according to the latest release notes, "relnotes.txt" available from http://tinyurl.com/7m5l8 or alternatively download pqs_3_1_1, which is basically equivalent to pqs_3_1_0, except the bug has been fixed there. Description PQS (Physical Quantities System) is designed to replace the use of floating point types for modelling physical quantities in C++ programs. Advantages include automated dimensional analysis checking, automatic unit conversions, self documentation of code and uniform mechanisms for dealing with physical quantities overall, allowing better interoperability, accuracy and repeatability among engineering, physics and trade applications. The library will ultimately consist of various types for modelling quantities in different situations. The t1_quantity, which is the first to be implemented, performs all its dimensional analysis checks as well as parts of its unit conversion calculations, at compile time rather than runtime, for maximum efficiency. PQS is designed with a firm commitment to the SI system, as being the internationally agreed preferred system of units. A reasonable selection of common quantities and units is included in the review version for demonstration purposes. The intent is to expand on this to include all the common quantities mentioned in Appendix B.8 and B.9 of the NIST SI document: http://physics.nist.gov/cuu/pdf/sp811.pdf The library also defines a selection of physical constants again intended as a flavour of the constants that would be included in a full library implementation as outlined in: http://physics.nist.gov/cuu/pdf/chart1.pdf Review questions: Please always explicitly state in your review, whether you think the library should be accepted into Boost. You might want to comment on the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? -Fred Bertsch

4 4

[statechart ] UML2.0 local transitions and history
by Tim Milward 05 Jun '06

05 Jun '06

I've built a small test program with the statechart library. (See below) It seems that the sequence of exit and entry actions invoked for a transition are modeled according to the UML 1.5 specification. In other words it models "external" transitions from the 2.0 spec. Is it possible, or are there any plans to extend it, to model the more useful local transitions from the 2.0 spec? Tests with deep history produce a static assertion if you attempt to transition to history of a containing state. UML 2.0 explicitly permits this. Are there any plans to modify the library to permit this? Yours, Tim Milward #include <iostream> #include <boost/statechart/event.hpp> #include <boost/statechart/state_machine.hpp> #include <boost/statechart/simple_state.hpp> #include <boost/statechart/transition.hpp> #include <boost/statechart/deep_history.hpp> using namespace std; namespace sc = boost::statechart; struct S0; struct S00; struct Machine : sc::state_machine< Machine, S0 > { Machine() { cout << "Machine()\n"; } ~Machine() { cout << "~Machine()\n"; } }; struct E0 : sc::event< E0 > { E0() { cout << "E0()\n"; } ~E0() { cout << "~E0()\n"; } }; struct E1 : sc::event< E1 > { E1() { cout << "E1()\n"; } ~E1() { cout << "~E1()\n"; } }; struct S0 : sc::simple_state< S0, Machine, S00, sc::has_deep_history > { // this would comile fine // typedef sc::transition<E0, sc::deep_history< S00 > > reactions; // this invokes exit actions of S00 and S0 (an external transition) typedef sc::transition<E0, S00 > reactions; S0() { cout << "S0()\n"; } virtual ~S0() { cout << "~S0()\n"; } }; struct S00 : sc::simple_state< S00, S0 > { // this doesn't compile // typedef sc::transition<E1, sc::deep_history< S00 > > reactions; // this invokes exit actions of S00 only typedef sc::transition<E1, S00 > reactions; S00() { cout << "S00()\n"; } virtual ~S00() { cout << "~S00()\n"; } }; int main() { Machine m; m.initiate(); m.process_event(E0()); m.process_event(E1()); return 1; }

2 8

[BGL] problem with adjacency_list and bidirectional_tag
by Tiago de Paula Peixoto 02 Jun '06

02 Jun '06

Hi. I've noted an apparent discrepancy between the documentation of the adjacency_list class and the actual behavior: It's stated in the documentation that graph_traits<adjacency_list>::directed_category should be a typedef to "directed_tag" or "undirected_tag", depending on whether the graph is directed or not. Those are also the only possible types defined by the Graph concept. But when bidirectionalS is used as the Directed template parameter for adjacency_list, the type of the directed_category is set to "bidirectional_tag". Shouldn't this simply be set to "directed_tag", and the bidirectional information be confined to graph_traits<adjacency_list>::transversal_category? At least that's what the documentation says... I didn't provide a test program, since this can easily be checked in the source code. I'm using boost 1.33.1 and GCC 4.1.0. Thanks. -- Tiago de Paula Peixoto <tiago(a)forked.de>

3 2

When Boost::signals will be thread-safe?
by Tanguy Krotoff 02 Jun '06

02 Jun '06

Hi Boost::signals are not thread-safe http://boost.org/doc/html/signals/s04.html#id2738867 "Boost.Signals will support thread safety in the future." I would like to know when this feature will be implemented, if somebody is working on it. I like very much the fact that Qt slot/signals are thread safe, it helps really a *lot* : "the slot is invoked when control returns to the event loop of the thread to which the object belongs. The slot is executed in the thread where the receiver object lives." http://doc.trolltech.com/4.1/threads.html Do you plan also to make Boost::signals executed in the thread where the receive object lives? Thanks in advance for your answers Regards, -- Tanguy Krotoff <tanguy.krotoff(a)wengo.fr> http://openwengo.org

2 1

Poll: Do you use Spirit 1.6?
by Nicola Musatti 02 Jun '06

02 Jun '06

Hallo, This is a poll I started on the Spirit General mailing list which I'm reposting here as suggested by Joel de Guzman. I apologize to those who already read this message there. I'd be interested to know how many of you are currently using Spirit 1.6.x and with which compilers, to gauge the effort that might be required to take on maintenance of the 1.6 branch. Currently I'm using Spirit 1.6 with Borland's BCB6 and BCB2006, in conjunction with Boost.Serialization. Thank you, Nicola Musatti

6 6

Antwort: Re: [boost.multi_array] Question about iterators on multi_array_views
by bernhard.maeder＠zkb.ch 02 Jun '06

02 Jun '06

Hi Ron Thanks for your fast reply, I'll going to check out your fix as soon as possible. Thanks Bernhard |---------+-----------------------------------> | | Ronald Garcia | | | <garcia(a)cs.indiana.edu> | | | Gesendet von: | | | boost-users-bounces@list| | | s.boost.org | | | | | | | | | 24.05.2006 19:42 | | | Bitte antworten an | | | boost-users | | | | |---------+-----------------------------------> >-----------------------------------------------------------------------------------------------| | | | An: boost-users(a)lists.boost.org | | Kopie: | | Thema: Re: [Boost-users] [boost.multi_array] Question about iterators on | | multi_array_views | >-----------------------------------------------------------------------------------------------| Greetings Bernard, Indeed you have caught a bug in multi_array's view iterators. I have crafted a fix that I will check into CVS whenever Sourceforge is amenable. Thanks for the report. ron On May 24, 2006, at 8:07 AM, bernhard.maeder(a)zkb.ch wrote: > Hello everyone > > I'm trying to use the boost.multi_array's iterators and came across a > problem: calling end() on a certain multi_array_view only yields the > same iterator, if it is called on exactly the same instance of the > view. When, however, the view is created twice (using the same > expression, of course), end() produces an iterator that doesn't > compare to the first one. > > In other words: > m_a[indices[index_range()][1]].end() > != m_a[indices[index_range()][1]].end() > > I'm not sure whether this is just me, trying to use something in a way > it shouldn't be used, or if this is a limitation of the multi_array > library. I'd appreciate your opinion! > _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users ___________________________________________________________________ Disclaimer: Diese Mitteilung ist nur fuer die Empfaengerin / den Empfaenger bestimmt. Fuer den Fall, dass sie von nichtberechtigten Personen empfangen wird, bitten wir diese hoeflich, die Mitteilung an die ZKB zurueckzusenden und anschliessend die Mitteilung mit allen Anhaengen sowie allfaellige Kopien zu vernichten bzw. zu loeschen. Der Gebrauch der Information ist verboten. This message is intended only for the named recipient and may contain confidential or privileged information. If you have received it in error, please advise the sender by return e-mail and delete this message and any attachments. Any unauthorised use or dissemination of this information is strictly prohibited.

2 1

boost::numeric::ublas matrix iterators
by Ed Johnson 01 Jun '06

01 Jun '06

Hi, I read through the Ublas documentation but did not see any examples with the iterator1 and iterator2 being used with a matrix. I am having trouble working with them. Does anyone know how to recreate this example using the iterators? http://www.boost.org/libs/numeric/ublas/doc/matrix.htm int main () { using namespace boost::numeric::ublas; matrix<double> m (3, 3); for (unsigned i = 0; i < m.size1 (); ++ i) for (unsigned j = 0; j < m.size2 (); ++ j) m (i, j) = 3 * i + j; std::cout << m << std::endl; } Many thanks, Ed Johnson

2 4