|
Boost : |
From: Kevlin Henney (Kevlin.Henney_at_[hidden])
Date: 2000-01-11 10:07:55
Jeremy wrote:
>There's one controvertial part in deciding what should go into the
>requirements for the Collection concept. The reference type
>requirements:
>
>1) a real C++ reference (too restrictive)
Agreed. This is one issue I have with the requirement in the standard.
>2) any type, but if it is not a real reference the type should also be the
>value type, so member access is still OK.
This raises the bar, but still doesn't go far enough...
>3) any type including proxies to the value type, now
> member access is *not* OK
I would look at it differently: (3) is a requirement, and should include
member access (where members exist) also is. In other words:
3) any type including proxies to the value type, such that any member
access is OK.
What this means in practice is that it is possible to write and use a
generic smart reference for built-ins -- or indeed any type that has no
operational requirements other than operator use.
In the absence of overloading operator. it is not possible to write a fully
generic smart reference class for types requiring member access, but it is
certainly possible to write them on a case by case basis as necessary. So
whilst you cannot have proxied_collection<> written as a template so that
it works generically, you can still write your own foo_collection with your
own foo_collection::reference and have it satisfy the Collection
requirements.
Thoughts?
Kevlin
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk