Illustrative example

In C++20 we have std::span with T and Extent template parameters, where Extent can be either some size_t value known at compile time or std::dynamic_extent which is basically (size_t)(-1) that represents some runtime value.

Suppose we have our own type-container with optionally provided compile-time size:

template <typename T, std::size_t Size>
class Container {
  ...
};

And some deduction guides for the type:

template <typename T, std::size_t Size>
Container(T (&)[Size]) -> Container<T, Size>;

template <typename T, std::size_t Size>
Container(std::vector<T>) -> Container<T, std::dynamic_extent>;

And a member function that returns the size of the container:

constexpr std::size_t size() {
  if constexpr (Size == std::dynamic_extent) {
    return size_; // some member value that is set in the constructor
  } else {
    return Size;
  }
}

This pattern of returning a value in case it is known at compile-time with if constexpr is pretty useful and simple but not very handy because if constexpr is not an expression that returns value and thus has to be wrapped into a function for each bit of the logic that requires reading the value. We can do better.

Wrapping the value

A very simplified example of a wrapper that could simplify the code above is something like this:

template <typename T, T Dynamic, T Value = Dynamic>
class CompileRuntimeValue {
  constexpr static inline bool kStatic = Value != Dynamic;
  constexpr static inline bool kDynamic = !kStatic;

 public:
  constexpr CompileRuntimeValue()
    requires(kStatic)
  = default;

  constexpr CompileRuntimeValue()
    requires(kDynamic)
  = delete;

  constexpr CompileRuntimeValue(T value)
    requires(kDynamic)
  : value_(std::move(value)) {}

  constexpr T operator*() {
    if constexpr {
      return value_;
    } else {
      return Value;
    }
  }

 private:
  struct Empty{};
  [[no_unique_address]] std::conditional_t<kDynamic, T, Empty> value_;
};

By wrapping the value into a type with a specific indicator that the value is dynamic allows to write the if constexpr once for all of the uses of compile/run time value.

Any CompileRuntimeValue object could also be marked with [[no_unique_address]] to hint the compiler that the value stored in the type itself. And applying that to the Container class:

template <typename T, std::size_t Size>
class Container {
  ...
  constexpr std::size_t size() {
    return *size_;
  }
  ...

 private:
  // initialized only in 'runtime' constructors, takes no space when Size is a compile-time value
  [[no_unique_address]] CompileRuntimeValue<std::size_t, std::dynamic_extent, Size> size_;
};

Electrons

In the beginning was an electron. I believe this is the best place to start since electrons are in a way the interface to electricity as a phenomenon. The mathematical model here is electrical field. Its the strength of the field that allows us predict the movement of electric charge. And along with electric charge the movement of energy and more importantly information.

Since the discovery of electron almost one and a half centuries ago electric current has become almost the one and only way to transmit and store information. On this level the interface consists of two operations:

• capacitance - to store electric charge and create voltage;
• current - to move the charge from one place to another.

There are many ways of manufacturing batteries, different types of wires, but that is really not important from the perspective of interfacing the electricity. The right point of view for now is that the laws of physics is the implementation detail. Or ultimately the Universe itself.

Atoms

One level up are atomic-level structures and crystalline solids. Thanks to Pauli exclusion principle, fermions and in particular electrons can not occupy the same quantum state part of which is the potential energy that an electron has relative to the nucleus.

This means that in some configurations of atoms there would be electrons on energy levels high enough that relatively small external amounts of energy or thermal exitations would be able to detach electron away from the nucleus. The act of electron ‘flying away from its temporary home’ is move from valency band to conduction band. And it is crucial as it is the basic principle behind one of the versatile inventions of the 20st century - semiconductors.

Between these two levels could be an energy gap of a particular size. This size is how much the energy of the solid needs to be increased to make it conduct. Different materials can be manufactured so that this energy gap is of specific size and therefore make the simplest logical element switch for electric current. The obvious property of this good abstraction is:

• switch - do or do not allow current to flow based on some external state.

Transistors

Semiconductors are fine by themselves but along with some engineering tricks they are used to manufacture more intricate devices - transistors.

The basic structure needed to make a transistor is PN-junction which occurs on the boundary of two types of semiconductors. These include:

• n-type. Manufactured by doping a crystal (silicon for ex. with four electrons in its valence band) with an element with a larger number of valence electrons (for silicon this number is five) which due to crystallic structure of the material makes the leftover electrons free (one that does not fit the four connections of the crystal). These electrons pass the charge when the crystal is connected to a battery;
• p-type. Here a crystal is doped with an element with a fewer valence electrons. This way the type of conductivity is via the free electron holes. These holes pass the charged electrons through when the semiconductor is connected to a battery.

