Re: [boost] More "any" remarks

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-11-12 11:02:43

In message <069701c04b0e$823ff9b0$0500a8c0_at_[hidden]>, David
Abrahams <abrahams_at_[hidden]> writes
>> 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.
>
>In that case I suggest you strike that whole part. It is at least confusing
>and at most misleading.

That is not the feedback I have had from other people, so I will leave
it.

>> >> 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.
>
>I was trying to suggest that the requirements: "is CopyConstructibe and the
>destructor doesn't throw" doesn't merit a whole concept name unto itself
>(i.e. ValueType). Certainly the standard combines /many/ more concepts than
>that before a new concept name emerges.

Factoring out concepts at this level simplifies the documentation. I
think the standard suffers for not following this modularity. As an
example, having ValueType also allows clarification that it does not
cover references. If VT were not documented, it would be a harder
concept to discuss -- it would require a more "careful reading" rather
than simply saying "ValueType". I prefer to name things that need
discussing than leave them inferred.

>> >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 :->
>
>How foolish of me not to have seen that. Pity, though ;-) The reason I
>mentioned it is that they seem to meet the requirements (CopyConstructible
>and non-throwing destructor).

See above :->

>AFAIK we have no non-exception-safe classes. Saying what you've said may
>have inadvertent implications. In fact, any class with even a pathetic
>exception policy is exception-safe for some definition of "safe" (e.g. "I
>promise not to crash as long as you don't throw anything"). So here's my
>last petition: I don't think you should say it.

I'm going to leave it as is, as it does not seem to confuse most people
and I cannot see what inadvertent implications you are referring to --
all members satisfy the strong or no throw gtee (this might be worth
documenting).

Given the standard definitions of exception safety (yours :->), in what
way is any not exception safe? Given my experience of the programming
populace, including the statement is of more benefit than harm.

>> >> Non-throwing destructor that releases any and all resources used in
>> >management
>> >hmm, watch your language----------------^^^  !
>>
>> Watch your formatting ;-)
>
>Seriously, there's no need to say "any and" here, is there? It doesn't add
>anything, does it?

It clarifies that it cannot be reference counted.

>> >> 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.
>
>Okay, but "anyone" can see that it's a copy assignment operator because the
>signature's right there...no?

It has a proper name, and I cannot see any drawbacks to referring to
something by its proper name.

>> The "copy constructor of the contents of rhs" does not seem to make
>> sense :-}
>
>Not sure why. 

Because rhs's content's copy constructor is of no interest :->

Thanks for the other comments, I'll roll them into the docs when I have
a minute or few.

Kevlin
____________________________________________________________

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