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

Re: [Boost-users] posix_time::from_ftime versus DateTime.FromFileTime
by Anders Dalvander 22 May '09

22 May '09

Archie14(a)lists.boost.org wrote: > I will appreciate any help in sorting out following issue: > > There is a value dt of type long. Calling boost::posix::time::from_ftime in > c++ and > DateTime.FromFileTime with that value produce "slightly" different results: > > dt = 128822886020000000 > > c++: "2009-Mar-23 13:30:02" > c#: {3/23/2009 9:30:02 AM} > DateTime.FromFileTimeUtc will probably produce the same results as boost::posix::time::from_ftime. Perhaps DateTime.SpecifyKind are needed as well. Regards, Anders Dalvander

2 1

boost::iterator_property_map causes run-time fatal error in debug mode on VS2008
by Artyom 22 May '09

22 May '09

Dear all, Noticed some strange behaviour in Debug mode today using boost::iterator_property_map. Not sure whether this is a bug so decided to post here. Here is a how property map is instantiated: template< class Graph, class Vertex, class Edge, class VertexIterator, class EdgeIterator > class PathRecorder { typedef typename boost::property_map< typename Graph, boost::vertex_index_t >::type VertexId_PMap; typedef boost::iterator_property_map< typename std::vector< Edge >::iterator, VertexId_PMap, typename Edge, typename Edge & > PredEdgeMap; /// relevant members std::vector< Edge > edges; VertexId_PMap vertex_id; PathRecorder( void ) : /*** some instantiations here ***/ predEdgeMap( edges.begin(), vertex_id ) { } /** @desc Update an entry inside a map ( fatal error happens here ) **/ void put( Vertex target, Edge e ) { boost::put( predEdgeMap, target, e ); } } In Release mode everything works fine but in Debug mode put method causes a fatal error. It fails in property_map.hpp (351): inline R operator[](key_type v) const { return *(iter + get(index, v)) ; } iter seems to be equal to 0... Which is extremely suspicious. Could anyone think whether I am doing something wrong? I can provide more information if this isn't enough. Arty

3 3

[asio] io_service performance
by Rusty Koonce 22 May '09

22 May '09

First, I'm a noob to the mailing list -- you all need a "search" option on the archives... perhaps it's there, but I didn't see it. I gave up on my O(N) search after making it through the last 3 or 4 months of archives. :) My question is rather simple... Is it better to have a single io_service with multiple threads sharing it calling poll()/poll_one(), or have each thread own its own io_service and calling run()? I saw the HTTP example that did the latter -- each thread owned its own io_service and called run(). My worry there would be if one handler takes a long time to execute it essentially blocks all others behind it. But it seems a single io_service with multiple threads calling poll() or poll_one() would prevent one expensive handler from holding up processing of others behind it (but there could be much more contention on the handler queue). Without a better understanding of the underlying architecture, I'm not sure which way would yield the best performance as traffic scales up on the server. Thanks! -Rusty

2 1

bootstrap.sh questions (compiling v1.39)
by Raymond Wan 22 May '09

22 May '09

Hi all, I'm hadn't been following the development of Boost's installation process and just went from 1.38 to 1.39 and realized the steps that I had written down no longer work. :-) I'm glad that the process was being looked into, but could someone help me with a couple of things? First, I use mpi and use to edit $BOOST/user-config.jam and put "using mpi ;" at the end to get it to compile. I didn't do this and I got a similar warning as before even though I ran: ./bootstrap.sh --with-libraries=graph,mpi,program_options,serialization Does "mpi" in it have no effect? After it finished, it seems the other 3 were made, but not mpi. Should I add "using mpi ;" still? [In $BOOST, I now notice there is no user-config.jam but a project-config.jam.] And the other thing I use to do was to edit the Makefile by adding "--layout=system" so that the generated libraries do not indicate the compiler version. (I did read the discussion earlier this month and I'm now wondering if it's bad practice to do this? I would like libboost_program_options-mt.so instead of libboost_program_options-gcc43-mt.so .) How do I do this with bootstrap.sh/bjam? Thank you! Ray

2 4

scoped_lock
by Space Ship Traveller 22 May '09

22 May '09

I think this is my own fault. I'm debugging some issues with multi-threading and using boost scoped_lock. My code looks like this: { // Enqueue the notification to be processed scoped_lock(m_notifications.lock); m_notifications.sources->push(note); } Am I correct in assuming this is not going to work as expected? The compiler might not even instantiate the lock given this code? I need to write it like this? { // Enqueue the notification to be processed scoped_lock locked(m_notifications.lock); m_notifications.sources->push(note); } Kind regards, Samuel

2 1

Re: [Boost-users] Error (runtime) assigning multi_array to multi_array with smaller dimensions
by Oei, YC 22 May '09

22 May '09

> //at class constructor > boost::multi_array<char, 2> array2d = new boost::multi_array<char, > 2>(boost::extents[x][y]); > //at class method > boost::multi_array<char, 1> array1d = array2d[0]; I tried out those two lines (minus the "new") here (see below), and they compile without complaints in g++ 4.1.2. Yung-Chin -- contents of test file -- #include <iostream> #include <boost/multi_array.hpp> int main() { size_t x = 5; size_t y = 7; boost::multi_array<char, 2> array2d = boost::multi_array<char, 2>(boost::extents[x][y]); std::cout << array2d.num_dimensions() << std::endl; std::cout << array2d[0].num_dimensions() << std::endl; boost::multi_array<char, 1> array1d = array2d[0]; std::cout << array1d.num_dimensions() << std::endl; return 0; } //main

2 3

Example of using posix_time with timezone
by Archie14 21 May '09

21 May '09

This post is related to my discovery of differences in behavior between posix_time::from_ftime and C# DateTime.FromFileTime methods (earlier post) Now I am trying to learn the proper usage of posix_time and time_zones. After reading the documentation I am still confused regarding usage of the timezone together with usage of classes/functions in posix_time namespace Is it possible to do smth.like this: First declare the time zone, like EST, CT ets and then all subsequent calls to posix_time namespace functions or classes will take this timezone as a base? I will really appreciate a simple example of specifying EST timezone for posix_time.

1 0

[multi_array] Looking for elegant way to convert between array and extent_gen objects
by Oei, YC 21 May '09

21 May '09

Dear list members, I've been working with multi_array lately, and am trying to exclusively use boost::arrays as the indexing object when accessing multi_arrays, in order to keep my code dimension-independent. There is a little issue however, in that not all multi_array methods take arrays as parameters; e.g. multi_array::resize() only takes an extent_gen parameter. I've come up with a workaround, which converts an array to the corresponding extent_gen object, and this works.... but it is an ugly amount of code for such a little task. I was hoping I might ask if you have better suggestions? Is there a way to make extents-notation dimension-independent? The content of the header file with my current solution is pasted below to illustrate what I'm trying to achieve - a (somewhat overly trivial) use case is as follows: #include "ArrayToExtentGen.h" [...] boost::multi_array<SomeValueType, SomeNumberOfDimensions> array; [...] boost::array<boost::multi_array_types::index, SomeNumberOfDimensions> position = {{0, 0, 0, 0, 0, 0, 0, 0}}; array.resize(ArrayToExtentGen(position)); [...] Thanks for your thoughts! Yung-Chin -- ArrayToExtentGen.h -- #ifndef GUARD_ArrayToExtentGen_h #define GUARD_ArrayToExtentGen_h #include <boost/array.hpp> #include <boost/multi_array.hpp> namespace YungChin { //! Helper class for ArrayToExtentGen() to recurse through dimensions template < size_t NumDimsIn, size_t NumDimsOut> class ArrayToExtentGenRecurse; //! Convert boost::array (used for addressing on multi_array) into extent_gen template<size_t NumDims> boost::detail::multi_array::extent_gen<NumDims> ArrayToExtentGen( const boost::array<boost::multi_array_types::index, NumDims>& array) { return ArrayToExtentGenRecurse<NumDims, NumDims>::Apply(array); } //ArrayToExtentGen template < size_t NumDimsIn, size_t NumDimsOut> class ArrayToExtentGenRecurse { public: static boost::detail::multi_array::extent_gen<NumDimsOut> Apply( const boost::array<boost::multi_array_types::index, NumDimsIn>& array) { return ArrayToExtentGenRecurse<NumDimsIn, NumDimsOut-1> ::Apply(array)[array[NumDimsOut-1]]; } //Apply }; //ArrayToExtentGen //! Partial specialisation of the above, to stop recursing at 0 dimensions template <size_t NumDimsIn> class ArrayToExtentGenRecurse<NumDimsIn, 0> { public: static boost::detail::multi_array::extent_gen<0> Apply( const boost::array<boost::multi_array_types::index, NumDimsIn>& array) { return boost::detail::multi_array::extent_gen<0>(); } //Apply }; //ArrayToExtentGen } //namespace YungChin #endif

1 0

posix_time::from_ftime versus DateTime.FromFileTime
by Archie14 21 May '09

21 May '09

I will appreciate any help in sorting out following issue: There is a value dt of type long. Calling boost::posix::time::from_ftime in c++ and DateTime.FromFileTime with that value produce "slightly" different results: dt = 128822886020000000 c++: "2009-Mar-23 13:30:02" c#: {3/23/2009 9:30:02 AM} What I am doing wrong? c++ code: typedef signed __int64 int64; int64 dt = 128822886020000000; datetime = boost::posix_time::from_ftime<boost::posix_time::ptime>(dt); std::string testdt = boost::posix_time::to_simple_string(datetime); C# code: Int64 dt = 128822886020000000; startdate = DateTime.FromFileTime(dt);

2 1

Re: [Boost-users] Boost.Unordered throws 64-bit portability warnings
by JOAQUIN M. LOPEZ MUÑOZ 21 May '09

21 May '09

________________________________________ De: boost-users-bounces(a)lists.boost.org [boost-users-bounces(a)lists.boost.org] En nombre de Daniel James [daniel_james(a)fmail.co.uk] Enviado el: jueves, 21 de mayo de 2009 21:36 Para: boost-users(a)lists.boost.org Asunto: Re: [Boost-users] Boost.Unordered throws 64-bit portability warnings 2009/5/21 Dominique Devienne <ddevienne(a)gmail.com>: > > > > FWIW, I'm getting these as well when using > > boost::hash_combine(hash_value(this->member_)); to implement hashes > > for my classes. We also use VS2005 with the compiler switch that > > raises these warnings. My work around below is not pretty... --DD > > > > #if ACME_SIZEOF_SIZE_T == 4 > > // Avoid warning C4267: 'argument' : > > // conversion from 'size_t' to 'unsigned int', possible loss of data > > boost::hash_combine( > > seed, static_cast<unsigned int>(hash_value(member_)) > > ); > > #else > > boost::hash_combine(seed, hash_value(member_)); > > #endif > > Doesn't 'boost::hash_combine(seed, member_)' work? > > I'll have a look at the warning when I get the chance, but AFAICT > they're wrong since when compiling for 64-bit a different overload or > template resolution would be chosen. Is this maybe related to http://lists.boost.org/boost-users/2007/03/26388.php ? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0