July 2011 - Boost - lists.preview.boost.org

[gsoc] Midterm surveys
by Andrew Sutton 13 Jul '11

13 Jul '11

If you are a GSoC student or mentor, please fill out your midterm evaluation. Yes, students have to fill something out too! No midterm evaluation, no pay. Thanks, Andrew

1 0

[1.47] PDF build of documentation available.
by John Maddock 12 Jul '11

12 Jul '11

The PDF builds of the Boost documentation are now available from: https://sourceforge.net/projects/boost/files/boost-docs/1.47.0/ Note that as ever, only the subset of libraries which use quickbook/boostbook/docbook as their documentation format are included in the build. Regards, John.

1 0

Date_Time previous_weekday() returns the same day
by Klaim - Joël Lamotte 12 Jul '11

12 Jul '11

Hi, We have a bug that seems to comes from boost::date_time::previous_weekday() (probably next_weekday() too) usage in case we want to go from a weekday to another same weekday: #include <iostream>#include <boost/date_time.hpp>#include <boost/date_time/gregorian/gregorian.hpp> int main() { using namespace boost::gregorian; auto today = date( 2011, Jul, 12 ); auto last_tuesday = boost::date_time::previous_weekday( today, greg_weekday(boost::date_time::Tuesday) ); std::cout << today << '\n'; std::cout << last_tuesday; std::cin.ignore(); return 0; } This example runs but return the same date twice instead of giving the tuesday before the given date (that is already a tuesday). Compiled with VS2010SP1 (boost 1.46.1) and GCC4.4(boost 1.44.0 - didn't see the difference in the code) What we first supposed was it will go to the tuesday of the previous week if we already are tuesday. It appears to not work this way. Is it the wanted behaviour? If it is, I suggest the documentation to be enhanced to warn the user about the case when you provide a date that is the same provided weekday. The code of boost::date_time::previous_weekday() (as far as I understand it) suggests that it should go to the previous week's weekday instead of returning the same day: template<class date_type, class weekday_type> inline date_type previous_weekday(const date_type& d, const weekday_type& wd) { return d - days_before_weekday(d, wd); } and then : template<typename date_type, class weekday_type> inline typename date_type::duration_type days_before_weekday(const date_type& d, const weekday_type& wd) { typedef typename date_type::duration_type duration_type; duration_type wks(0); duration_type dd(wd.as_number() - d.day_of_week().as_number()); // 1 if(dd.days() > 0){ // 2 wks = duration_type(7); } // we want a number of days, not an offset. The value returned must // be zero or larger. return (-dd + wks); // 3 } Correct me if I'm wrong : 2. checks if the generated day is the same weekday than the provided one, right? So if I'm correct, there might be a problem in 1 or 3? Thanks for your time. Joël Lamotte

1 0

[btree] In-memory B-tree experimental work
by Beman Dawes 12 Jul '11

12 Jul '11

There was quite a bit of speculation at BoostCon about the performance of an in-memory B-tree based ordered associative container. I've done enough experimental work to report some real numbers for an in-memory B-tree map implementation vs std::map: inserting 10000000 elements... btree: 1985589.4 per sec, 81.7% faster than stl stl: 1092714.3 per sec, 45.0% slower than btree iterating over 6321389 elements... btree: 588200694.1 per sec, 2323.5% faster than stl stl: 24270489.8 per sec, 95.9% slower than btree finding 10000000 elements... btree: 2468384.9 per sec, 109.3% faster than stl stl: 1179177.8 per sec, 52.2% slower than btree erasing 10000000 elements... btree: 2444250.3 per sec, 150.7% faster than stl stl: 974793.1 per sec, 60.1% slower than btree Those timings are a simple map<long, int>, and are probably about the best case for the B-tree implementation. In a similar test of a map<char*, int>, i.e. an indirect map using pointers to strings containing the key, the memory B-tree was only slightly faster than the STL. A typical red-black container has an overhead of something like 3 pointers per node, IIRC, so memory use for the B-tree container is presumably a lot less that the STL container, even if the B-tree container has not been packed. Unlike the disk-resident B-tree implementation, the in-memory tree is much closer to the STL interface. The only significant differences are that insert/emplace/erase always invalidates iterators and Key must be Assignable, not just CopyConstructible. The code can be viewed or downloaded at https://github.com/Beman/memory-btree It is currently C++0x only, and tested only with VC++ 10 and GCC 4.6. Since this is the first time I've used move semantics, I may not be getting full mileage out of r-value references yet. There is no documentation yet. I need to set this work aside for awhile to get on with other projects. But I thought there might be interest in the timings. It would also be interesting to push the same set of random numbers into a std::vector, sort it, then run find, iterate, and erase, then look at those timings. --Beman

1 0

identification versus demangle
by Gordon Woodhull 12 Jul '11

12 Jul '11

