Boost logo

Boost :

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-04-02 11:03:03


From: "Reece Dunn" <msclrhd_at_[hidden]>
> David Abrahams writes:
>
> >I think your definitions are mostly on target, but I think where you
> >go wrong is that traits/policies has less to do with how a template
> >is defined than how it's used.
>
> To me a traits class provides information to a template class that gives
> (possibly platform or type dependant) information. For example, the decimal
> point character (100.00 or 100,00?) would be in a traits class (I know this
> is in a locale, but this is an example). Another example would be a format
> string to use as a separator between items in a list, depending on whether a
> character, string, wide character, wide string, etc are used.
>
> A policy class provides functional, i.e. behavioural, information. Examples
> include string comparison, pointer validation (for smart pointers) and error
> handling (e.g. smart pointers and how to handle InvalidPointer - nothing,
> throw std::exception, assert failure, etc.).

I don't agree with those distinctions. I don't have a problem
with a traits class providing behavior so long as that behavior,
specialized as appropriate for the type, is the only behavior you
can get using that traits name. That is, when you want character
traits as defined by the Standard Library, you don't take a
template parameter supplying the traits class, you simply use
std::char_traits<T>::foo. When your template requires clients to
provide overriding functionality, you add a policy parameter
through which clients can inject the class that best implements
the policy semantics for their purposes.

To me, policies are passed to a template as a parameter, traits
are simply known by their name within the template. (Gee, why
didn't I just say *that* before!)

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk