C++ Design Patterns – Are Utility Classes with Static Members an Anti-Pattern?

Short answer : You're mixing before-compile-time and compile-time concepts that have similarities in their purpose. Interfaces (abstract classes and all the object-orientation paradigm implementation) are inforced at compile-time. Concepts are the same idea but in the context of generic programming that in C++ occurs BEFORE compile time. We don't have that last feature yet.

But let me explain from the beginning.

Long answer:

In fact, Concepts are just language inforcement and "made easier for the programmer" of something already present in the language, that you could call "duck typing".

When you pass a type to a template function, that is a generic function from which the compiler will generate real (inline) code when called, that type needs to have some properties (traits?) that will be used in the template code. So it's the idea of duck-typing BUT it's all generated and done at compile time.

What happens when the type don't have the required properties?

Well, the compiler will know that there is a problem only once the generated code from the template is compiled and fail. That means that the error that will be generated will be an error inside the template code, that will be shown to the programmer as his error. Also, the error will have tons of informations because of the meta informations provided in case of template code generation, to know which instantiation of the template we're talking about.

Several problems with that : first, most of the time, template code is library code and most programmers are users of library code, not writers of library code. That means that this kind of cryptic error is really hard to understand when you don't understand how the library is written (not just the design, how it is really implemented). The second problem is that even when the programmer did write the template code, the reasons of failure might still be obscure because the compiler will be able to tell that there is a problem too late : when the generated code is being compiled. If the problem is relative to the type properties, then it should check it even before generating the code.

That's what Concepts allow (and are designed for) : to allow the (generic code) programmer to specify the properties of types being passed as template parameters and then to allow the compiler to provide explicit errors in case the provided types don't fulfill the requirements.

Once the check is successful, the code will be generated from the template and then compiled, certainly successfully.

All the Concept checking occurs exclusively before compile-time. It checks types themselves, not object's types. There is no object before compile-time.

Now, about "interfaces".

When you create an abstract or virtual base type, you're allowing code using it to manipulate objects of the child types without knowing their real implementations. To enforce this, the base type expose members that are virtual and might be (or have to be) overloaded by the child types.

That means that the compiler can check at compile time that all objects passed to a function requiring a reference to the base class have to 1. be of one of the child types of the base class, 2. that child type have to have implementations of virtual pure functions declared in base classes if any.

So at compile-time, the compiler will check the interfaces of object's types and report if something is missing.

It's the same idea than Concepts, but it occurs too late, as said in the Concept description. It occurs at compile-time. We're not in generic code (template code), we're after it have been processed and it's already too late to check if the types fulfill generic requirements, that cannot be exposed by virtual base classes. In fact, the whole object orientation paradigm implementation in C++ don't even exists when the template code is being processed. There is no objects (yet). That's

Classes describe constraints on objects to be used to check requirements for functions manipulating those objects. Concepts describe constraints on types (including classes) to be used to check requirements for generic code to generate real code from those types and generic code combination.

So, again, it's the same "sanity check", but in another layer of the language, that is templates. Templates are a full (turing complete) language that allow meta-programming, programming types even before they appear in the compiled code. It's a bit like scripting the compiler. Let's say you can script it, classes are just values manipulated by the script. Currently, there is no way to check constraints on these values other than to crash the script in a non-obvious way. Concepts are just that : provide typing on these values (that in generated code are types). Not sure I'm clear...

Another really important difference between virtual base classes and Concepts is that the first one forces a strong relation between types, making them "bound by blood". While template metaprogramming allow "duck typing" that Concepts just allow to make requirements clearer.

I'm seeing a lot of instantiable classes in the C++ and Java world that don't have any state.

Some possibile reasons to create classes without ivars of their own:

• State is or could be contained in a superclass.

• Class implements some interface and needs to be instantiable so that instances can be passed to other objects.

• Class is intended to be subclassed.

• Handy way to group related functions. (Yes, there may be better or different ways to do the same.)

Am I getting this wrong? Is it not OOP if I don't put everything into objects (i.e. instantiated classes)?

OOP is a paradigm, not a law of nature. There are some languages where everything is an object, so you really don't have a choice. Other languages (e.g. C) don't provide any support for OOP at all, but you can still program in an object oriented style. I'd say you can have OOP if you don't do everything in classes... you might say that you just have less OOP in that case.