Hi all, I want to print and visualize MPL.Graph (and thus MSM) metadata. I'm debating whether to help "Make boost::units::detail::demangle an official utility function" [1] (actually the public function is peacefully called simplify_typename) or to use Joel Falcou's Identification library [2]. It would be annoying to users to have to register every type in their graph/state machine, so I guess I'm wondering if demangle(typeid(T).typename()) is impossible on a lot of compilers. Anyone know this? Thanks, Gordon [1] https://svn.boost.org/trac/boost/ticket/4876 [2] https://github.com/boost-vault/Miscellaneous/blob/master/identification-v0.…

3 4

[test] [iostreams] 1.47.0 VC++ 10.0 warnings
by Beman Dawes 12 Jul '11

12 Jul '11

A build of 1.47.0 using VC++10.0 is producing warnings from only a few libraries. It would be great if these were cleared so that this popular compiler builds Boost without warnings at the default settings. Thanks, --Beman boost\test\impl\execution_monitor.ipp(1078) : warning C4702: unreachable code boost\test\impl\execution_monitor.ipp(1082) : warning C4702: unreachable code boost\test\utils\named_params.hpp(74) : warning C4702: unreachable code boost\test\utils\named_params.hpp(78) : warning C4702: unreachable code boost\test\utils\named_params.hpp(86) : warning C4702: unreachable code libs\iostreams\src\file_descriptor.cpp(241) : warning C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning) libs\iostreams\src\file_descriptor.cpp(265) : warning C4244: 'argument' : conversion from 'std::streamsize' to 'DWORD', possible loss of data libs\iostreams\src\file_descriptor.cpp(281) : warning C4244: 'argument' : conversion from 'std::streamsize' to 'DWORD', possible loss of data libs\iostreams\src\mapped_file.cpp(325) : warning C4244: 'argument' : conversion from 'boost::iostreams::stream_offset' to 'SIZE_T', possible loss of data libs\iostreams\src\mapped_file.cpp(59) : warning C4244: 'return' : conversion from 'const boost::iostreams::stream_offset' to 'size_t', possible loss of data

4 6

Re: [boost] [1.47.0] Release candidate files available
by Edward Rankin 12 Jul '11

12 Jul '11

Hi, On Mon, Jul 11, 2011 at 11:59 AM, <boost-request(a)lists.boost.org> wrote: > ---------- Forwarded message ---------- > From: Beman Dawes <bdawes(a)acm.org> > To: Boost Developers List <boost(a)lists.boost.org> > Date: Sun, 10 Jul 2011 17:57:31 -0400 > Subject: [boost] [1.47.0] Release candidate files available > Release candidate files for 1.47.0 are available at > http://boost.cowic.de/rc/ > > As always, the release managers would appreciate it if you download > the candidate of your choice and give building it a try. Please report > both success and failure, and anything else that is noteworthy. > > This helps ensure the candidates build OK before we push them out to > SourceForge. > > Thanks, > > --The release managers > > I compiled using VS 2010 SP1 with Intel Composer XE 2011 Update 4. Two things to note: This error described in the bug ticket I filed previously for 1.46.1 is still there: https://svn.boost.org/trac/boost/ticket/5305 This bug is about the fact that b2/bjam tries to call iclvars.bat in the wrong directory for the XE 2011 versions. Intel moved the file when releasing XE 2011. This error described in the following bug ticket for boost.property_tree is still there: https://svn.boost.org/trac/boost/ticket/5307 A workaround for VS 2010 was required due to a bug in the std::pair. Since the Intel Compiler uses the same C++ Runtime library, it needs this workaround too. Thanks, Edward

1 0

More Boostcon videos available
by Marshall Clow 12 Jul '11

12 Jul '11

Steven's talk on Boost.Units: http://blip.tv/boostcon/boost-units-5364809 Chris' talk: Are You Ready for IPv6? http://blip.tv/boostcon/are-you-ready-for-ipv6-5364812 Matias's talk: Generic Conversion and Segmentation for Ranges: a Solution for Unicode http://blip.tv/boostcon/generic-conversion-and-segmentation-for-ranges-a-so… Boris's talk: Creating Boost.Asio extensions http://blip.tv/boostcon/creating-boost-asio-extensions-5364822 (The Other) Boris talks about: Object-relational mapping with ODB and Boost http://blip.tv/boostcon/object-relational-mapping-with-odb-and-boost-5364825 The rest later this week. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

1 0

[serialization] VC++ compiler warnings
by Beman Dawes 12 Jul '11

12 Jul '11

A 1.47.0 VC++ 10.0 build of Boost produced a lot of stupid warnings from Serialization in the form c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\xutility(2227) : warning C4996: 'std::_Copy_impl': Function call with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators' These can be shut off various ways, such as sticking "#include <boost/config/warning_disable.hpp>" at the start of the file being compiled. If we could get rid of these serialization warnings, that leaves only a handful of VC++ warnings from other libraries. And those look trivial to fix, so I'll pester those folks too. It would be great if Boost default build produced no warnings for this popular compiler. Thanks, --Beman

4 6

[1.47.0] Release candidate files available
by Beman Dawes 11 Jul '11

11 Jul '11

Release candidate files for 1.47.0 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --The release managers

8 12