December 2010 - Boost - lists.preview.boost.org

[Review] Formal Review of Proposed Boost.Chrono Library Starts TOMORROW
by Anthony Williams 05 Jan '11

05 Jan '11

Hi everyone, The review of Vicente Botet's Chrono library starts TOMORROW (November 6th) and lasts until November 15th unless an extension occurs. What is it? ======== Boost.Chrono aims to implement the new time facilities in C++0x, as proposed in N2661 - A Foundation to Sleep On (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm) That document provides background and motivation for key design decisions and is the source of a good deal of information in this documentation. See the current C++0x working draft at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3126.pdf for details of what was accepted. The Boost.Chrono library provides: * A means to represent time durations: managed by the generic duration class . Examples of time durations include days, minutes, seconds and nanoseconds, which can be represented with a fixed number of clock ticks per unit. All of these units of time duration are united with a generic interface by the duration facility. * A type for representing points in time: time_point. A time_point represents an epoch plus or minus a duration. The library leaves epochs unspecified. A time_point is associated with a clock. * Several clocks, some of which may not be available on a particular platform: system_clock, monotonic_clock and high_resolution_clock. A clock is a pairing of a time_point and duration, and a function which returns a time_point representing now. * To make the timing facilities more generally useful, Boost.Chrono provides a number of additional clocks that are thin wrappers around the operating system's time APIs, thereby allowing the extraction of read (wall clock) time, user CPU time, system CPU time, - process_real_cpu_clock, captures real (wall clock) CPU times. - process_user_cpu_clock, captures user-CPU times. - process_system_cpu_clock, captures system-CPU times. - A tuple-like class __process_cpuclock_, that captures real, user-CPU, and system-CPU times together. - A thread_clock thread monotonic clock, when supported by a platform. * Boost.Chrono also includes typeof registration for duration and time_point to permit using emulated auto with C++03 compilers. * Boost.Chrono also provides I/O for duration and time_point. It builds on <boost/ratio/ratio_io.hpp> to provide readable and flexible formatting and parsing for types in <boost/chrono.hpp>. The duration unit names can be customized through a new facet: duration_punct. Getting the library ============= The latest version of this library may be downloaded from vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=chrono… SVN: http://svn.boost.org/svn/boost/sandbox/chrono Boost.Chrono depends on Boost.Ratio http://www.boostpro.com/vault/index.php?action=downloadfile&filename=ratio.… and optionaly Boost.System Header Only http://www.boostpro.com/vault/index.php?action=downloadfile&filename=system…. and the docs may be viewed here HTML: http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html/index.ht… PDF: http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/chrono.pdf You can get all these information also (which should avoid some long links) from http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Chrono Writing a review ================ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager. Here are some questions you might want to answer in your review: - 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? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Anthony Review Manager for the proposed Boost.Chrono library -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

9 32

compiling Boost boost_1_45_0 regex with icu (redhat).
by Candid Shot 05 Jan '11

05 Jan '11

Greetings. I am trying to compile boost regex with icu. The icu library is placed in a non-standard place, so I have set the appropriate environment variable. However everytime I run bjam, console output (amongst many thing) says - has_icu builds : no I have invoked bjam with -sBOOST_HAS_ICU=1. No luck picking icu. I have invoked bjam with -sICU_PATH=/home/xxx/yyy, and no luck either. OTOH, if I go to the subdirectory : libs/regex/build and do 'make -f gcc.mak' It builds with -DBOOST_HAVE_ICU=1 and with the right icu include directory in the compile line. I am new to compiling boost, and would love to find out what is going on. And how can I rectify it. Thanks, CD.

3 6

[Range] begin/end ADL issues in C++0x range-based for
by Michel MORIN 04 Jan '11

04 Jan '11

