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

Subject: Re: [boost] [any] Divergence between Boost.Any and standard library proposal
From: Beman Dawes (bdawes_at_[hidden])
Date: 2013-05-04 09:15:25

On Fri, May 3, 2013 at 12:30 PM, Antony Polukhin <antoshkka_at_[hidden]> wrote:
> 2013/5/3 Beman Dawes <bdawes_at_[hidden]>:
>>...
>>
>> 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