The examples given with the library are programs composed of multiple files and modules that provide a deeper illustration of how the library is supposed to be used, as opposed to the tutorials, which are single stand-alone files that illustrate concrete library features focusing on functionality and not on structure.

Hello World

The "Hello World" example is a very simple program with a single source file, which shows a usage of the very core library functionality. It is a no means an example of architecture.

Basic

The "Basic" example illustrates most of the library's features, but it mainly gives an idea of a sample project file structure.

Includes

Mixins

There are several files named *_mixin.hpp. They have a single line in them which declares that a class is a mixin.

They are all you need to include in order to use these mixins to mutate objects. The users are encouraged to implement a similar structure in their own applications. It allows us to modify the mixin classes, without having to recompile anything but the compilation units that define the actual classes.

In most cases a C++ class is split between two files. A header for the declaration to be included in compilation units that use the class, and a compilation unit with the class definition. The mixin classes in the example are similarly split. However, you may notice that the only place the header files that declare a mixin class are included is in their corresponding compilation units. In fact, your mixins that are like the ones in the example and are never used with object::get as actual C++ classes, don't need header files at all. You may simply write them in their compilation units only, much like Java or C# classes are written.

Messages

There are also several header files, named *_messages.hpp and their corresponding *_messages.cpp compilation units.

They are used to declare and define messages. The messages in a file are grouped by some common factor.

You need to include such files (and only them) if you want to call messages for and object. The code that calls the messages is completely oblivious to what mixins might actually implement them. You may add or remove mixins from your project and all your code that only calls messages, won't need to be recompiled.

The users are encouraged to separate any messages they create in a similar fashion.

Code

Even though some mixins in the project are named *_renderer they don't actually do any graphical rendering. They are merely stub classes that are used to show how a project may be structured and to give and idea of what and when is being called.

Multi DLL

The Multi DLL example is an example that shows how multiple dynamic libraries can work together sharing mixins and messages.

It has four modules:

• dynlib - a C++ dynamic library, linked with all other modules that has a mixin and some messages.
• plugin - a plugin-style dynamic library, which is not linked with the executable and, as plugins in other applications, may or may not be present with it. If it is present, the executable loads it, and calls its exported function, which enriches an object with a custom plugin mixin.
• executable - the actual project executable that creates an object, optionally gives it to the plugin for custom mutation and then calls some messages.