ACCU Buttons

Hugo Arregui, Carlos Castro and Daniel Gutson work out how to combine two useful techniques.

Aspect Oriented Programming (AOP) is a programming paradigm that makes possible to clearly express programs separated into ‘aspects’, including appropriate isolation, composition and reuse of the aspect code [Kiczales97]. AOP defines weaving as the process of composing the aspects into a single entity.

Independently, there are situations in which a base class needs to know its subclass, e.g. for type-safe downcasts. The Curiously Recurring Template Pattern (CRTP) is a C++ idiom in which a class X derives from a class template instantiation using X itself as template argument [Abrahams04]. This way, the base class can know the derived type.

Both AOP and the CRTP are widely adopted C++ programming techniques. In particular, there exists an AOP easy implementation using templates [Spinczyk05]. However, a C++ grammar incompatibility arises when combining AOP and CRTP. While there exists a C++ dialect called AspectC++ [Spinczyk05], we don’t evaluate in this work its ability to combine AOP and CRTP since it requires its own compiler extensions and so its not standard C++. Here we look at a simple solution implemented in standard C++ that addresses the issue without any overhead penalty.

Problems combining AOP + CRTP

There are some situations where combining the benefits of AOP and CRTP are desirable; however, as we will show below, some problems arise when applying together the individual standard procedures of each technique.

The code in Listing 1 shows an attempt of adding functionality, through aspects, to a base class named Number.

We can observe that the return type of ArithmeticAspect’s operator + and - needs to know the ‘complete type’ (FULLTYPE) when trying to extend the base class functionality through operator overloading. We will address this issue in the following sections.

A minimal solution

The basic principle of this solution does not differ in essence from the traditional solution mentioned before.

Problem

Number takes the place of the last aspect in the aspects list. However, Number itself needs to know (as a template template argument) the aspects list, to which it itself belongs, leading to a ‘chicken or egg’ grammatical dilemma.

For example, if Number knew the complete type, it could use it as a return type for its operators as shown in Listing 2.

This shows the weaving of a single aspect with CRTP, which works perfectly:

LogicalAspect<ArithmeticAspect<Number<??>>>

On the other hand, this exposes the problem when trying to weave one additional aspect, since it requires a template template argument, which the aspects lists can’t grammatically fulfill as coded above.

We present two solutions: the first being the simplest using C++11’s template alias [Reis
], and the second using variadic templates (templates that take a variable number of arguments, recently introduced in C++11 [Gregor]) as the only C++11’s feature, which in turn, can also be easily implemented in C++98 as well. Both use a common language idiom introduced next, which aims to be used as a library providing a friendly syntax and reduced reusable code.

The proposed language idiom

A possible solution would be to apply some handcrafted per-case base template aliases, as shown below:

Although this does the trick it tends to be impractical, and also would increment linearly the number of related lines of code in terms of the amount of combinations to be used, which would cause a copy-paste code bloat.

However, we will look for a more generic way to address this issue, avoiding drone code cloning, and being able to encapsulate the method into a library.

Therefore, in order to provide a user-oriented and easy to use library, we'll use C++11’s new variadic-templates so we can cleanly express our intention: to ‘decorate’ the base class with a list of aspects. An example of what we intend to achieve is shown below:

Decorate<Number>::with<ArithmeticAspect,
LogicalAspect>

The skeleton of the Decorate class is shown in Listing 3, the details of which will vary in the solutions below.

Binder encapsulates an aspect (as a template template argument) within a complete type Binder<Aspect>. Additionally, it enables us to do a ‘bind’ operation to the next aspect or base class, by accessing to the Binding inner class.

The way in which Binder finally allows us to construct the whole type is shown below.

Let’s analyze step-by-step this listing (from the innermost to the outermost definition):

Binder<LogicalAspect> uses the second definition, it just provides a complete type for the aspect with a possibility to bind to another complete type

Binder<ArithmeticAspect, Binder<LogicalAspect>> uses the first definition.

The binding generates a Binder to the ArithmeticAspect, and binds it to Binder<LogicalAspect>::Binding<T> generating a template template argument combining both aspects. (In short, Binder generates a template template argument – combining Arithmetic with Logical aspects – to be used in the base class).

Finally, the type is injected into the base Number class.

Since such an implementation is not immediately obvious, we have provided a simplified version in Listing 8 for illustration.

Now we’ve got a Binder that implements the weaving of aspects and finally inject them into the base class.

Applying the list of Aspects to the Number class

The only remaining detail is to apply our Bind class to the list of aspects. To do this, we define a helper structure called Apply, that recursively applies the Binder class to each aspect, as shown in Listing 9.

Final comments

We think that the solution to the problem exposed in this article could become straightforward by enhancing the language with a reserved keyword to get the full type. We suggest to consider this problem for the next revision of the language standard.