RE: [boost] Policy or Trait?
Trait - A class template parameterized on a single type that associates information with that type. A traits class, therefore, provides an external, named grouping of metainformation, behavior, or both for that type. A trait class is never passed as a template parameter; it's name is ubiquitous. A traits class never has state.
By state you mean non-static data members, yes?
Policy - A class template passed to other templates for the purpose of providing a named grouping of metainformation, behavior, or both to those templates. Because it is a template parameter, different policy classes can be used as desired. In many cases, a policy class is used as a base class.
Well, apparently there is somebody who think the same as I do. Thank you Rob, for your definitions. They seems sound and close to what I have in mind.
What do you think? I know that my definitions mean that std::char_traits is a policy class, despite its name, and they probably deviate from some other ad hoc definitions. The question is whether these provide sound, distinct, and defensible concepts that could be codified for future use at Boost (and elsewhere).
That's flaw in char_traits not in definitions above, IMO. Gennadiy.
From: "Rozental, Gennadiy" <gennadiy.rozental@thomson.com>
Trait - A class template parameterized on a single type that associates information with that type. A traits class, therefore, provides an external, named grouping of metainformation, behavior, or both for that type. A trait class is never passed as a template parameter; it's name is ubiquitous. A traits class never has state.
By state you mean non-static data members, yes?
Yes.
Policy - A class template passed to other templates for the purpose of providing a named grouping of metainformation, behavior, or both to those templates. Because it is a template parameter, different policy classes can be used as desired. In many cases, a policy class is used as a base class.
Well, apparently there is somebody who think the same as I do.
Thank you Rob, for your definitions. They seems sound and close to what I have in mind.
I'm hoping we can all come to agree on something that usefully distinguishes these terms. It is a hindrance to communication if everyone brings a different interpretation of the words to a conversation and if the two are thought to be completely interchangeable, then why use both? -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
participants (2)
-
Rob Stewart -
Rozental, Gennadiy