[Range] begin/end ADL issues in C++0x range-based for Hi, I recently played around with C++0x range-based for (available on GCC 4.6 Pre-Release). It turned out that some codes using Boost libraries do not compile. Compiler errors (ambiguous calls to begin/end) are generated, when ADL finds both std::begin/end and boost::begin/end in range-based for and there is no single best match. Remarkably, boost::iterator_range (and adapted ranges in Boost.Range) cannot be used in range-based for. First let us recall range-based for. A range-based for for (auto x : range_expr) { // do something } is equivalent to { // Special rule: namespace std is added to rng's associated namespaces auto&& rng = range_expr; for ( auto it = begin(rng), it_end = end(rng); it != it_end; ++it ) { auto x = *it; // do something } } Note that rng has namespace std as its associated namespaces and the unqualified begin/end function call triggers ADL. In C++0x, there are std::begin functions (for simplicity, let's ignore end): template <typename Range> auto begin(Range& r) -> decltype(r.begin()); template <typename Range> auto begin(Range const& r) -> decltype(r.begin()); And Boost.Range has boost::begin functions: template <typename Range> inline typename boost::range_iterator<Range >::type begin(Range& r); template <typename Range> inline typename boost::range_iterator<Range const>::type begin(Range const& r); So, if - rng has namespace boost as its associated namespaces, - the header file boost/range/begin.hpp is included, and - there is no single best match between std::begin and boost::begin, then unqualified begin function call becomes ambiguous. For example, all the following codes fail to be compiled: // code 1 #include <boost/range/iterator_range.hpp> for (auto x : boost::iterator_range<int*>(nullptr, nullptr)) {} // error // code 2 #include <boost/ptr_container/ptr_vector.hpp> for (auto x : boost::ptr_vector<int>()) {} // error // code 3 #include <vector> #include <boost/range/adaptor/reversed.hpp> for (auto x : std::vector<int>() | boost::adaptors::reversed) {} // error // code 4 #include <boost/algorithm/string.hpp> #include <boost/array.hpp> for (auto x : boost::array<int, 2>()) {} // error // code 5 #include <vector> #include <boost/shared_ptr.hpp> #include <boost/range/algorithm.hpp> for (auto x : std::vector<boost::shared_ptr<int> >()) {} // error These errors can be resolved by fixing boost/range/begin.hpp. The fix uses a using-declaration ("using std::begin;") and SFINAE (disable_if with "has_begin" metafunction). A summary of range-based-for-compatible <boost/range/begin.hpp> is the following: #ifndef BOOST_NO_RANGE_BASED_FOR namespace boost { using std::begin; // has_begin metafunction... template <typename Range> inline typename boost::range_iterator<Range>::type begin(Range& rng, typename disable_if<range_detail::has_begin<Range>>::type* = 0) { return range_begin(rng); } // const version ... } #else // existing code... For details, see the attached. I also attach a patch for Boost.Config to add BOOST_NO_RANGE_BASED_FOR. Any comments or thoughs? Regards, Michel

4 7

[smart_ptr] enable_shared_from_this and multiple inheritance solution
by Philippe Cayouette 03 Jan '11

03 Jan '11

Fellow boosters, A little while ago I found a pernicious problem with enable_shared_from_this when used with multiple inheritance. Here is an example: #include <boost/smart_ptr.hpp> #include <boost/enable_shared_from_this.hpp> class Base1 : public boost::enable_shared_from_this< Base1 > { public: Base1() {} virtual ~Base1() {} boost::shared_ptr< Base1 > GetBase1() { return shared_from_this(); } }; class Base2 : public boost::enable_shared_from_this< Base2 > { public: Base2() {} virtual ~Base2() {} boost::shared_ptr< Base2 > GetBase2() { return shared_from_this(); } }; class Derived : public Base1, public Base2 { }; int main() { boost::shared_ptr< Derived > wDerived(new Derived()); // Either of the following lines crashes with GCC, but the first one // passes on VS2005 boost::shared_ptr< Base1 > wBase1 = wDerived->GetBase1(); boost::shared_ptr< Base2 > wBase2 = wDerived->GetBase2(); return 0; } Since Derived inherits from two bases that each inherits from enable_shared_from_this, it has two internal weak_ptr. These weak_ptr are usualy initialised in the constructor of the shared_ptr and I have observed two different behavior with the above code depending if I build it with VS2005 or GCC. With VS2005, the first base class in the inheritance list of Derived (here Base1) get its internal weak_ptr initialized, but not the second one, thus it crashes when we try to access the Base2 weak_ptr via shared_from_this. On GCC, neither base classes get their internal weak_ptr initialized and both base classes access to their internal weak_ptr provokes a crash. To prevent that kind of problem, I created a SmartPtrBuilder and a (very) slightly modified EnabledSharedFromThis (only one assert was removed). Here is the same program with the modifications: #include <boost/smart_ptr.hpp> #include "EnableSharedFromThis.h" #include "SmartPtrBuilder.h" class Base1 : public Generic::EnableSharedFromThis< Base1 > { public: Base1() {} virtual ~Base1() {} boost::shared_ptr< Base1 > GetBase1() { return SharedFromThis(); } }; class Base2 : public Generic::EnableSharedFromThis< Base2 > { public: Base2() {} virtual ~Base2() {} boost::shared_ptr< Base2 > GetBase2() { return SharedFromThis(); } }; class Derived : public Base1, public Base2 { public: // Factory method static boost::shared_ptr< Derived > Create() { return Generic::SmartPtrBuilder::CreateSharedPtr< Base1, Base2 >(new Derived()); } private: Derived() {} }; int main() { boost::shared_ptr< Derived > wDerived = Derived::Create(); // No more crashes boost::shared_ptr< Base1 > wBase1 = wDerived->GetBase1(); boost::shared_ptr< Base2 > wBase2 = wDerived->GetBase2(); return 0; } As you can see, Derived has now a factory method that uses the SmartPtrBuilder to create the shared_ptr. Two template arguments are used on CreateSharedPtr, allowing it to initialize the internal weak_ptr of each base classes. The SmartPtrBuilder I did can support up to 10 base classes as template arguments and I also did a variadic template version which has no limit. By using the factory method, the users of Derived don't need to know which of its base classes need its internal weak_ptr need to be initialized. Source code for the SmartPtrBuilder and the modified EnableSharedFromThis: http://spoluck.ca:8000/boost/EnableSharedFromThis.h http://spoluck.ca:8000/boost/SmartPtrBuilder.h That builder might be incorporated to the boost smart pointer library so that anyone could use its facilities to prevent the problem mentioned earlier. No modification to the mighty shared_ptr class required, only the addition of a builder. What do you think? Philippe

3 7

[SoC] BGL project idea
by Gautam Sewani 03 Jan '11

03 Jan '11

Hi, I am a Computer Science student hoping to contribute to Boost for this year's summer of code. I had a few questions regarding the BGL project idea (https://svn.boost.org/trac/boost/wiki/SoC2010#Boost.Graph) for SOC 2010. 1. I can think of only a few places where the suggested algorithms will be used. Does the community think that these algorithms are used frequently enough to put them in a library? How important does the community consider this project? 2. Will the project proposal be expected to include the API design? Thanks and Regards Gautam

5 29

[BGL] Get properties from an out_edge_iterator efficiently
by Shaun Jackman 03 Jan '11

03 Jan '11

Hi, I have a graph implementation where get(tag, graph, out_edge_iterator) is much more efficient than get(tag, graph, edge_descriptor) which is probably not an usual case. Would it make sense for BGL to provide a default implementation of the former that dereferences the iterator and calls the latter? Graphs for which the former is more efficient could then specialize this function template. Cheers, Shaun

2 3

[thread] boost::this_thread::sleep broken?
by Jamie Allsop 02 Jan '11

02 Jan '11

From the docs I'd expect to be able to write this: std::cout << "Time Before Sleep: " << boost::posix_time::microsec_clock::local_time() << std::endl; boost::this_thread::sleep( boost::posix_time::seconds(10) ); std::cout << "Time After Sleep : " << boost::posix_time::microsec_clock::local_time() << std::endl; and have the 'this' thread sleep for approximately 10 seconds. Instead sleep returns instantaneously: Time Before Sleep: 2010-Dec-25 01:38:50.949160000 Time After Sleep : 2010-Dec-25 01:38:50.949436000 I've tried this with boost 1.45 and boost 1.43 using gcc 4.4 on debian x86_64. Am I missing something obvious? Jamie

2 2

Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)
by Lars Viklund 02 Jan '11

02 Jan '11

>>> On Fri, Dec 17, 2010 at 9:34 PM, Lars Viklund<zao(a)acc.umu.se> wrote: >>>> Maybe you can adapt to the conventions of the real world, or use >>>> git-svn? >> On Fri, Dec 17, 2010 at 22:19, Dean Michael Berris >> <mikhailberis(a)gmail.com> wrote: >>> Which real world are you talking about, the one that I live in where >>> nobody uses SVN anymore and instead use Git for large open source >>> development projects? :) >Am 18.12.2010 09:47, schrieb Scott McMurray: >> Probably the "large commercial software company" world where the >> source control is so bad that branches get merged once every two weeks >> at best, and all checkins are blocked for over 24 hours when they do, >> so multiple releases get worked on in the same branch just to avoid >> the merging headaches. On Sat, Dec 18, 2010 at 03:46:30PM +0100, Oliver Kowalke wrote: >I think we should stop this talk - if desired you can start a new thread >with this topic. I apologise if the term "real world" was misunderstood, but I'm rather tired of when people come in from the outside, implying or demanding that a project should change their version control, build system or favourite bikeshed colour, just because they are used to something else (possibly "better") from elsewhere. As for version control, what does it matter if Boost uses Subversion, when you as a DVCS user can trivially use git-svn [1] to interop against the repository (in this case, the sandbox). You get to use your favourite toy, without affecting the existing infrastructure in any way. In the end, the version control you choose is rather tangential. As long as it's sufficiently competent (which Subversion in my eyes is), you'll survive. Of course, you may propose constructive criticism and suggest migration plans to other toolchains, with good arguments for why this is a good thing. See the mythical 'Ryppl' project, which aims to componentise Boost into a pile of Git repositories and some magical combination of scripts and CMake, aimed at letting you track exactly the versions of components you need. Remember that no tool is isolated. Changing from Subversion to <whatever> would result in many changes propagating to how test runners are set up, rewriting of commit hooks, modifying Trac (if possible) (although the SVN functionality is disabled there for now), requiring adaptation of any entity out there that use Boost's repositories in any way, including externals, build scripts, CI environments, etc. And of course, having to have the mirrored Subversion repositories up for years, as you can't really 'flag day' such things. -- Lars Viklund | zao(a)acc.umu.se

