Blogs and thoughts of cpgf library

cpgf version 1.6.0 is released, after 3.5 years since previous version

Now in the Mar. 2017, cpgf version 1.6.0 is released.

→

2017/03/25 06:50 · Wang Qi · 0 Comments

New developer joined, and cpgf source moved to github

I'm glad to announce two pieces of news in cpgf project, both of which are really good for the future of cpgf.

→

2014/02/23 01:51 · Wang Qi · 0 Comments

Rewriting tool metagen with LLVM Clang

Current tool metagen is written in Java and it uses Doxygen as C++ parser. Doxygen is a great documenting tool and it has a decent C++ parser, but it also has its limitations, such as it's difficult to get all information from Doxygen XML. I still remember I had hard time to try to solve a type's full qualified name and I had to write simple code parser to parse the type relationship. Though current metagen was successfully used to generate meta data for Irrlicht which is a very complicated 3D graphics engine, it's very hard to make metagen suits as an all-purpose tool to work with any library. I tested that it's very hard to make metagen works with wxWidgets.

I believe LLVM Clang is the way I should switch to. There are two primary reasons I made this decision:

  • Clang is a real and very powerful C++ compiler. So Clang can produce every bit information that we need from any C++ code.
  • Clang is designed with tooling in mind. It's easy to develop tools based on Clang.

I started rewriting metagen during our China Dragon Boat Festival. After about two days work, I have almost finished the front end part, which parses Clang AST (abstract syntax tree) to metagen internal data structures. What I should do next is to re-organize the internal data structures and output to meta data code, which is not very much Clang relevant.

Up to now I'm very happy to work with Clang compiler. My only concern is that Clang is lacking documentation and there are not very much open source tools using Clang.

My goal for metagen is still the same: make metagen works with very complicated code base, such as wxWidgets, without too much human interventions. I believe Clang is able to meet my goal. :)

2013/06/12 13:29 · Wang Qi · 11 Comments

A handy Perl script tool to synchronize folders in SVN manner

Download the source code here

To execute the script, just invoke

The tool synchronizes source folder to destination folder, in SVN manner. It does,

  • Add files/folders to destination folder which only exist in source folder.
  • Delete files/folders from destination folder which only exist in destination folder.
  • Override files in destination folder which exist in both source and destination folders and the file content is different. Unlike SVN, it doesn't merge files.

I wrote this tool to copy changed files from my development SVN repository to the publish repository which is hosted on Microsoft Codeplex. If you think it's useful, feel free to use or modify it on your purpose.

2013/02/23 03:35 · Wang Qi · 4 Comments

Coming 2013 is slow but still active for cpgf library development

In the coming year 2013, I will have very little time and energy on cpgf development. The reason is after some tough hesitation, I decided to switch my daily job to a China oriented company, which culture is having a lot of overtime everyday and even weekend. Apparently I will not have much spare time and energy to work on cpgf massively. That situation will last for at least the whole year 2013.

So cpgf library development will be slow in 2013.

→

2012/12/18 14:22 · Wang Qi · 5 Comments

API design principles in cpgf library

From the first day when I designing the API in cpgf library, I had some design principles in mind and tried to stick with them. In this blog I will show the principles and give some examples.

Please note, none of any principles are found or invented by me. I was inspired by the great book “API Design for C++” and the blog Designing Qt-Style C++ APIs

→

2012/12/01 11:21 · Wang Qi · 0 Comments

cpgf library one year birthday -- a review of past one year

cpgf library first version was released on 2011, Nov. 05. At the time I writing this blog, 2012, Nov. 24, one year has passed. One year is not quite long time for a long term open source library project, but a lot of development had been done in the year. I will give a review on what happened on cpgf in the last year. Looking back is for better looking forward!

→

2012/11/24 15:53 · Wang Qi · 0 Comments

cpgf library 1.5.2 was released, we have meta data for Irrlicht

Oh yeah, cpgf library version 1.5.2 was released. Only one and a half months elapsed since previous version 1.5.1, how ever, the new version is an accumulated work in half a year, seriously!

→

2012/11/24 05:41 · Wang Qi · 0 Comments

Why I prefer NULL over 0 as null pointer in C++

Today I added a new item in cpgf FAQ documentation about why 0 can be passed as pointer in Google V8 Javascript and Python, but not in Lua.

I add that entry because I found the same problem when I convert a sample code for Irrlicht engine from Javascript to Lua. In the Irrlicht sample code, 0 is used as null pointer. I'm not familiar with Irrlicht and don't know which method parameter is pointer and which is integer, so when I was converting Irrlicht C++ sample code to Javascript, I just keep 0 as it is, but when I convert the code from JS to Lua, 0 doesn't work any more. For the reason, please read the FAQ, I won't repeat myself.

That small problem makes me confirm that it's correct that I always use NULL rather than 0 as null pointer. Below I will explain it.

→

2012/11/10 15:21 · Wang Qi · 0 Comments

Why can't GVariant be extended with unlimited data types?

Today I created a new todo task in the task system. The task is about to add a new type to GVariant to allow GVariant holds both variant data and meta type. Suddenly I had a new idea, why not to use function traits to allow the users to add arbitrary variant types to extend GVariant?

Pseudo C++ code:

// General function to create variant with built-in types
// same as how we do now
GVariant createVariant(...);
// The user may extend to add new variant type for FooClass
// The returned GVariant has a new variant type, such as vtFoo
GVariant createVariant(const FooClass & fooObject);

I felt excited about the new idea and almost wanted to add a new todo task for it. But then after a while, I realized the idea is completely wrong.

The reason is simple. GVariant must be platform independent and can be transferred across shared modules (DLLs).

That's how GVariant was designed for, similar as the VARIANT type in Windows Component Object Modal (COM). If we allow the users to extend GVariant with arbitrary variant types, we can't guarantee the extended type exists in another module (DLL), and we also can't guarantee the extended type has same size and layout in another module.

Though up to now cpgf is not tested in cross modules environment and it most likely can't work due to the C++ type cast on interfaces, crossing modules is our long term goal and we will definitely implement it one day in the future. So we have to take care about the crossing module ability in the very core component such as GVariant.

Because this is so important and I don't want to forget, I write down this blog to remind myself every time I review the blog. :-)

2012/09/25 14:47 · Wang Qi · 0 Comments