|
| 1 | +Directives |
| 2 | +========== |
| 3 | + |
| 4 | +The :mod:`cpp-netlib` uses a technique for allowing message-passing |
| 5 | +semantics in a chainable fashion in the form of directives. The basic |
| 6 | +concept for directives is, in a general sense, an encapsulated |
| 7 | +transformation that can be applied to objects that abide by the |
| 8 | +directive protocol. |
| 9 | + |
| 10 | +Using the object-oriented notion of message passing, where an object |
| 11 | +accepts a message (usually a function call) we define a simple DSEL in |
| 12 | +order for the protocol to be supported by certain object types. In the |
| 13 | +:mod:`cpp-netlib` the protocol implemented is similar to that of the |
| 14 | +standard iostream formatting system: |
| 15 | + |
| 16 | +.. code-block:: c++ |
| 17 | + |
| 18 | + object << directive1(...) |
| 19 | + << directive2(...) |
| 20 | + ... |
| 21 | + << directiveN(...); |
| 22 | + |
| 23 | +In :mod:`cpp-netlib` the directives are simple function objects that |
| 24 | +take a target object as reference and returns a reference to the same |
| 25 | +object as a result. In code the directive pattern looks like the |
| 26 | +following: |
| 27 | + |
| 28 | +.. code-block:: c++ |
| 29 | + |
| 30 | + struct directive_type { |
| 31 | + template <class Input> |
| 32 | + Input & operator()(Input & input) const { |
| 33 | + // do something to input |
| 34 | + return input; |
| 35 | + } |
| 36 | + }; |
| 37 | + |
| 38 | +To simplify directive creation, usually factory or generator functions |
| 39 | +are defined to return concrete objects of the directive's type. |
| 40 | + |
| 41 | +.. code-block:: c++ |
| 42 | + |
| 43 | + inline |
| 44 | + directive_type directive(...) { |
| 45 | + return directive_type(); |
| 46 | + } |
| 47 | + |
| 48 | +The trivial implementation of the directive protocol then boils down |
| 49 | +to the specialization of the shift-left operator on the target type. |
| 50 | + |
| 51 | +.. code-block:: c++ |
| 52 | + |
| 53 | + template <class Directive> |
| 54 | + inline target_type & operator<< |
| 55 | + (target_type & x, Directive const & f) { |
| 56 | + return f(x); |
| 57 | + } |
| 58 | + |
| 59 | +.. todo:: |
| 60 | + |
| 61 | + An example using a directive. |
| 62 | + |
| 63 | +The rationale for implementing directives include the following: |
| 64 | + |
| 65 | + * **Encapsulation** - by moving logic into the directive types the |
| 66 | + target object's interface can remain rudimentary and even hidden |
| 67 | + to the user's immediate attention. Adding this layer of |
| 68 | + indirection also allows for changing the underlying |
| 69 | + implementations while maintaining the same syntactic and semantic |
| 70 | + properties. |
| 71 | + * **Flexibility** - by allowing the creation of directives that are |
| 72 | + independent from the target object's type, generic operations can |
| 73 | + be applied based on the concept being modeled by the target |
| 74 | + type. The flexibility also afforded comes in the directive's |
| 75 | + generator function, which can also generate different concrete |
| 76 | + directive specializations based on parameters to the function. |
| 77 | + * **Extensibility** - because the directives are independent of the |
| 78 | + target object's type, new directives can be added and supported |
| 79 | + without having to change the target object at all. |
| 80 | + * **Reuse** - truly generic directives can then be used for a broad |
| 81 | + set of target object types that model the same concepts supported |
| 82 | + by the directive. Because the directives are self-contained |
| 83 | + objects, the state and other object references it keeps are only |
| 84 | + accessible to it and can be re-used in different contexts as well. |
| 85 | + |
| 86 | +Extending a system that uses directives is trivial in header-only |
| 87 | +systems because new directives are simply additive. The protocol is |
| 88 | +simple and can be applied to a broad class of situations. |
| 89 | + |
| 90 | +In a header-only library, the static nature of the wiring and chaining |
| 91 | +of the operations lends itself to compiler abuse. A deep enough |
| 92 | +nesting of the directives can lead to prolonged compilation times. |
0 commit comments