28 102

[Review][Ratio] Boost.Ratio has been ACCEPTED
by Anthony Williams 01 Jan '11

01 Jan '11

Hi, I am pleased to announce that Boost.Ratio has been ACCEPTED into Boost. There were not as many reviews for Boost.Ratio as for some libraries, but they were overwhelmingly positive. Boost.Ratio is an important building block for other upcoming submissions, and provides an implementation of the C++0x rational arithmetic facilities. A few changes were requested by the reviewers, which I will list below. I know that Vicente has already started working on some of these. These changes should be addressed before the library appears in a Boost release. * Some of the macros had names with RATIO_RATIO in. These should be changed to just RATIO * The ratio_add, ratio_sub, ratio_multiply and ratio_divide templates should derive from the resulting ratio type as well as providing the nested ::type member, in order to closely emulate the template alias facility from C++0x * The typos in the documentation should be fixed, and the documentation reviewed for correctness and clarity (though several of the reviewers made positive comments on the quality of the documentation). * The library needs more tests under the Boost Software License. * All references to names from the boost namespace should be qualified with boost:: to avoid potential name clashes and ambiguity with names from the global namespace. * Sections commented out with #if 0 should be removed * The extensions beyond the facilities required by the C++0x draft should be able to be enabled or disabled through use of a configuration macro. * References to the tests, examples and documentation from within the code should be checked for correctness. I would like to thank Vicente for submitting the library and those that took the time to write a review. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

2 2

[fiber] new version
by Oliver Kowalke 01 Jan '11

01 Jan '11

boost.fiber has been refactored - most of the code has moved to another lib. The new version allows directly to run and yield the fiber. class jumpable is an example how a fiber can be used.

2 3