From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-11-10 05:13:23
In message <065601c04ad3$291104f0$0500a8c0_at_[hidden]>, David
Abrahams <abrahams_at_[hidden]> writes
>What a happy coincidence; I just found a compelling use for any in my own
>> The following type, patterned after the OMG's Property Service, defines
>> name-value pairs for arbitrary value types:
>> 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?
As with Jeff Garland's posting, I will go for a more native C++
approach. This was a more literal translation of the OMG Property
Service, which manages property queries and updates through sequences.
>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.
Certainly. This inclusion in the examples section was just rushed in,
and it is my intent to work this into a fuller example.
>> ValueType requirements
>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?
No problem. Pointers and smart pointers themselves are values. So any is
value-based in the same way that STL is -- in other words, it does not
go chasing after pointers.
>> The specific requirements on value types to be used in an any are:
>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?
I didn't think it was important enough to introduce a separate
requirement, so I patterned it after the 'optional' reqs on sequences.
>It doesn't look like your any class can hold a (non-const) reference. If so,
>I think you should consider correcting this.
References are not values :->
>> An exception-safe class whose instances can hold instances of any type
>> satisfies ValueType requirements: effectively an unbounded union type.
>> any itself satisfies ValueType requirements.
>Ooh, a pet peeve of mine: you can't just say "an exceptions-safe class".
Yes you can :-) This is an abstract for the rest of the class, and the
precise meaning of exception safety is made clear in the specific member
>Is "structor" an accepted term? I've never heard it before...
It's a collective term used originally, IIRC, by SNiFF+. And no, it is
>> Non-throwing destructor that releases any and all resources used in
>hmm, watch your language----------------^^^ !
Watch your formatting ;-)
>> any & operator=(const any & rhs);
>> Copy assignment operator
>Why say that part?
Because there not all assignment operators are copy assignment
operators, eg the templated assignment operator.
>> that copies content of rhs into current instance,
>In what sense is *this "current"?
Just a particular OO turn of phrase: the instance on which I am
currently focused, ie 'inside'.
>> discarding previous content, so that the new content is equivalent in both
>> and value to the content of rhs,
>Can't we just say "the new content is a copy of the content of rhs"?
I was just trying to make as explicit as possible.
>> or empty if rhs is empty. May fail with a
>> std::bad_alloc exception or any exceptions arising from the copy
>> 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"
The "copy constructor of the contents of rhs" does not seem to make
>> Assignment satisfies the strong guarantee of exception
>Or "satisfies the strong exception-safety guarantee"?
Kevlin Henney phone: +44 117 942 2990
Curbralan Limited mobile: +44 7801 073 508
mailto:kevlin_at_[hidden] fax: +44 870 052 2289
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk