Re: [boost] More "any" remarks

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-11-10 07:05:24

----- Original Message -----
From: "Kevlin Henney" <kevlin_at_[hidden]>

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

In that case I suggest you strike that whole part. It is at least confusing
and at most misleading.

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

> >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).

> >> 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".
>
> 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
> descriptions.

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.

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

Rather, I asked whether the term was "accepted", i.e. recognized and used by
a significant fraction of programmers.
I'd prefer "constructors/destructors", FWIW. No need to (help) invent new
terminology here.

> >> 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?

> >> 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?

> >> 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'.

I'd suggest "*this" for better precision.

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

I understand. It's just that all the language here seems to make a simple
thing very complicated.

> >> 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 :-}

Not sure why. Certainly, the original language doesn't make it clear that
the type of the original contents of *this will not throw from its c-ctor.

nit-picking-ly y'rs,
dave