|
|
Glas :Re: [glas] glas Digest, Vol 25, Issue 1 |
From: Robert P. Goddard (Robert_Goddard_at_[hidden])
Date: 2007-04-05 13:34:00
Karl,
I'm generally supportive of your idea of using free functions and traits
in place of member functions and member typedefs. However, I caution
against doing away with the latter. The Standard Library provides a good
example (as it often does): The default definition for
std::iterator_traits is, in part,
template <class Iterator>
struct iterator_traits {
typedef typename Iterator::value_type value_type;
};
That way the developer of an iterator has a choice: Provide a
specialization of iterator_traits, or provide a nested typedef and let
the default iterator_traits pick it up. The latter is often easier, in
part because nested typedefs can come from a base class. The former is
sometimes necessary, such as non-class types or classes developed by
someone else.
The same principle applies to free functions versus member functions: A
reasonable default definition of size() could be
template <class V>
VectorExpression<V>::size_type size( const V& size )
{
return V.size();
}
Again, the developer of a new VectorExpression class has a choice:
Overload the free size() function or provide a member function. The
latter is often preferred, e.g. when it's a virtual function, and the
former is sometimes necessary, e.g. when it's a non-class or you don't
own it.
In both cases, the free version is the preferred interface for users.
The member version is provided primarily for developers, who can be the
same users wearing different hats.
-- Robert P. Goddard, Senior Physicist Applied Physics Laboratory, University of Washington 1013 NE 40th St., Seattle, WA 98105-6698 206-543-1267; FAX 206-543-6785; cell 206-718-4417 Robert_Goddard_at_[hidden] glas-request_at_[hidden] wrote: > Send glas mailing list submissions to > glas_at_[hidden] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.boost.org/mailman/listinfo.cgi/glas > or, via email, send a message with subject or body 'help' to > glas-request_at_[hidden] > > You can reach the person managing the list at > glas-owner_at_[hidden] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of glas digest..." > > > The glas archives may be found at: http://lists.boost.org/MailArchives/glas/ > > Today's Topics: > > 1. Re: proposals (Karl Meerbergen) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 04 Apr 2007 20:10:51 +0200 > From: Karl Meerbergen <Karl.Meerbergen_at_[hidden]> > Subject: Re: [glas] proposals > To: Generic Linear Algorithm Software <glas_at_[hidden]> > Message-ID: <4613EA2B.9030408_at_[hidden]> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > I am preparing a proposal for an extendable backend system and concepts > for vectors (and scalars to some extent). > > One of the design decisions I would like to make is to use free > functions as much as possible. I think that free functions would make > life alot easier and extensions more straightforward. I will explain > later in detail. > > Does someone have a strong objection against > size(v) instead of v.size(), stride(v) instead of v.stride() ? > > Similarly, one could argue that meta functions are preferred to members, > e.g. > size_type<V>::type rather than V::size_type. > > However, concept C++ suggests to organize this in a slightly different > way, e.g. > VectorExpression<V>::size_type > where VectorExpression is a concept. > In pure C++, VectorExpression would be a traits blob. > Therefore, I prefere the latter notation to meta functions with a single > type member. > > Best, > > Karl > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: Karl.Meerbergen.vcf > Type: text/x-vcard > Size: 339 bytes > Desc: not available > Url : http://lists.boost.org/MailArchives/glas/attachments/20070404/5b83a4eb/attachment.vcf > > ------------------------------ > > _______________________________________________ > glas mailing list > glas_at_[hidden] > http://lists.boost.org/mailman/listinfo.cgi/glas > > End of glas Digest, Vol 25, Issue 1 > *********************************** >