"David Abrahams" <dave@boost-consulting.com> wrote in message news:uzn9vnwtz.fsf@boost-consulting.com...

"Rozental, Gennadiy" <gennadiy.rozental@thomson.com> writes:

...

...

...

both for that type. A trait class is never passed as a template parameter; it's name is ubiquitous.

Whoops, can't agree there. The boost type traits are passed as template parameters all the time:

mpl::apply_if< is_pointer<X>, remove_pointer<X>, add_reference<X> >

What he meant, I think, is "never passed as a template parameter together with primary type"

I don't know what "primary type" means here.

X in example above. Actually you may say that even my rephrasing isn't correct. One could always says mpl::apply_if<is_pointer<X>, X, "something else" > Let me try this way: For any type "T" listed in template definition no class that specify trait of the type "T" is used in a same template parameter list.

...

...

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.

Could you please rephrase. It's a bit unclear.

Technically one can never say "class template foo is a traits template" or "class template foo is a policy" without examining how it's used. There's no fundamental reason that the same class template can't be used in both ways, so for any given class template, there may be no either/or answer.

Well, technically you maybe right, though it's quite difficult to imagine an example of that. But still trait is entity that *define* compile time mapping of type to some kind of value, which maybe numaric value, another type or any other more complex thing (including something that may defines behavior). You may use it as a template parameter (not quite as a policy though in majority of the cases). Like in example above. Here we are using type trait as a selector. But is_pointer is still a trait class. Would you advokate a design that supply is_pointer along with type it applied to as a template parameters? template<typename T, typename TIsPointer> struct my_container {...}; template<typename T> struct C { my_container<T,is_pointer<T> > storage; }; So, could we say that is_pointer defines a trait? Regards, Gennadiy.

"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:

...

Well, technically you maybe right, though it's quite difficult to imagine an example of that.

char_traits is one.

But If I understood you correctly in some other place you say that char_traits is an example of bad design. And I think the same. IMO any example of trait/policy mixure in the same class would be an example of bad design. Gennadiy.

...

And I think the same. IMO any example of trait/policy mixure in the same class would be an example of bad design.

I don't know; it seems to me that the

template <class T, class Policy = xxx_traits<T> > class Foo;

idiom might not be a bad one for some uses if xxx_traits is only supplying associated types. It allows customization of the meaning of Foo<X> for any X by specializing xxx_traits<X>, while also allowing users to explicitly choose Foo<X, Y> when they don't like the default for X.

And you get basic_string design as a result. If user do not like default value for the trait. It's value should be set *externally* to the component definition. That is the major point I am trying to prove in regards to numeric_cast design and in thic generic discussion. Gennadiy.

...

If user do not like default value for the trait. It's value should be set *externally* to the component definition. That is the major point I am trying to prove in regards to numeric_cast design and in thic generic discussion.

But what about the distinction that xxx_traits<T>, a class, is being used as the Policy type in Foo? From Foo's perspective, it has a Policy which its clients can define any way they like

They sure could. Note though that this is not how basic_string is designed. There Traits parameter used as trait collection. I am yet to see an example of good design that rely on possibility of trait class to be used sometimes as policy. I still couldn't find a reason to use policy parameter that could be instantiated with trait value. It should be something that is not unique to the type but sometimes it may coinside with some other [un]related type trait. I guess it's possible. But it rare case that could be omitted in basic definition and mentioned only in "special cases" clause.

within the constraints of what's expected of the policy. By the same token, other code, even code within Foo can use xxx_traits<T> to get information. (Foo could do it regardless of the type corresponding to the template argument Policy.)

-- Rob Stewart stewart@sig.com

Gennadiy.

From: David Abrahams <dave@boost-consulting.com>

I don't know; it seems to me that the

template <class T, class Policy = xxx_traits<T> > class Foo;

idiom might not be a bad one for some uses if xxx_traits is only supplying associated types. It allows customization of the meaning of Foo<X> for any X by specializing xxx_traits<X>, while also allowing users to explicitly choose Foo<X, Y> when they don't like the default for X.

Right. The only problem arises when xxx_traits is used as the exemplar for the policy and not all of xxx_traits' interface is needed. That can be solved with documentation, but the tendency is likely to be to copy xxx_traits and modify its functionality when creating a new policy class. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;

Rob Stewart <stewart@sig.com> writes:

From: David Abrahams <dave@boost-consulting.com>

...

Technically one can never say "class template foo is a traits template" or "class template foo is a policy" without examining how it's used. There's no fundamental reason that the same class template can't be used in both ways, so for any given class template, there may be no either/or answer.

I don't quite agree. A policy class is only that because it is a template parameter.

A class is never a template parameter. It can be a template argument.

Whether a class that is passed as a policy to some template happens to be a traits class is immaterial. So, in the context of the template, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Exactly. How it's used.

the template parameter is a policy class and that may correspond to a traits class in a particular specialization, but that doesn't make the traits class a policy class. Does that make sense?

Not much, to me. I think you're trying to say the same thing I said, but in a more contorted way. -- Dave Abrahams Boost Consulting www.boost-consulting.com

From: David Abrahams <dave@boost-consulting.com>

Rob Stewart <stewart@sig.com> writes:

...

From: David Abrahams <dave@boost-consulting.com>

...

Technically one can never say "class template foo is a traits template" or "class template foo is a policy" without examining how it's used. There's no fundamental reason that the same class template can't be used in both ways, so for any given class template, there may be no either/or answer.

I don't quite agree. A policy class is only that because it is a template parameter.

A class is never a template parameter. It can be a template argument.

Those two are often used interchangeably. The standard always, may use "parameter" and "argument" in those senses, but they aren't defined and common usage gets in the way. Anyway, I meant "parameter" according to that dichotomy.

...

Whether a class that is passed as a policy to some template happens to be a traits class is immaterial. So, in the context of the template, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Exactly. How it's used.

A traits class can be used as a policy. We're agreed. However, that traits class is not a policy class. A class (template) can be created to be a policy or it can be created to be a traits class. In the former case, it is created specifically to meet a need for a policy; there is no intention that code would ever be written using its name directly. That is, it is only ever passed as a template _argument_. By contrast, a traits class is not created to be used as a policy. If a template comes along that decides the traits class' interface is appropriate to be its policy, then the traits class can be used as that templates policy. That doesn't make the traits class a policy class, IMO. Its use within the template is as a policy.

...

the template parameter is a policy class and that may correspond to a traits class in a particular specialization, but that doesn't make the traits class a policy class. Does that make sense?

Not much, to me. I think you're trying to say the same thing I said, but in a more contorted way.

Therein lies the rub. You _think_ we're saying the same, but neither of us is entirely sure yet. BTW, once there's agreement, we need to try our hand at definitions. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;

"David B. Held" <dheld@codelogicconsulting.com> writes:

Ah, and here I think is the sticking point. I think we are thinking of traits and policies as complements/duals of each other. That is certainly a natural way for brains to dichotomize things. But, after writing my definitions and seeing more discussion, I am led to the conclusion that traits and policies are fundamentally different things.

That is, I claim that "traitness" is a property of a *type*, but

std::iterator_traits is not a type. Don't you mean a *class template*? -- Dave Abrahams Boost Consulting www.boost-consulting.com