C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Policies Vs. concepts          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Dave Guest Posted: Thu Aug 26, 2004 7:44 am    Post subject: Policies Vs. concepts Hello all, It seems to me that policies (as defined by Alexandrescu in "Modern C++ Design") and concepts (as defined by Siek, et al. in "The Boost Graph Library") are synonomous. Am I correct? Thanks, Dave [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top David Abrahams Guest Posted: Fri Aug 27, 2004 2:59 am    Post subject: Re: Policies Vs. concepts "Dave" <better_cs_now (AT) yahoo (DOT) com> writes: Quote: Hello all, It seems to me that policies (as defined by Alexandrescu in "Modern C++ Design") and concepts (as defined by Siek, et al. in "The Boost Graph Library") are synonomous. Am I correct? Not really. A generic component that accepts a policy parameter almost certainly requires that parameter to satisfy some concept -- or should, if the component is properly designed and documented -- but that doesn't mean concepts are the same as policies. A concept is an abstract description of requirements placed on some type parameter(s) by a generic component. For example, the std::vector specification requires that its first argument (the type that will be stored) models the CopyConstructible concept. A policy is a concrete type that is used to control the features or behavior of another type. For example, the Allocator argument to std::vector is a type that supplies the memory management behavior of the resulting vector. HTH, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top David B. Held Guest Posted: Fri Aug 27, 2004 10:57 am    Post subject: Re: Policies Vs. concepts Dave wrote: Quote: Hello all, It seems to me that policies (as defined by Alexandrescu in "Modern C++ Design") and concepts (as defined by Siek, et al. in "The Boost Graph Library") are synonomous. Am I correct? Not at all. A policy is an "external" point of customization for a type. It's complement is a trait (which provides all the customizations "internally"). A concept is technically an inductive metatype, or a metatype that is defined by a set of rules. Of course, most people won't define concepts quite like this, but I argue that this is the most precise definition. I will illustrate the differences of each below: Policies: template <typename T> class ref_counted { ... }; template <typename T> class deep_copy { ... }; template <typename T, class OwnershipPolicy> class smart_ptr { ... }; smart_ptr<int, ref_counted> p; smart_ptr<my_class, deep_copy> q; Traits: template <typename T> struct call_traits { typedef T const& param_type; }; template <typename T> struct call_traits<T*> { typedef T param_type; }; template <typename T> struct call_traits<T&> { typedef T& param_type; }; Of course, this isn't how you would normally go about defining call_traits<>, but I hope you get the idea. Concepts: template <typename T> concept SmartPtr<T> { T& SmartPtr::operator*(void); T* SmartPtr::operator->(void); } template <SmartPtr SP> void sink(SP& sp) { // ... } Of course, the code above is not remotely legal C++. But what it is meant to convey is that SmartPtr is a parameterized concept that requires operator*() and operator->() to be defined for the matching type (the type that gets substituted for SP). A more concise syntax (a la N1522) would be: void sink(SmartPtr& sp) { // ... } So as you can see (I hope) is that Policies are used to customize a composite type using arbitrary types passed into the class. Traits are used to customize a type by adding specializations of the traits class. Concepts are used to constrain generic arguments. You cannot use a concept as a policy (doesn't make sense, because a Policy is a type, and a concept is a metatype). Nor can you use a Policy as a Concept (what would it mean for a generic function to accept types conforming to ref_counted?). Policies and Traits are about customization of types (providing features beyond what the authors have included), while Concepts are about constraint of generic arguments (defining a limited set of valid types for a template argument). Dave [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Terje Slettebø Guest Posted: Sat Aug 28, 2004 3:15 am    Post subject: Re: Policies Vs. concepts "David B. Held" <dheld (AT) codelogicconsulting (DOT) com> wrote Quote: A concept is technically an inductive metatype, or a metatype that is defined by a set of rules. Of course, most people won't define concepts quite like this, but I argue that this is the most precise definition. One might also say that a concept defines a set of types, e.g. Assignable is the set of types satisfying the requirements of the Assignable concept. This is similar to a base class defining (or enabling) a set of types supporting its interface (any decendants of the base class). Quote: I will illustrate the differences of each below: Policies: template <typename T class ref_counted { ... }; template class deep_copy { ... }; template class smart_ptr { ... }; smart_ptr smart_ptr<my_class, deep_copy> q; Traits: template <typename T struct call_traits { typedef T const& param_type; }; template struct call_traits { typedef T param_type; }; template struct call_traits { typedef T& param_type; }; Of course, this isn't how you would normally go about defining call_traits<>, but I hope you get the idea. Concepts: template <typename T concept SmartPtr { T& SmartPtr::operator*(void); T* SmartPtr::operator->(void); } template <SmartPtr SP void sink(SP& sp) { // ... } So as you can see (I hope) is that Policies are used to customize a composite type using arbitrary types passed into the class. Traits are used to customize a type by adding specializations of the traits class. Concepts are used to constrain generic arguments. You cannot use a concept as a policy (doesn't make sense, because a Policy is a type According to "Modern C++ Design", one definition of a policy is: "a policy defines a class interface or a class template interface". So a policy isn't a type, in itself; it's a requirement of a type. However, you may have several _implementations_ of that policy, which may be classes or class templates. Quote: , and a concept is a metatype). Nor can you use a Policy as a Concept (what would it mean for a generic function to accept types conforming to ref_counted?). Policies and Traits are about customization of types (providing features beyond what the authors have included), while Concepts are about constraint of generic arguments (defining a limited set of valid types for a template argument). I'm not sure it's that easy to tell them apart, so I'd like to get some more insights into this. To take the examples above, what if you do: concept OwnershipPolicy // In the make-believe langage that has support for concepts { // Define the concept here } template class smart_ptr { ... }; Here, the policy parameter has to model the OwnershipPolicy concept. If we take the definition of policy in MC++D, doesn't this sound like concepts (at least when it comes to UDTs)? The interface doesn't even have to be specified as exact types, but might specify that e.g. some function returns a result that is convertible to something else. It seems to me that these are quite similar: Policy - Policy implementation Concept - Model of the concept Regards, Terje [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top David B. Held Guest Posted: Sat Aug 28, 2004 11:02 am    Post subject: Re: Policies Vs. concepts Terje Sletteb=F8 wrote: Quote: [...] One might also say that a concept defines a set of types, e.g. Assignable is the set of types satisfying the requirements of the Assignable concept. [...] After writing a rather forceful and convincing argument for why Policies and Concepts are different, I've come to the conclusion that they are, more or less, the same. I would say that a Policy is a special type of Concept that defines a *component* type, rather than a free-standing type. Otherwise, they're basically the same thing. Dave [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top David B. Held Guest Posted: Sat Aug 28, 2004 11:03 am    Post subject: Re: Policies Vs. concepts David Abrahams wrote: Quote: [...] A policy is a concrete type that is used to control the features or behavior of another type. A *specific* policy is a concrete type. Quote: For example, the Allocator argument to std::vector is a type that supplies the memory management behavior of the resulting vector. The Allocator argument is a Policy that is a Concept. The Allocator Policy defines an interface for types which can be used as allocators, which is essentially the same as defining an interface for Sequences which determines which types qualify as such. Dave [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top David Abrahams Guest Posted: Mon Aug 30, 2004 10:58 am    Post subject: Re: Policies Vs. concepts "David B. Held" <dheld (AT) codelogicconsulting (DOT) com> writes: Quote: David Abrahams wrote: [...] A policy is a concrete type that is used to control the features or behavior of another type. A *specific* policy is a concrete type. For example, the Allocator argument to std::vector is a type that supplies the memory management behavior of the resulting vector. The Allocator argument is a Policy that is a Concept. No it is not. The allocator argument is a type argument. This is very clear from template <typename T, typename Allocator> struct vector; That type must satisfy the "allocator" concept. 20.1.5 (lib.allocator.requirements) details the allocator requirements. The allocator *parameter* is used as a policy to determine the vector's behavior. Quote: The Allocator Policy defines an interface for types which can be used as allocators, which is essentially the same as defining an interface for Sequences which determines which types qualify as such. Sorry, Dave, but you are very confused. CopyConstructible is a concept, not a policy. There's a clear distinction. Policies *are* concrete types. If the literature you've read has not come out and clearly said that type parameters used as policies have to satisfy particular concepts, then it is lacking. That doesn't make Policies equal to Concepts. I can write a function template that requires one of its function arguments to be an instance of a type satisfying Allocator requirements. That doesn't mean the type is being used as a policy. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Arkadiy Vertleyb Guest Posted: Tue Aug 31, 2004 10:09 am    Post subject: Re: Policies Vs. concepts David Abrahams <dave (AT) boost-consulting (DOT) com> wrote Quote: Sorry, Dave, but you are very confused. CopyConstructible is a concept, not a policy. There's a clear distinction. Policies *are* concrete types. If the literature you've read has not come out and clearly said that type parameters used as policies have to satisfy particular concepts, then it is lacking. That doesn't make Policies equal to Concepts. I can write a function template that requires one of its function arguments to be an instance of a type satisfying Allocator requirements. That doesn't mean the type is being used as a policy. Can't we just say that concepts play the same role in temlates as interfaces play in old good runtime polymorphism? At the same time policies have a lot of analogy with the "Strategy" design pattern from the Go4 book. "policies have to satisfy particular concepts" looks like direct translation of "classes have to implement particular interfaces". Confusing concepts with policies is similar to confusing interfaces with concrete classes implementing these interfaces. Regards, Arkadiy [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top David B. Held Guest Posted: Tue Aug 31, 2004 10:18 am    Post subject: Re: Policies Vs. concepts David Abrahams wrote: Quote: "David B. Held" <dheld (AT) codelogicconsulting (DOT) com> writes: David Abrahams wrote: [...] For example, the Allocator argument to std::vector is a type that supplies the memory management behavior of the resulting vector. The Allocator argument is a Policy that is a Concept. ;) No it is not. The allocator argument is a type argument. This is very clear from template <typename T, typename Allocator> struct vector; That type must satisfy the "allocator" concept. 20.1.5 (lib.allocator.requirements) details the allocator requirements. The allocator *parameter* is used as a policy to determine the vector's behavior. I would say that "typename Allocator" names a Policy which must conform to the Allocator concept, and that the actual argument passed to an instantiation of vector is an *instance* of the policy in the same way that vector is a model of Random Access Container. And I don't see why that is a bad way to look at things. Quote: The Allocator Policy defines an interface for types which can be used as allocators, which is essentially the same as defining an interface for Sequences which determines which types qualify as such. Sorry, Dave, but you are very confused. CopyConstructible is a concept, not a policy. I agree. In another post I added the caveat that a Policy must also specify a component of another type. Since most people don't compose types with CopyConstructible, it makes sense to call it a Concept but not a Policy. Quote: There's a clear distinction. Policies *are* concrete types. I think it is the language that is very confused. And I think that the vector::allocator example simply adds to the confusion because we have a Policy that has the same name and function as a Concept. I think a more illustrative example is something like SmartPtr::OwnershipPolicy. An *instance* of an OwnershipPolicy must provide functions like release(), etc. Or, you could say that if op is an OwnershipPolicy, the expression: op.release(); is valid. Look familiar? So it is true that we call things like op "policies", but I think that is simply sloppiness due to a cloudy understanding of what exactly policies are. I think we should call OwnershipPolicy the Policy, and op an "instance" of the policy (in total analogy to a "model" of a Concept). Quote: If the literature you've read has not come out and clearly said that type parameters used as policies have to satisfy particular concepts, then it is lacking. And what literature does not make this error of omission? Your new book, perhaps? ;) Quote: That doesn't make Policies equal to Concepts. I can write a function template that requires one of its function arguments to be an instance of a type satisfying Allocator requirements. That doesn't mean the type is being used as a policy. Right, and I would not argue that. I would say that because the function argument is not being used to compose a type (though one might pedantically attempt to argue that it is composing the function type itself, but that's not quite what I mean, and I think that's easy to see), that it is not an instance of a Policy. I think the distinction is really a philosophical one. Do we say that Policies conform to some Concept, or that Policies *are* that Concept, and it is instances of the policy which are the concrete types? Unfortunately, I don't think there is enough literature on the matter to decide it decisively. However, I will simply argue that the latter philosophy is better because of parsimony. If we say that Policies conform to some Concept, then in may real-world instances, that Concept is unnamed, and we are left with the awkward situation that a Policy is restricted by an anonymous Concept. On the other hand, if we say that Policies define the Concept (which seems purer to me, by the way), then we have a convenient analogy to Concepts, and nobody is left without a name. Dave [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze@gabi-soft.fr Guest Posted: Tue Aug 31, 2004 7:24 pm    Post subject: The meaning of concept, was: Re: Policies Vs. concepts David Abrahams <dave (AT) boost-consulting (DOT) com> wrote [...] Quote: That type must satisfy the "allocator" concept. [...] Quote: CopyConstructible is a > concept, not a policy. I'm pretty sure I understand what you mean by concept here, and I think that the word is becoming widely used in this sense, but is it a good choice? In normal English, at least as I understand it, a "concept" is a lot vaguer than what you mean -- if I talk about the concept of assignable (at least in normal English), then I am talking about a means of making it take the value of another object, be it by means of an operator=, a member function assign, or even memcpy (assuming that memcpy has the correct semantics for the object). I'll admit that this is just a vague thought, but I like vocabulary to be as precise as possible. Also, I don't really have an alternative to suggest, and even if I did, it might already be too late (although a few quick glances at the standard didn't show it referring to them as concepts). Just wondering... -- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top David Abrahams Guest Posted: Tue Aug 31, 2004 7:51 pm    Post subject: Re: Policies Vs. concepts "David B. Held" <dheld (AT) codelogicconsulting (DOT) com> writes: Quote: David Abrahams wrote: "David B. Held" <dheld (AT) codelogicconsulting (DOT) com> writes: David Abrahams wrote: [...] For example, the Allocator argument to std::vector is a type that supplies the memory management behavior of the resulting vector. The Allocator argument is a Policy that is a Concept. ;) No it is not. The allocator argument is a type argument. This is very clear from template <typename T, typename Allocator> struct vector; That type must satisfy the "allocator" concept. 20.1.5 (lib.allocator.requirements) details the allocator requirements. The allocator *parameter* is used as a policy to determine the vector's behavior. I would say that "typename Allocator" names a Policy It names a policy parameter. It's a policy parameter because of the way it's used. Quote: which must conform to the Allocator concept, Right. Quote: and that the actual argument passed to an instantiation of vector is an *instance* of the policy Wrong. It's a model of the Allocator concept. It is _used_ as the vector's allocation policy. Quote: in the same way that vector is a model of Random Access Container. And I don't see why that is a bad way to look at things. Because it conflates valuable distinctions. Distinctions are only powerful if they, um, distinguish things. Quote: The Allocator Policy defines an interface for types which can be used as allocators, which is essentially the same as defining an interface for Sequences which determines which types qualify as such. Sorry, Dave, but you are very confused. CopyConstructible is a concept, not a policy. I agree. In that case, concepts are not the same things as policies. QED. Quote: In another post I added the caveat that a Policy must also specify a component of another type. I can't even parse that. Quote: Since most people don't compose types with CopyConstructible, it makes sense to call it a Concept but not a Policy. It makes sense to call it a concept because it is described as a concept, and the term of art "concept" was invented to denote sets of requirements like CopyConstructible. The term of art "policy" was invented to denote a role played by a type in composing other types... or something like that (the best definition of the term "policy" I can find is still pretty fuzzy, but that's the gist). Quote: There's a clear distinction. Policies *are* concrete types. I think it is the language that is very confused. It is, the way you're using it. When you say "Masters in Computer Science" is the same category of term as "Senior Software Engineer" you end up with confused language, too. It's an analogous confusion. Quote: And I think that the vector::allocator example simply adds to the confusion because we have a Policy that has the same name and function as a Concept. I think a more illustrative example is something like SmartPtr::OwnershipPolicy. An *instance* of an OwnershipPolicy must provide functions like release(), etc. Then OwnershipPolicy is a concept. Quote: Or, you could say that if op is an OwnershipPolicy, the expression: op.release(); is valid. Look familiar? So it is true that we call things like op "policies" op may be a policy in the context of some particular use. Quote: but I think that is simply sloppiness due to a cloudy understanding of what exactly policies are. I think we should call OwnershipPolicy the Policy, and op an "instance" of the policy (in total analogy to a "model" of a Concept). If you do that, you simply undermine the power of the terminology. OwnershipPolicy is a concept. A given model of the concept may be used as a policy by some smart_ptr template. Quote: If the literature you've read has not come out and clearly said that type parameters used as policies have to satisfy particular concepts, then it is lacking. And what literature does not make this error of omission? Your new book, perhaps? No, our new book doesn't cover policies, in part because we couldn't find any rigorous formalisms underlying the idea of policies or policy-based design. PBD appears to be a kind of craft, which is fine -- but we couldn't find anything useful to add to what's already been written. Furthermore, it doesn't seem directly relevant to template metaprogramming, which is after all the subject of the book. Quote: That doesn't make Policies equal to Concepts. I can write a function template that requires one of its function arguments to be an instance of a type satisfying Allocator requirements. That doesn't mean the type is being used as a policy. Right, and I would not argue that. I would say that because the function argument is not being used to compose a type (though one might pedantically attempt to argue that it is composing the function type itself, but that's not quite what I mean, and I think that's easy to see), that it is not an instance of a Policy. Therefore policy-ness has to do with the _role_ played by a type. Concept-ness does not: it _only_ has to do with sets of requirements. QED. Quote: I think the distinction is really a philosophical one. Do we say that Policies conform to some Concept, or that Policies *are* that Concept, and it is instances of the policy which are the concrete types? The former. Quote: Unfortunately, I don't think there is enough literature on the matter to decide it decisively. However, I will simply argue that the latter philosophy is better because of parsimony. Parsimony is not helpful when it conflates two different ideas. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Gabriel Dos Reis Guest Posted: Wed Sep 01, 2004 3:00 am    Post subject: Re: The meaning of concept, was: Re: Policies Vs. concepts [email]kanze (AT) gabi-soft (DOT) fr[/email] writes: [...] Quote: I'll admit that this is just a vague thought, but I like vocabulary to be as precise as possible. You mean like "class"? -- Gabriel Dos Reis [email]gdr (AT) integrable-solutions (DOT) net[/email] [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top David Abrahams Guest Posted: Wed Sep 01, 2004 9:58 am    Post subject: Re: The meaning of concept, was: Re: Policies Vs. concepts [email]kanze (AT) gabi-soft (DOT) fr[/email] writes: Quote: David Abrahams <dave (AT) boost-consulting (DOT) com> wrote in message news:<uu0ultlb4.fsf (AT) boost-consulting (DOT) com>... [...] That type must satisfy the "allocator" concept. [...] CopyConstructible is a > concept, not a policy. I'm pretty sure I understand what you mean by concept here, and I think that the word is becoming widely used in this sense, but is it a good choice? Take it up with Alex Stepanov. ;-> http://www.sgi.com/tech/stl/drdobbs-interview.html It's too late to change; "concept" is well-established in the generic programming literature. Quote: In normal English, at least as I understand it, a "concept" is a lot vaguer than what you mean -- So are "void", "class", "template", and even "function." Quote: if I talk about the concept of assignable (at least in normal English), then I am talking about a means of making it take the value of another object, be it by means of an operator=, a member function assign, or even memcpy (assuming that memcpy has the correct semantics for the object). I'll admit that this is just a vague thought, but I like vocabulary to be as precise as possible. Also, I don't really have an alternative to suggest, and even if I did, it might already be too late (although a few quick glances at the standard didn't show it referring to them as concepts). You could say "Abstract Data Type Plus Complexity Requirements" :( -- Dave Abrahams Boost Consulting http://www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Nicola Musatti Guest Posted: Wed Sep 01, 2004 8:42 pm    Post subject: Re: The meaning of concept, was: Re: Policies Vs. concepts [email]kanze (AT) gabi-soft (DOT) fr[/email] wrote in message news:<d6652001.0408310116.7bfc2a0e (AT) posting (DOT) google.com>... Quote: David Abrahams <dave (AT) boost-consulting (DOT) com> wrote in message news:<uu0ultlb4.fsf (AT) boost-consulting (DOT) com>... [...] CopyConstructible is a > concept, not a policy. I'm pretty sure I understand what you mean by concept here, and I think that the word is becoming widely used in this sense, but is it a good choice? In normal English, at least as I understand it, a "concept" is a lot vaguer than what you mean -- if I talk about the concept of assignable (at least in normal English), then I am talking about a means of making it take the value of another object, be it by means of an operator=, a member function assign, or even memcpy (assuming that memcpy has the correct semantics for the object). I'll admit that this is just a vague thought, but I like vocabulary to be as precise as possible. Also, I don't really have an alternative to suggest, and even if I did, it might already be too late (although a few quick glances at the standard didn't show it referring to them as concepts). But in the context of C++ programming the term 'concept' as described by Dave A. does have a precise meaning. See http://www.sgi.com/tech/stl/stl_introduction.html Cheers, Nicola Musatti [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.