Boost logo

Boost :

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.
>Note that
>> 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

>> Structors
>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
not standard.

>> any::~any();
>> 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
>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"

The "copy constructor of the contents of rhs" does not seem to make
sense :-}

>> Assignment satisfies the strong guarantee of exception
>> safety.
>Or "satisfies the strong exception-safety guarantee"?


Thanks, Kevlin.

  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, gregod at, cpdaniel at, john at