- Boost - lists.boost.org

OLE Automation date to local_date_time conversion
by Matthew Chambers 25 Jun '09

25 Jun '09

Hello fellow boosters, Under MSVC boost::date_time supports conversion from FILETIME, so it makes sense to also support conversion from the OLE automation date format, helpfully defined at: http://msdn.microsoft.com/en-us/library/system.datetime.fromoadate.aspx > The d parameter is a double-precision floating-point number that > represents a date as the number of days before or after the base date, > midnight, 30 December 1899. The sign and integral part of d encode the > date as a positive or negative day displacement from 30 December 1899, > and the absolute value of the fractional part of d encodes the time of > day as a fraction of a day displacement from midnight. d must be a > value between negative 657435.0 through positive 2958466.0. In fact, I don't see a good reason this function can't be included in a non-MSVC build too since it doesn't depend on the Win32 API in any way. The code to handle this conversion is quite ugly. Here is my code to do it: namespace boost { namespace date_time { //! Create a time object from an OLE automation date value. /*! Create a time object from an OLE automation date value. * The oa_date parameter is a double-precision floating-point number that * represents a date as the number of days before or after the base date, midnight, * 30 December 1899. The sign and integral part of oa_date encode the date as a * positive or negative day displacement from 30 December 1899, and the absolute * value of the fractional part of oa_date encodes the time of day as a fraction of a * day displacement from midnight. oa_date must be a value between * negative 657435.0 through positive 2958466.0. */ template<class time_type> inline time_type time_from_OADATE(double oa_date) { typedef typename time_type::date_type date_type; typedef typename time_type::date_duration_type date_duration_type; typedef typename time_type::time_duration_type time_duration_type; using boost::math::modf; static const date_type base_date(1899, Dec, 30); static const time_type base_time(base_date, time_duration_type(0,0,0)); int dayOffset, hourOffset, minuteOffset, secondOffset; double fraction = fabs(modf(oa_date, &dayOffset)) * 24; // fraction = hours fraction = modf(fraction, &hourOffset) * 60; // fraction = minutes fraction = modf(fraction, &minuteOffset) * 60; // fraction = seconds modf(fraction, &secondOffset); time_type t(base_time); t += time_duration_type(hourOffset, minuteOffset, secondOffset); t += date_duration_type(dayOffset); return t; } } } Here are some basic unit tests: template<typename time_type> void test_time_from_OADATE(std::ostream* os_ = NULL) { typedef typename time_type::date_type date_type; typedef typename time_type::date_duration_type date_duration_type; typedef typename time_type::time_duration_type time_duration_type; using namespace boost::date_time; if (os_) *os_ << "OADATE: 0.0 -> " << time_from_OADATE<time_type>(0.0) << endl; unit_assert(time_from_OADATE<time_type>(0.0) == time_type(date_type(1899, Dec, 30), time_duration_type(0,0,0))); if (os_) *os_ << "OADATE: 1.0 -> " << time_from_OADATE<time_type>(1.0) << endl; unit_assert(time_from_OADATE<time_type>(1.0) == time_type(date_type(1899, Dec, 31), time_duration_type(0,0,0))); if (os_) *os_ << "OADATE: -1.0 -> " << time_from_OADATE<time_type>(-1.0) << endl; unit_assert(time_from_OADATE<time_type>(-1.0) == time_type(date_type(1899, Dec, 29), time_duration_type(0,0,0))); if (os_) *os_ << "OADATE: 2.0 -> " << time_from_OADATE<time_type>(2.0) << endl; unit_assert(time_from_OADATE<time_type>(2.0) == time_type(date_type(1900, Jan, 1), time_duration_type(0,0,0))); if (os_) *os_ << "OADATE: 2.25 -> " << time_from_OADATE<time_type>(2.25) << endl; unit_assert(time_from_OADATE<time_type>(2.25) == time_type(date_type(1900, Jan, 1), time_duration_type(6,0,0))); if (os_) *os_ << "OADATE: -1.25 -> " << time_from_OADATE<time_type>(-1.25) << endl; unit_assert(time_from_OADATE<time_type>(-1.25) == time_type(date_type(1899, Dec, 29), time_duration_type(6,0,0))); } I made it templated because its sibling function in boost\date_time\filetime_functions.hpp is templated, but it seems that ptime is the only stock type that will work. Local_time doesn't have the right constructors, at least. Thoughts? What's the procedure to add this officially to date_time? Thanks, -Matt Chambers

2 1

Random Numbers
by Dima 25 Jun '09

25 Jun '09

Hi all, this is my first post here. As far as I've seen boost provides standard random number generators for each distribution class. So, if you want a normally distributed class, you're automatically using Box-Mueller.... However, there are other ways of generating random numbers, such as using the inverse cumulative distribution function and evaluate it at a uniformly generated random number. It might be good to add this functionality to the library, since basically everything that is needed is there. Questions: Is this already in development? Is this something of interest? I'd be willing to participate somehow if this is not already in progress. Need first step guidance though. Best regards, Dima

2 1

[MultiArray] constness and documentation bugs
by Frank Mori Hess 25 Jun '09

25 Jun '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am able to modify a const multi_array through a multi_array_ref. For example: const boost::multi_array<int, 2> myarray(boost::extents[2][2]); boost::multi_array_ref<int, 2> myarrayref(myarray); myarrayref[0][1] = 2; IMO, trying to create a multi_array_ref from a const multi_array should fail to compile, only a const_multi_array_ref should work. Also, the reference doesn't include the public inheritance between multi_array, multi_array_ref, and const_multi_array in their class synopses. It is important because it seems to be the only reason you can do conversions from multi_array to multi_array_ref or const_multi_array_ref. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpDgtMACgkQ5vihyNWuA4VKgACg4+vF6iDMXKgROj6Wl0/sDDWl bZ8AoMDKVcGSY3SWGcRRvaxG6ik8VsPS =A71z -----END PGP SIGNATURE-----

1 0

Fixed point integer proposal
by Soren Holstebroe 25 Jun '09

25 Jun '09

Hi, Some years ago I wrote a fixed point template for transparent fixed point integer arithmetics and conversion. It worked well and performance was equal to that of native integer types, at least in MS VC++. The template takes a base type and the number of bits reserved for the fraction part and meta-programming works out boundary safe arithmetics and conversions. The template has been used in an image processing library, but lately I used it for seamless conversion of a 4+28 bit fixed point MAD-library decoded mp3-stream to the output buffer of the sound system, with a detour through a float-based sound effect. Would there be public interest in a template like that in the boost library? Soren

6 5

boost::test documentation typo
by Philippe Vaucher 25 Jun '09

25 Jun '09

Hi, The tutorial at http://www.boost.org/doc/libs/1_39_0/libs/test/doc/html/tutorials/new-year-… uingkeeps using BOOST_AUTO_EST_CASE when it obviously should be BOOST_AUTO_TEST_CASE. If no one replies to this mail saying he'll handle it I'll create a ticket on the trac. Philippe

1 0

Re: [boost] version conflicts: is there a solution?
by Artyom 25 Jun '09

25 Jun '09

There are many problems and this is not as simple as you think. Because if you have two versions of foo() defined in header files they may be exported and... collide. See: http://stackoverflow.com/questions/836875/ This problem is much more significant at UNIX platforms where all symbols are exported by default. Think of boost_1.38 boost/foo.hpp namespace boost { int foo() { return 1; } } boost_1.39 boost/foo.hpp namespace boost { int foo() { return 1; } } Now the library includes this header from 1.38 and automatically exports foo outside. Now, you use 1.39 and may get different values of foo(). You may do simple tests and find how bad this is. So... NO You can't use two versions of boost in same project especially at ELF platforms. ...... I just what to remind that there is a script I had written that renames boost namespace and macros preventing namespace collisions of two different versions of Boost. http://lists.boost.org/Archives/boost/2009/05/151816.php So take a look on it, and give feedback, so I would be able to submit it officially to Boost. Artyom > Having the definitions separated into different translation > units doesn't seem > to be enough to prevent ODR violations according to the > standard. It gives a > list of requirements for multiple definitions in different > translation units > in section 3.2.5. >

2 1

Linear circular buffer
by Soren Holstebroe 25 Jun '09

25 Jun '09

Hi, The boost library contains a circular buffer template by Jan Gaspar. It seems well written and STL robust, but I believe the design has some performance shortcomings in many practical usages. Every time I have used a circular buffer it has been to drag a window over a huge or real time dataset. If the dataset is non real-time and small enough to be contained in memory, there is no practical need for a circular buffer, since the window data pointer can just be dragged in memory along the full length of the dataset. In many algorithms using a dragged window, you would need to process the full length of the window for each time the window is moved. E.g. convolving signal data. Thus, you read from the window a lot more than you write. To maximize performance of your window reading and to utilize external libraries, you need linear access to the data. While Gaspar's circular buffer provide a linearize method, it requires a full reorganization of the contained data. This yields an O(N*M) efficiency, just for dragging the window (size N) over the data (size M). For internal use, the circular buffer provides iterators, but each iteration requires an internal buffer check, in order to wrap around the buffer border. Since the nature of a circular buffer in most practical scenarios (at least that I can think of) is to be involved in the processing of large amount of data, read performance is important. If you allow the internal buffer to allocate more memory than the size of the circular buffer, you can reduce the number of times you need to reorganize the internal buffer to make it linear readable. If you allocate N items more than the circular buffer size, you only need to reorganize every N+1 pushes to the window. Thus, allocating additional 100 items will reduce the reorganization overhead to 1%. I have written to Jan Gaspar, who recognizes that the buffer is not efficient for linear use, but he hasn't got the time anymore to add that feature. Is a circular buffer variant with linear access at a low maintenance cost something that would have public interest? Soren

2 1

Boost.Containers? (WAS Re: Proposal: Monotonic Containers - Comparison with boost::pool, boost::fast_pool and TBB)
by Dean Michael Berris 24 Jun '09

24 Jun '09

On Wed, Jun 24, 2009 at 10:40 AM, Christian Schladetsch<christian.schladetsch(a)gmail.com> wrote: > > What do people think of moving boost::interprocess::containers to > boost::containers? These containers are not really specific to interprocess? > I think this can easily be done through 'using' declarations: namespace boost { namespace containers { using boost::interprocess::list; using boost::interprocess::vector; /* ... */ } } I don't think it should move though to support earlier applications that are already using the interprocess namespace for the containers. -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

4 6

[range][rangex] Joining two unrelated ranges?
by Dean Michael Berris 24 Jun '09

24 Jun '09

Hi Guys, I was wondering if a utility that allows the encapsulation (and merging) of two ranges is already part of RangeEx? I was thinking along the lines of: vector<int> a, b; // populate a, populate b auto r = concat(a, b); // concatenates the ranges into a single range set<int> c(begin(r), end(r)); // r looks like a single forward range I'm not sure if this is already supported in Boost.Range and it'd be nice to know if this is already in RangeEx. TIA -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

8 12

boost::compressed_bitset
by Zachary Turner 24 Jun '09

24 Jun '09

I know there's over a zillion bitset implementations, but often times I have found myself in need of a bitset that is efficient (space-wise) at storing millions, billions, or even trillions (no joke) of bits. For this I have developed an in-house class which stores bits in a structure vaguely reminiscent of a "T-Tree" (http://en.wikipedia.org/wiki/T_tree) You can think of it basically as an std::map<boost::uint64_t, boost::uint64_t> where <key, value> represents the *interval* of bits [key, key+value-1]. So it's basically run-length encoded, with logarithmic lookups instead of linear lookups. Obviously the worst case scenario is where bits alternate 10101... throughout the entire bitset, and this structure will be terrible in that case. But where there are frequent runs of 0 and 1 bits, this gives orders of magnitude savings in space. Since a map is sorted on key, it's still a valid binary search tree and one can find the node for the k'th bit by map::lower_bound(k) and quickly check whether the bit is set by testing whether k is in [iter->first , iter->first+iter->second). The most difficult part is insertion / deletion since it involves splitting (or merging) intervals and rebalancing but the complexity is still no worse than that of a normal rebalancing avl tree. I almost exclusively use this structure in a way that interval nodes represent sequences of 1 bits, but it can just as easily be used the other way around, where intervals represent sequences of 0 bits. In fact now that I think about it probably doesn't even matter. Performing bitwise operations on such a structure is very fast. All you need to do is expand / reduce the intervals appropriately. Lookup / assignment is obviously not constant time but of course that is the tradeoff. Forward / reverse iteration is still very fast however as you only need to take the non-constant time hit once on begin(). It is also very fast to iterate only 1 bits or only 0 bits for the same reason, which can be quite slow with normal bitsets. The implementation I currently have is very unsuitable for boost for many reasons, but if there is enough interest I will (slowly) work on adapting this to be more generic / usable by a wider audience, of course with suggestions and input from the community. Zach

6 9