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
> > 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
> > 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
> 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
> 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
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
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
The converse relationship an external concept and its corresponding concept
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
void foo( const T, int )
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk