Skip to content

Home

Jump to bottom
Loïc Touraine edited this page Jul 14, 2018 · 10 revisions

What is XPCF ?

XPCF stands for "Cross-Platform Component Framework"

XPCF is a lightweight cross platform component framework, inspired by COM, XPCOM and similar frameworks.

It is designed to provide dependency injection using reflection and type introspection, with clarity, simplicity and light code base in mind.

It uses C++ metaprogramming together with some new C++11/14/17 features to detect most injection problems at compile-time.

It implements the abstractfactory and the factory design patterns (through the ComponentManager and ComponentFactory classes).

It allows to split the implementation code in "components" that can be assembled to form other components.

Components can be gathered together in so-called "modules".

Modules can later be introspected to figure out the components they provide.

The code is on github at github.com/b-com-software-basis/xpcf.

Features

  • Main features:

    • Binding of a type to an interface

  • Unlike most component frameworks, most checks are done at compile time, so that errors can be caught early. Some examples of checks done at compile time: Checking that all required types are bound (implicitly or explicitly)

  • The only injection errors that can't be detected at compile time (and will be detected at run-time) are:

  • No code generation. Just include xpcf.h and link with the xpcf library.

  • Reduces the need of #includes. The header file of a component only includes the interfaces exposed by the component. The implementation classes and the interfaces that the component doesn't expose (for example, private interfaces that the client code doesn't need to know about) don't need to be included. So after changing the implementation of a component (as long as the interfaces exposed by the component remain the same) only the component itself needs to be re-compiled. A component can implement new interfaces : the client code doesn't need to be rebuilt, it remains binary compatible. This makes compilation of large projects much faster than an include-all-the-classes-I-use approach.

  • Helps with binary compatibility: as a consequence of the previous point, since the client code doesn't include the implementation classes (not even the header files) if the interfaces exported by the component didn't change the compiled client code is binary compatible with the new implementation.

  • Conditional injection based on runtime conditions. This allows to decide what to inject based on e.g. flags passed to the executable or an XML file loaded at runtime.

Eager to get started? Jump to the Getting started page of the tutorial.

Look at the sampleComponent/ directory in the source tree for components sample code, or see the FAQ page for more information.

License

The code is released under the Apache 2.0 license. See the LICENSE.md file for more details.

Contact information

Currently Loïc Touraine ([email protected]) is the only regular developer of this project.

Clone this wiki locally