- Boost - lists.boost.org

[type_erasure] default implementation of concept signatures
by Vicente Botet 28 May '11

28 May '11

Hi Steve, Concepts are able to define default implementations if the type doesn't provides the specific signature. For example in 20.1.2 Comparisons the concept LessThanComparable defines a default for implementation for bool operator>(U const& a, T const& b) { return b < a; } bool operator<=(U const& a, T const& b) { return !(b < a); } bool operator>=(T const& a, U const& b) { return !(a < b); } In the definition of the concept less_than_comparable in Boost.Any, you define the implementation of these operators in function of operator<(), but if the types provide the specific signature the specific function is not called. I guess that the default implementation of for example operator<= should use operator< only if the the underlying types don't provide operator<=. What do you think? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/type-erasure-default-implementation-of-c… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 9

[1.47.0] Release schedule
by Beman Dawes 28 May '11

28 May '11

* Monday, June 6: branches/release closed for all changes, except by permission of a release manager. * Monday, June 13: branches/release frozen. Only release managers may commit. Once tests have cycled and the release managers are satisfied with stability, release candidates for the beta will be generated. * Monday, Jun 20: Beta release target date. See June in http://www.boost.org/development/index.html or https://www.google.com/calendar/embed?src=5rorfm42nvmpt77ac0vult9iig@group.… The final release date won't be set until later in the process. Thanks, --Beman

1 0

'unnamed_Path' was not declared in this scope
by Ilya Chernykh 28 May '11

28 May '11

Hi! While building a package against boost I receive the following message: /usr/include/boost/filesystem/v2/operations.hpp: In function 'Path boost::filesystem2::current_path()': /usr/include/boost/filesystem/v2/operations.hpp:534:14: error: 'unnamed_Path' was not declared in this scope Is this an error in boost and how can I overcome it?

2 1

[gsoc] heap review
by Tim Blechmann 28 May '11

28 May '11

hi all, during this `summer of code', i will do the review of two proposed libraries, boost.lockfree and boost.heap. the boost.heap review will be the first one, taking place from may 30th to june 8th. boost.heap is an implementation of different priority queue data structures. they can be found at: tarball: http://tim.klingt.org/git?p=boost_heap.git;a=snapshot;h=HEAD;sf=tgz git repository: git://tim.klingt.org/boost_heap.git documentation: http://tim.klingt.org/boost_heap/ there will be a `formal' review announcement, i want to invite people to check out code, examples and documentation ... cheers, tim -- tim(a)klingt.org http://tim.klingt.org Question: Then what is the purpose of this "experimental" music? Answer: No purposes. Sounds. John Cage

6 9

[Block Pointer] benchmark
by Phil Bouchard 27 May '11

27 May '11

Hi, Just for the records I have benchmarked block_ptr using: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/be… And I get the following: auto_ptr: 9208870 ns shared_ptr: 22958516 ns block_ptr: 75860365 ns Which is pretty good given the complexity it goes thru. I was wondering if there is any hope in having a pool::ordered_malloc() call of O(1) instead of O(n) and a faster pool::is_from()? The latter could be just a check to see if a pointer is within reserved memory pages of the pool. I tried to talk to the author of pool but I got no response. Thanks, -Phil

10 47

[release] 1.4.7
by Thomas Heller 27 May '11

27 May '11

Hi, Now that boostcon is over, what are the dates for 1.47? Thanks, Thomas

9 11

boost.move?
by Bryce Lelbach 27 May '11

27 May '11

Has been Boost.Move been accepted already? If so, can we squeeze it in for the next Boost release? -- Bryce Lelbach aka wash boost-spirit.com px.cct.lsu.edu github.com/lll-project

1 0

Boost Steering Committee
by Beman Dawes 27 May '11

27 May '11

There was a special session Friday morning at BoostCon 2011 to announce the formation of a Boost Steering Committee. The slides from that session have been annotated to make them more comprehensible to those not present. See http://tinyurl.com/3l27o3q (There is also a link on steering.boost.org, but DNS isn't resolving that yet for me. Instead use https://sites.google.com/a/boost.org/steering/) We haven't yet decided anything beyond what is on the slides, so it will take a bit of time before details emerge. As the slides mention, the first job of the steering committee is to design of its own operating procedures and policies. Input from the Boost community will help form those procedures and policies. The steering committee is an important change in the way Boost operates! We hope it will position Boost to continue to grow and prosper. --The Boost Steering Committee Beman Dawes Dave Abrahams Hartmut Kaiser Jeff Garland Jon Kalb Marshall Clow Robert Stewart Steven Wantanabe

3 2

[tokenizer] tokenizing by strings rather than chars
by Andrzej Krzemienski 27 May '11

27 May '11

Hi, I am facing a problem, and I wonder if Boost.Tokenizer, or any other Boost library solves it already. I want to parse numbers separated by "new-lines", however, on my windows system, a "new-line" is represented by two consecutive characters: 13, 10 (or in other words by string "\n\r"). So, only if I encounter a sequence of these two chars do I want to cut the token. boost::char_separator appears to be a bad choice, because it only "cuts" on single chars. Is there a solution to that problem in Boost? Regards, &rzej

3 3

iterator_facade triggers ADL, fails to compile
by Arno Schödl 27 May '11

27 May '11

Hello, the attached file arg_names.cpp fails to compile (VS2008) when using boost::lambda::_1 or boost::phoenix::arg_names::_1. The compilation succeeds when using boost::bind. All three variations are in the attached code for illustration. The compilation fails due to the presence of a templated operator& definition which is introduced by the instantiation of a class that is declared "andable" (from boost/operators.hpp). The compilation fails because iterator_facade triggers ADL in BOOST_ITERATOR_FACADE_INTEROP and finds the aforementioned operator& when comparing iterators that carry boost::lambda::_1 or boost::phoenix::arg_names::_1 as part of their type specification. In the example, this is illustrated by using filter_iterator. It is not clear to me what exactly the mechanism is that causes this ADL problem. But the static_cast in BOOST_ITERATOR_FACADE_INTEROP can be implemented using references instead of pointers, as shown below, which makes the problem disappear. In any case, using operator& on the iterator may be problematic if the iterator overloads operator&. --- C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/boost_1_46_1/boost/iterator/iterator_facade.hpp Wed May 25 11:42:14 2011 +++ C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/boost_1_46_1/boost/iterator/iterator_facade - Copy.hpp Wed May 25 11:41:49 2011 @@ -819,8 +819,8 @@ is_interoperable< Derived1, Derived2 >::value \ )); \ return_prefix iterator_core_access::base_op( \ - *static_cast<Derived1 const*>(&lhs) \ - , *static_cast<Derived2 const*>(&rhs) \ + static_cast<Derived1 const&>(lhs) \ + , static_cast<Derived2 const&>(rhs) \ , BOOST_ITERATOR_CONVERTIBLE(Derived2,Derived1) \ ); \ } Does anyone understand better what is happening? Or can we simply adopt the change? Regards, Arno -- Dr. Arno Schödl | aschoedl(a)think-cell.com Technical Director think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

3 4