[boost] Re: Re: Re: Re: Collection Concept

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-11-19 06:12:47

From: "Pavol Droba" <droba_at_[hidden]>
> On Wed, Nov 19, 2003 at 08:16:51PM +1100, Thorsten Ottosen wrote:
> > "Pavol Droba" <droba_at_[hidden]> wrote in message

> > > Another open issue is, how to express the collection concept
requirements
> > in the means of
> > > container(collection)_traits.
> > > Maybe some kind of "IndirectCollection" could be specified, where all
> > requirements are
> > > specified in the means of traits, instead of member functions/typdefs.
> >
> > yeah, or maybe just a freestanding implementation of the XXConcept, so
we
> > could simply say
> > "collection traits is a freestanding implementation of the Collection
> > concept which gives uniform access to the
> > Collection concept for many unrelated types."
> >
>
> Problem is that there is a need for a precise specification of such a
concept.
> Simple wording is not enough, because it is not clear what operations
> must be provided and what are the traits names.
>
> collection_traits can be seen as an implementation of such a concept for
some
> specific types.

what about this bla bla then:

"Generic programming in C++ is characterized by the use of templates where
the template parameter(s) must satisfy certain requirements.Often these
requirements are sufficiently important that we give them a name: we call
such a set of type requirements a <i>concept</i>. We say that a type <i>
conforms to a concept</i> or that it <i>is a model of a concept</i> if it
satisfies all of those requirements. The concept can be specified as a set
of member functions with well-defined semantics
and a set of nested typedef with well-defined semantics.

Often it much more flexible to provide free-standing functions and typedefs
which provides the exact same semantics (but a different syntax) as
specified
by the concept. This allows generic code to treat different types <i> as if
</i> they fulfilled the concept. In this case we say that the concept has
been <i> externalized </i> or that the new requirements <i>is an external
concept </i>. We say that a type <i> conforms to an external concept </i>
or that it <i> is a model of an external concept </i>. A concept may exist
without a corresponding external concept and conversely.

Whenever a concept specifies a member function, the corresponding  external
concept
must specify a free-standing function of the same name, same return type and
the same argument list except there is an extra first argument which must
be of the type (or a reference to that type) that is to fulfill the external
concept. If the corresonding member function has any cv-qulifiers, the
first argument must have the same cv-qualifiers. Whenever a concept
specifies a nested typedef, the corresponding external concept
specifies a <i>type-generator</i>, that is, a type with a nested typedef
named 'type'. The type-generator has the name as the nested typedef with
'_of' appended.
The converse relationship an external concept and its corresponding concept
also holds.

Example: FooConcept.

               A type T fulfills the FooConcept if it
               has the follwing public members:

               void T::foo( int ) const;
               typedef <i>implementation defined </i> foo_type;

The corresponding external concept is the FooExternalConcept

              A type T fullfills the FooExternalConcept if these
free-standing functions and type-generators
              exists:

              void foo( const T, int )
              foo_type_of<T>::type

best regards

Thorsten