Re: [boost] [any] Divergence between Boost.Any and standard library proposal

On Fri, May 3, 2013 at 12:30 PM, Antony Polukhin wrote:

2013/5/3 Beman Dawes :

...

...

AFAICS, the Adobe (and the proposed standard) behavior is preferred. The type does need to decay.

Comments?

Looks like I broke it in https://svn.boost.org/trac/boost/ticket/6999 .

Should I create a new ticket:-)

There are also some other differences: * boost implementation has perfect forwarding of ValueType (constructor and operator=)

I created the attached little test program to see the effects of that. For both VC++ 2012 and GCC 4.7.0 -std=c++11, your implementation is more efficient: Adobe: copy construct any copy ctor move ctor move ctor move construct any move ctor move ctor move ctor copy assign to any copy ctor move ctor move ctor move assign to any move ctor move ctor move ctor Boost: copy construct any copy ctor move construct any move ctor copy assign to any copy ctor move assign to any move ctor Only the tests with differences are shown. The results are the same for both debug and release builds for both compilers. Please look at the test program and verify the tests are OK. I'll email Sean Parent to see what he has to say about those test results:-)

* ValueType requirement is MoveConstructible or CopyConstructible (it can be used with move only types)

Interesting point. IIRC, there has been some discussion in the LWG about such types, but I can't remember the conclusions. I'll check with Daniel Krügler.

* ~any() is noexcept

By convention, the standard library doesn't add noexcept to destructors. I've forgotten the rationale for that.

* proposal misses noexcept in for bad_any_cast: virtual const char* what() const;

Ha! Thanks for spotting that. Proposal fixed.

* Boosts version does not accept Allocator

The standard library is tentatively planning to add type erased allocator support to vocabulary types like any if they typically allocate heap memory, so it was added at the request of the LWG.

A few things that I think would be helpful: * clear() method

Interesting. I'll give it some thought for the proposal.

* ??? assign() method with Allocator

I'll do whatever the committee wants on that one. Thanks for your comments! Much appreciated! --Beman