Overview

For templatised functions and classes, the input template arguments usually have little or no restriction on the class that can be used, e.g.

   1 template <typename T>
   2 void f(T input) {
   3     // use some aspect of T's interface
   4 }

Of course the compile will fail if you try to use an input type, T, that doesn't have the specialised interface you want, but the compile time error message is often very verbose and its difficult to find the error. An idea which is merging into the c++ mainstream as well as that used by the boost concept checking library is to characterise common behaviours into _Concepts_. A simplified version of this is utilised here.

Compiling & Linking

Include the following at the top of any translation unit:

   1 #include <ecl/concepts.hpp>
   2 
   3 // The concept definition/validation classes.
   4 using ecl::BluePrintConcept;
   5 using ecl::ContainerConcept;
   6 using ecl::SignedByteContainerConcept;
   7 using ecl::UnsignedByteContainerConcept;
   8 using ecl::NullaryFunctionConcept;
   9 using ecl::StreamConcept;
  10 using ecl::InputCharDeviceConcept;
  11 using ecl::OutputCharDeviceConcept;
  12 using ecl::InputOutputCharDeviceConcept;
  13 using ecl::InputByteDeviceConcept;
  14 using ecl::OutputByteDeviceConcept;
  15 using ecl::InputOutputByteDeviceConcept;

Usage

• Implementing Concepts

Concepts

Existing concepts in the ecl include:

@section conceptsList Existing Concepts

• BluePrints - checks for blueprint functionality as defined in ecl_utilities.

• Containers - also bytecontainer, simple checks for basic prerequisite container methods.

• NullaryFunctions - function objects which require no arguments in execution.

• Streams - any class with basic char streaming capabilities.

• Devices - device functionalities compatible to those in ecl_devices.