Connecting anode to the p-type end of a semiconductor and catode to the n-type end (forward bias), we get a diode. Diode acts as a one-way conductor because the internal flow of electrons from n-type to p-type parts of the whole semiconductor creates an area around the PN-junction which acts as an insulator. This way, when anode is connected the n-type end and catode to the p-type end (reverse bias), only high-energy electrons are able to surpass the insulation layer thus requiring a large voltage.

Now things need to be only a bit more complex. We need to make a semiconductor out of three parts and it can be done in a couple of ways:

• n-type connected to p-type connected to n-type;
• p-type connected to p-type connected to p-type.

Both do not conduct electricity in neither forward nor reverse bias. To make this structure useful we need to add a third terminal which would either inject electrons to the middle part of the semiconductor or shrink the insulation area by changing voltage between the two PN-junctions. Thus the main function of a transistor is:

• amplify - regulate the amount of current or act like a switch depending on control current or voltage

Logical circuits

This tier makes a bit larger leap through the levels of abstraction. The reason is that we are slowly moving away from the necessary physical devices towards the vast possibilities of an abstract design space. There are many ways of manufacturing logic gates either based on transistors or not, but the main goal of this operation is to create a set of binary logical elements which satisfies the criteria functional completeness. Inputs and outputs for these elements are represented by voltage.

The most basic devices are the unary NOT (inverter) and binary AND (conjunction) and OR (disjunction) and XOR (exclusive disjunction) gates. These represent the basic functions of binary logic and could be visualized via truth tables. To achieve functional completeness (which means having a set of gates that can be used to construct any binary function with any number of arguments) we need only a single gate. And none of the above is sufficient enough.

The bases for the binary logic in electric devices are NAND and NOR gates. One can proof that any binary function could be implemented in terms of one of these gates. And this is pretty much the main function of the logical circuits - being building blocks for more complex operations, so interface here is something like:

• perform arbitrary operations on binary numbers represented by distinct voltage levels using voltage or current as a controller

Some of the more specific applications of the logical gates include:

• flip-flops or latches - simplest stateful gate. Two inputs are used to manipulate the state bit on the output. The “stateful” here implies some clocking device that defines the possible frequency of the state transitions;
• counters and registers - a combination of flip-flops that represents a stored binary number which can be loaded or read;
• ALU (arithmetic logic unit) - general purpouse circuit that is designed to perform arithmetic operations on binary numbers.

Processors, memory, networking, other hardware

There it is. Out of the previous beautiful abstractions something more general-purpouse could be created. Again, specific CPU architectures here are not important. The principle is using stateful logical circuits to store a fixed amount of information and having a computing circuit to read from and write into the memory. Everything else here is a matter of interpretation.

• store information in binary form
• manipulate information in binary form

A specific CPU architecture exposes a set of instructions generic enough to express pretty much any computation. Instructions are represented by binary operation codes stored in memory. Basically this gives us a way to write a program and later execute it on a CPU or another hardware designed for different problems like displaying information or proxying it to other devices. There is also a lot more to unpack on this layer of abstraction by going deeper (c) into the specifics: memory management unit, caches, hardware parallelism etc.

The other hardware function that belongs to this section is networking. This is also a gargantuous topic that comes with its own abstraction layers like OSI, TCP/IP, wide variety of protocols. But to make the point of this discussion, we would only need a method of exchanging the information between processors. By providing a transmission medium like wires, air or optical fiber and a way of representing bits like different voltage levels, a modulated property of a electromagnetic wave, and photon detectors correspondingly, we unlock the next necessary part of the interface:

• send and receive information in binary

General-purpouse computers, APIs

The next and the most recent level is programs. Having got the variety of the tools to manipulate binary numbers we can abstract further and finally implement specific ideas in digital space. I think it is better to treat compilers, interpreters or programming languages as an implementation detail and to better focus on inter-application communication.

Now that there are programs that have some intelligence on their own, their communication protocols are the interface themselves. Let’s consider the main unit of work in the global network of computers currently - something like a web-server which is capable of handling a specific set of requests. Here the main decisions to make are the structure of a message passing between applications and the properties of the set of requests that the application could handle. The restrictions are that the message as well as the application interface has to be dynamic and flexible enough although that impacts performance a lot. It seems like the way to go for the modern apps is either binary format like protocol buffers along with gRPC or REST + JSON.

With all of that we can easily represent real-world actions by application-like actors and have basically achieved the complexity that allows to think about computations declaratively. The pinnacle of all the ladder of abstractions above is something like:

• perform arbitrary actions in an abstract space that also could be mappped onto the real world

…AI?

Well, actually it seems like the structure of application interfaces at the moment is still too rigid to become an implementation detail.

Maybe we will come together and develop a protocol generic enough to allow to easily integrate different independent applications without them knowing about each other. Maybe we will, as well as with many other hard tasks, employ neural networks to pass the responsibility for the answer onto the statistics. Maybe even the current solutions will proof to be sufficient enough.

Or maybe we will just discover a way to make strong AI. In any case, the greater goal of a good interface is to be transparent, understandable and obvious for all its consumers: for hardware, for software. And for us.

The C language has strict semantics for most of its expressions. That means pretty much any complex expression gets evaluated first and then the evaluated result is used as the value of the expression. For example, in the following snippet the function call gets evaluated even though its result is never used:

example1.h:

#include <stdio.h>

int a_or_b(int a, int b) {
    return a > 0 ? a : b;
}

int get_a() {
    puts(__func__);
    return 1;
}

int get_b() {
    puts(__func__);
    /* some expensive computation */
    return 2;
}

int main() {
    a_or_b(get_a(), get_b());
    /*
     * will print
        get_a
        get_b
     * in unspecified order
     */
}

Since all the functions here are computed in runtime and have external linkage, there is no way for compiler to know whether it is legitimate to remove a call from an expression.

There are languages which have lazy semantics by default and we could use one language construction to emulate it in plain C. This construction is logical short-circuiting.

The idea consists of:

• Separating the state we operate on in a number of objects which can besides store some information for error handling etc.
• Having operations on the state specified in terms of function that may fail (e.g. returning bool or anything which can indicate whether an arbitrary operation succeeded)

example2.h:

#include <stdio.h>
#include <stdbool.h>

struct Calculation {
    int state;
    char error[128];
};

bool operation1(struct Calculation* calculation) {
    puts(__func__);
    return true;
}

bool operation2(struct Calculation* calculation) {
    puts(__func__);
    return false;
}

bool operation3(struct Calculation* calculation) {
    puts(__func__);
    return true;
}

int main() {
    struct Calculation calculation;

    (operation1(&calculation), operation2(&calculation)) && operation3(&calculation);
    /*
     * will print
        operation1
        operation2
     */
}

The logical operations along with comma operator can help express complex chains of computations. In the example above operation1 is performed unconditionally and operation3 evaluation depends on the success of the operation2.

The enumeration could also be a means to pass runtime info to to type level with minimal overhead.
The both previous examples are focused on compile-time values, but with by adding a couple of runtime checks we can achieve more by taking some inspiration from a common pattern functional programming idea of implementing functions in terms of pattern matching.

atype.hpp:

/* let's pretend that this is a type we want to match on */
using type = int;

/* pattern matching is basically determining the state of a variable
   we'll need a list of possible states we are going to handle */
enum class int_state
{
    positive,
    negative,

    other
};

/* helper utility to associate types with state enums */
template<typename T>
struct get_state_t;

/* associate int with int_state */
template<>
struct get_state_t<int> { using type = int_state; };

/* convenience routine */
template<typename T>
using state_t = typename get_state_t<T>::type;

/* mapper from type value to its state */
template<typename T>
auto stateof(const T& value) -> state_t<T>;

atype.cpp:

/* definition of the state mapper for our type */
template<>
auto stateof<int>(const int &value) -> state_t<int>
{
    return value > 0 ? int_state::positive
         : value < 0 ? int_state::negative
         : int_state::other;
}

example3.hpp:

/* an interface visible to client code */
auto magic(int) -> int;

Somewhere in example3.cpp:

/* the real magic implementation */
template<int_state>
auto true_magic(int i) -> int;

/* implement the function in terms of pattern matching */
template<>
auto true_magic<int_state::positive>(int i) -> int
{
    return i;
}
template<>
auto true_magic<int_state::negative>(int i) -> int
{
    return -i;
}
template<>
auto true_magic<int_state::other>(int i) -> int
{
    return 0;
}

/* interface implementation via simple switch
   that can be auto-generated, for each unhandled case
   compiler generates a warning */
auto magic(int i) -> int
{
    switch (stateof(i))
    {
    case int_state::positive: return true_magic<int_state::positive>(i);
    case int_state::negative: return true_magic<int_state::negative>(i);
    default: return true_magic<int_state::other>(i);
    }
}

That’s for sure a lot of boilerplate for such a simple function but the overall pattern is very simple - by doing a few runtime checks we can acquire additional information about runtime values and carry this information to type level. This is especially useful when objects are immutable because the state can be calculated on construction.

All of the examples (except the one with static_assert) do not require modern language features and by sacrificing some type-safety can be used even with C++03-supporting compiler.

enum class is a great feature of C++11 and has many uses. Some of which are:

• type-safe enumerations;
• ability to share the same name between multiple enum class‘es contrary to plain C enums;
• a finite set of values that can abstract away anything.

Here and below we are going to focus on the latter which is basically the main reason behind enumeration types in general. The idea is that enum class being type-checked represents a bare bones set of values - a type.
Beyond that templates have a nice capability of being specialized not only on types but on compile time variables which enum class constants are. Other than enums we can use any intergal values but the fact that enum values can be given explicit names comes in handy. With a couple of abstractions we’ll try to implement Rust-like enums with attached data.

Example one (C++14): ‘overloading’ return type

The enumeration could mean a way for client code to specify an additional parameter to a function which in turn can be specialized on that parameter.
The simplest example here is a common construction or access point for multiple types - a factory, application settings storage etc.

example1.hpp:

/* explicit list of values of our so called type */
enum class overloader
{
    caseA,
    caseB
};

/* set of types which associate with the overloader values
   the key point is that a single type can associate with multiple enum values */
struct typeA
{
    void a();
};
struct typeB
{
    void b();
};

/* mapping between the values and types of overloader */
template<overloader>
struct get_return_t;

/* concrete type mappings */
template<>
struct get_return_t<overloader::caseA> { using type = typeA; };
template<>
struct get_return_t<overloader::caseB> { using type = typeB; };

/* convenience routine */
template<overloader O>
using return_t = typename get_return_t<O>::type;

/* this way the interface is clealy defined and extendable in exactly one place - the enum */
template<overloader O>
auto get() -> return_t<O>;

Somewhere in example1.cpp:

void typeA::a() {}
void typeB::b() {}

/* the definitions are modular because of the template specialization */
template<>
auto get<overloader::caseA>() -> return_t<overloader::caseA>
{
    auto value = typeA{};
    // ...
    return value;
}
template<>
auto get<overloader::caseB>() -> return_t<overloader::caseB>
{
    auto value = typeB{};
    // ...
    return value;
}

Client code

/* only an 'overloader' value could be passed */
auto valueA = get<overloader::caseA>();
valueA.a();
auto valueB = get<overloader::caseB>();
valueB.b();

In C++14 there is auto return type deduction for functions but that forces us to write the definition in header.

Example two (C++14): implementing CRTP / a family of mixins

The enumeration could also mean a way to list a family of implementation or mixin types.

example2.hpp:

/* for std::is_same */
#include <utility>

/* list of scenarios */
enum class family
{
    caseA,
    caseB
};

/* type specifier for interface methods */
template<family, class>
struct get_method_t;

/* explicit user-defined types for interface methods */
template<class C>
struct get_method_t<family::caseA, C> { using type = int(C::*)(int, char); };
template<class C>
struct get_method_t<family::caseB, C> { using type = void(C::*)(double); };

/* convenience routine */
template<family F, class C>
using method_t = typename get_method_t<F, C>::type;

/* implementation class */
template<family F>
struct implementation;

/* implementation types specifications */
template<>
struct implementation<family::caseA>
{
    auto foo(int, char) -> int;
    /* caseA-specific methods */
};
template<>
struct implementation<family::caseB>
{
    auto foo(double) -> void;
    /* caseB-specific methods */
};

/* common interface for implementation types */
template<family F>
struct interface : implementation<F>
{
    /* enforce method 'foo' in implementation<F> with the specified signature */
    static_assert(std::is_same_v<
        decltype(&implementation<F>::foo),
        method_t<F, implementation<F>>>);
};

Somewhere in example2.cpp:

auto implementation<family::caseA>::foo(int, char) -> int
{
    /* caseA implementation details */
}
auto implementation<family::caseB>::foo(double) -> void
{
    /* caseB implementation details */
}

Client code

auto valueA = interface<family::caseA>{};
valueA.foo(42, 'e');

auto valueB = interface<family::caseB>{};
valueB.foo(42.0);

The common benefit of all these applications is simplification of the interface for client code by using a small number of key entities all defined in one place. Most of these things can be implemented using the regular CRTP, inheritance etc. But in some cases putting a collection of something under an enumeration can help express restrictions in your code.

For more see part 2