More "any" remarks

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-11-10 00:00:34

What a happy coincidence; I just found a compelling use for any in my own
work!

> The following type, patterned after the OMG's Property Service, defines
> name-value pairs for arbitrary value types:
>
> struct property
> {
>     property();
>     property(const std::string &, const boost::any &);
>
>     std::string name;
>     boost::any value;
> };
>
> typedef list<property> properties;

Sorry, but wouldn't std::map<std::string, boost::any> be much more apt? Does
OMG allow multiple properties with the same name?

> The following base class demonstrates one approach to runtime polymorphism
based
> callbacks that also require arbitrary argument types. The absence of
virtual
> member templates requires that different solutions have different
trade-offs in
> terms of efficiency, safety, and generality. Using a checked variant type
offers
> one approach:
>
> class consumer
> {
> public:
>     virtual void notify(const any &) = 0;
>     ...

This bit seems to assume a great deal of specific background
knowledge/understanding of a particular problem domain on the reader's part.
I think a little more explanation would help a lot.

>
> ValueType requirements
>
> Values are strongly informational objects for which identity is not
significant,
> i.e. the focus is principally on their state content and any behavior
organized
> around that. Another distinguishing feature of values is their
granularity:
> normally fine-grained objects representing simple concepts in the system
such as
> quantities.
>
> As the emphasis of a value lies in its state not its identity, values can
be
> copied and typically assigned one to another, requiring the explicit or
implicit
> definition of a public copy constructor and public assignment operator.
Values
> typically live within other scopes, i.e. within objects or blocks, rather
than
> on the heap. Values are therefore normally passed around and manipulated
> directly as variables or through references, but not as pointers that
emphasize
> identity and indirection.
>

This seems like an inappropriately strong emphasis to be giving to such
qualitatively described properties. Suppose I wanted to hold a pointer or
smart pointer in an any (yes, I think I have a real use for this)? Would
there actually be a problem? If so, what would the problem be? If not, what
are you actually trying to say above?

> The specific requirements on value types to be used in an any are:
>
>
>
> A ValueType is CopyConstructible [20.1.3].
>
> A ValueType is optionally Assignable [23.1]. Only any::copy_to requires
this
> optional capability.
>
> The destructor for a ValueType does not throw any exceptions.

This I can grasp. A ValueType is CopyConstructible and its destructor
doesn't throw. I suggest a separate concept AssignableValueType. Or maybe
this is too simple and common a combination of concepts to be worthy of a
separate concept name?

> --------------------------------------------------------------------------
------
>
> any class any { public: // structors
>
>     any();
>     any(const any &);
>     template<typename ValueType>
>       any(const ValueType &);
>     ~any();
>
> public: // modifiers
>
>     any & swap(any &);
>     any & operator=(const any &);
>     template<typename ValueType>
>       any & operator=(const ValueType &);
>
> public: // queries
>
>     operator const void *() const;
>     const std::type_info & type() const;
>     template<typename ValueType>
>       bool copy_to(ValueType &) const;
>     template<typename ValueType>
>       ValueType * to_ptr();
>     template<typename ValueType>
>       const ValueType * to_ptr() const;
>
> private: // representation
>     ...
> };

It doesn't look like your any class can hold a (non-const) reference. If so,
I think you should consider correcting this.

> An exception-safe class whose instances can hold instances of any type
that
> satisfies ValueType requirements: effectively an unbounded union type.
Note that
> any itself satisfies ValueType requirements.

Ooh, a pet peeve of mine: you can't just say "an exceptions-safe class".
There's no well-defined meaning for the term "exception-safe". See
http://people.ne.mediaone.net/abrahams/abrahams.html for more details.

>
> --------------------------------------------------------------------------
------
>
> Structors

Is "structor" an accepted term? I've never heard it before...

> any::~any();
>
>
>
> Non-throwing destructor that releases any and all resources used in
management
hmm, watch your language----------------^^^  !

> of instance.

> any & operator=(const any & rhs);
>
>
>
> Copy assignment operator

Why say that part?

> that copies content of rhs into current instance,

In what sense is *this "current"?

> discarding previous content, so that the new content is equivalent in both
type
> and value to the content of rhs,

Can't we just say "the new content is a copy of the content of rhs"?

> or empty if rhs is empty. May fail with a
> std::bad_alloc exception or any exceptions arising from the copy
constructor of
> the contained type.

Can't we just say "may throw anything thrown by the copy constructor of the
contents of rhs, or std::bad_alloc"

> Assignment satisfies the strong guarantee of exception
> safety.

Or "satisfies the strong exception-safety guarantee"?

> template<typename ValueType>
>
>   any & operator=(const ValueType & rhs);
>
>
>
> Templated assignment operator makes a copy of rhs, discarding previous
content,
> so that the new content of is equivalent in both type and value to rhs.
May fail
> with a std::bad_alloc exception or any exceptions arising from the copy
> constructor of the contained type. Assignment satisfies the strong
guarantee of
> exception safety.

Ditto