Re: [boost] Formal Review: any

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-11-07 11:44:16

In message <D3E6C22AF7F13B4FB2490F89879B408F06608D_at_SEA-DOG>, Gary Powell
<Gary.Powell_at_[hidden]> writes
>I've read the documents, and looked over the any.hpp file. I think "any"
>should be accepted into boost. 

Thanks.

>I have not made my own test suite. Sorry I'm
>short of time this week.

Know the feeling...

>any.hpp should add the following bit of code.
>
>namespace std {
>void swap(boost::any & lhs, boost::any & rhs) { lhs.swap(rhs); }
>}
>
>Reasoning: If you are going to provide an optimized swap you should let the
>namespace std know about it.
>
>I think this is a legal overload. (Feel free to cite chapter and verse for
>why not.)

As pointed out elsewhere, this needs to be a full specialization, which
I will add.

>As an addition I'd also prefer that "any" take a template parameter
>allocator instead of calling the global new. (That would make any a
>template, which would make the above swap addition illegal.) 

Or, to be accurate, it would require partial function template
specialization... which is not legal :-(

>Reasoning, it would make it more flexible for user controlled memory.

Well, there are some problems with this, not least of which is that I
personally dislike the standard allocator model :-> It solves a small
class of problems in an unnecessarily complex and awkward fashion. It is
often easier to solve such problems a different way.

Partly as a result of the previous point, custom allocators are rare.
Very rare. As a corner case it would completely change the syntax of any
from simple to quirky, ie instead of declaring boost::any users would
always (that's 99.X% rounded up :->) be declaring boost::any<>. In other
words, common usage would be compromised.

Making any templated on an allocator sounds like premature
generalisation, esp as I am not convinced that it genuinely buys users
much. In over four years of presenting and playing around with similar
classes, custom allocation has never been requested until now :-}

>Alternatively would it be possible for holder to have an operator new, which
>called the ValueType::operator new() ? That would allow it to call the user
>type new. (Caveat I haven't tried this so I'm not even sure that its
>possible.)

Problem with that is that ValueType::operator new may not be of much use
as it would be in all probability be tailored to sizeof(ValueType)
rather than sizeof(holder<ValueType>).

>Question: Does it make sense to add the operator!() to any? (Or does the
>conversion to void * happen first and then operator!()? )
>
>as in   
>  any a; 
>  if (!a) {...}

This is currently legal as a result of the conversion to const void *.
However, I should make it clear in the documentation.

>I tried to search the history for "any" and comparisons, and thanks to the
>frequent use of the word "any" it was more work that it was worth. So I hope
>not to start a chain of "We discussed this in April and rejected it because"
>discussions, was there any discussion of whether any should provide the
>operator==() and operator>() ? I was thinking about forwarding the
>comparisons to the native types and letting it either compile or not.
>(Depending on whether the types had the necessary operations.)

There was a discussion on this, some time after April, and it kind of
forked :-> Currently, any requires only the minimum, that ValueType be
CopyConstructible. Putting relational operators would now also require
EqualityComparable and LessThanComparable, which is much further than I
want to go with any. It narrows any's use and starts pushing it in a
different direction, esp when it comes to user expectation -- how should
any(2) > any(1.0) if content-based comparison is performed? The current
any supports relational operators in the same way that bool does, ie
based on existence of content, eg any() == any() and any() < any("").

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Limited               mobile: [phone]
  mailto:kevlin_at_[hidden]     fax:    [phone]
  http://www.curbralan.com
____________________________________________________________