CopperSpice is a set of cross platform libraries for C++. The following sections describe some of the philosophies behind the development of CopperSpice and our long term goals.
For a complete list of release dates, significant changes, and past history, refer to our CopperSpice timeline. Timeline
- May 2014 - December 2016
- CopperSpice 1.0.0 through 1.3.3
- January 2017
- CopperSpice 1.4.0
- May 2017
- CopperSpice 1.4.1
- July 2017
- CopperSpice 1.4.2
- September 2017
- CopperSpice 1.4.4
- January 2018
- CopperSpice 1.4.5
- June 2018
- CopperSpice 1.5.0
- September 2018
- CopperSpice 1.5.1
- February 2019
- CopperSpice 1.5.2
- August 2019
- CopperSpice 1.5.3
- CopperSpice 1.6.0
Library versus Framework
The basic definition of a library is essentially a set of classes or functions you call from your application. The reason developers find libraries so valuable is they add features which are not in the base language. Library functionality is normally maintained by someone other than the application developer.
In C++ the STL is a library which is maintained by the C++ standards committee and is not updated very often. Boost is a set of libraries which are contributed by a large number of people. The committee for Boost tries to set guidelines but each library is independently managed. Updates are at the discretion of the library developer.
All the functionality in a library is at the same level of abstraction. A class in CopperSpice like QString (similar to std::string) operates at a low level and the methods are written to modify or query the given data. The entire QString class operates at the same level of abstraction, namely a sequence of characters.
A framework is a set of interrelated libraries which is intended to confine your design choices. Whatever restrictions exist in the framework may constrain how you write your application. The intention of a framework is that a developer does not need to make many of the fundamental design decisions. Some believe this makes a framework easier to use, can increase productivity, and programmers are not required to learn as much about the low level operations.
The downside of a framework is that applications do not always fit into the given framework model. Frameworks can make applications difficult to scale, they are often restrictive, and very expensive to port away from.
The functionality provided in a framework is at several different layers of abstraction for any given class.
As a developer you may not need to use every library in the framework however you may end up needing to include libraries because of their dependencies.
CopperSpice is transitioning to a set of libraries, as we move away from the framework concept into smaller independent libraries.
In order to build the main Core library in Qt, moc has to be built first. In order to build moc you need QMake and a special version of the Core library which is called the bootstrap library. The way this is done is by building QtCore in a special "bootstrap" configuration by disabling a large portion of the library with a massive number of #ifdefs. The bootstrap library is then used to build QMake, followed by the moc being built. After this process has been completed the real version of the QtCore library is compiled.
This legacy bootstrap dance is not required in CopperSpice where CsCore is just a normal C++ library.
Removing moc resulted in several benefits for CopperSpice. QMake is no longer required and developers can build CopperSpice with GCC or clang using the CMake build system.
The full functionality moc provided has been retained in CopperSpice. The implementation of reflection which was supplied by this code generator, is now based entirely on modern C++. A string based code generator is not used in CopperSpice.
Listed below are some of the advantage of the improved reflection system.
- The bootstrap library is not required and all code related to it was removed
- CsCore is simpler to build and maintain with the enormous reduction in #ifdefs
- A templated class can inherit from QObject
- Improved static type checking in Signals and Slots
- Typedefs in Signal/Slot parameters are recognized as the defined type, not the alias name
- Data types which contain a comma can be used without restrictions
- For example: QMap<QString, bool>
- This affects Signal/Slots, Properties, and QMetaMethod
- QMap can be used as a data type for a Signal or a Slot parameter
Moving to CopperSpice
CopperSpice requires C++17 and takes advantage of templates, variadic templates, SFINAE, constexpr, tuples, type traits, decltype, and the power of modern C++. It is our aim to encourage other developers working on CopperSpice to leverage C++ features to improve functionality.
Our PepperMill utility will convert your application header files to standard C++ header files. This will allow your existing Qt code to run with no other code modifications. The step is done only one time.