Now in the Mar. 2017, cpgf version 1.6.0 is released.
The previous version 1.5.6 was released in Jul. 2013, 3.5 years ago. So why did the new version take so long time?
The reason was simple, because I was busy (or, lazy). In the past years, not only was I very busy in my previous job (developing game with a lot of overtime), but also I was working on my proprietary Forex back testing/optimizing/live trading system which was another large project with more 100K lines of C++ code.
Now and hope in the future I will have plenty of free time in my open source projects.
There are several new features added to the library in 3.5 years ago. But what I want to tell is my recent work that didn't add much new features but improved the library significantly.
cpgf was developed since about 2010, at the time that the latest C++ standard was C++03 and TR1. After C++11 was approved in 2012 (Wikipedia said it was Aug. 2011), I still refuse to use C++11 in cpgf. The reason is simple, at the time not all compilers (such as Visual C++ 2008, 2010) supported C++11 well. cpgf must be compiled happily on all "modern" C++ compilers.
Now it's 2017, even the laziest VC++ 2015 supports almost all C++11 features. It's time to embrace C++11!
Another reason I love C++11 is that in my proprietary financial trading system, I used a lot of C++11 features, and I really think C++11 is a new era of C++!
GCallback is the core component of cpgf and is used in most meta data processing code. The old callback system (GCallback) was written using the ugly preprocessor based partial template specialization. The code was very difficult to understand and more like write-only code, even I myself don't want to change the code.
Now thanks to the great C++11, I rewrote the callback system with variadic template. The code is not only clean, readable and shorter, but also the compiling time is reduced.
GVariant is another core component and is used everywhere through the whole library. It involves a lot of C++ type deduction. The old code is just like a heap of patches, when any type deduction broken, a new patched is added. The whole old GVariant lacked uniform design.
Now GVariant is re-designed from scratch, yes, from scratch, that's why I say it was rewritten and not refactored. The new GVariant code is much much cleaner, and no any patch any more!
The old cpgf library was not quite performance considered because it was not the top priority. Recently I add a benchmark target to the build system, and improve the script binding library a little bit.
C++ code
struct TestObject
{
TestObject() : x(0) {
}
int addX(const int delta) {
this->x += delta;
return this->x;
}
int x;
};
Lua code
a = TestObject()
for i = 1, 1000000 do
a.addX(5)
end
Before optimizing: 6900 ms
After optimizing: 2650 ms
The performance was doubled.
However, a caveat, the script binding performance is still much slower than other single-script binding library such as toLua++, and is about 30 times slower than native Lua code. This is because that cpgf script binding is very very generic, it has to do a lot of type checking and casting before calling a C++ function from script. But I believe cpgf is usable in high performance game as long as the architecture is well designed. I'm using cpgf in my Gincu 2D game engine.
The game engine uses cpgf extensively, such as the callback system, the tweening library, and the script binding library (the meta data is generated by cpgf tool metagen).
If you want to learn from live samples, the game engine is worth looking at in.