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

From: Pavol Droba (droba_at_[hidden])
Date: 2003-11-19 07:08:11

On Wed, Nov 19, 2003 at 10:12:47PM +1100, Thorsten Ottosen wrote:
> 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
> 

It sounds very good. It should be added to concept_check docs. There is only one small matter.
There could be a possible problem with nameclashes. freestanding function, unlike members, are
not encapsulated in a namespace.

Maybe it would be better to put the traits into a namespace (f.e. with the name of concept).

Regards,

Pavol.