CODEWITHSUNDEEP
c++
AlwaysLearning
AlwaysLearning

Reputation: 8051

Are policies concepts?

While working through Section 1 of Modern C++ Design (Alexandrescu, 2001) the following thought occurred to me: aren't policies just concepts?

If I understand correctly, a concept is a set of requirements on the interface of the classes implementing the concept.

A policy is also a specification that policy classes must satisfy. (though some policy classes can provide an enriched interface, I am not sure whether this takes a policy out of the realm of being a concept)

Upvotes: 3

Views: 281

Answers (2)

Maksim Solovjov
Maksim Solovjov

Reputation: 3157

You need to consider what are the aims of both concepts and policies.

Concepts establish strong assumptions about the class, both syntactically and semantically. For example, Comparable implies presence of comparison operators for the type as well as that certain axioms hold, i.e. a == b -> a is equivalent to b, rather than any other implementation of operator==. Strong assumptions make code more predictable.

Policies, on the other hand, establish the actual behaviour of the class, with an emphasis on interchangeability. Every individual implementation of a policy does encompass one or more concepts; however, the variations of a policy that you plug into a class only share constraints. For example (pseudocode):

// constraint Lockable -> has Lock() and Unlock() methods

// concept RealLockable -> constrained by Lockable, Lock() blocks other threads
// concept FakeLockable -> constrained by Lockable, Lock() does nothing

class FakeLock; // a policy that embodies the concept FakeLockable
class Lock; // a policy that embodies the concept RealLockable
class RecursiveLock; // a policy that can also embody the concept of RealLockable

template<class T, Lockable Lock> // constrained by Lockable
class Queue;

A policy is an implementation technique to alter the behaviour of a target class. A concept is an explicit tool for establishing assumptions:

template<Comparable T>
class PriorityQueue;

Comparable T would not be a policy, in my opinion, because when you specify PriorityQueue<int> or PriorityQueue<double> you don't aim to change the behaviour: on the conceptual level, all these queues do is allow you to access min or max element in constant time. However, with some future syntax you can claim that T embodies mathematically correct semantics, i.e. a < b -> b > a, and then Comparable T will be a concept.

In the end, every class, policy or not, represents a concept or two. Classes introduce concepts implicitly, concepts document them explicitly.

Upvotes: 4

πάντα ῥεῖ
πάντα ῥεῖ

Reputation: 1

As far as what I understood from that book, policy based design isn't absolutely precise about a distinction from concepts. Merely because the latter term came up later historically.

Alexandrescu's policies are an early predecessor of what's understood as concepts nowadays.

Though there's a line:

Concepts won't ever change instantiation layout, while policies as introduced in the book could.

Somewhat I think a concept describes an interface, while a policy might participate in an interfaces implementation.

Upvotes: 1

Related Questions