The latest version of QtCreator brings an option to run static-code-analysis using Clang. I struggled a lot with the setup of Coverity for Asset-Importer-Lib, so I had some hope that the setup for Clang will be a little bit easier. I wanted to run it on Windows 10 first, then move to Linux. So here is the report of my experiences:

First thing to do is get the latest QtCreator-version, the latest one is QtCreator-4.0.0. You can find it here: QtCreator-Homepage .

QtCreator is able to open CMake-based projects. What a luck: Asset-Importer-Lib is based on a CMake build. So open it and run the clang-analyser, theoretically.

Unfortunately there is a bug with clang-analyser when you are using the Visual-Studio to build it. You can find the corresponding bug here: https://bugreports.qt.io/browse/QTCREATORBUG-16234 . When using VS together with the clang-analyser the executable of clang cannot been started in the correct way. The workaround to get it running is easy: add the folder conaining clang in the QtCreator-bin-directory to your Enrironment-variable path.

Did it, restarted QtCreator, open Asset-Importer-Lib, clang analysis began to work …

To be continued …

If you want to generate a 64bit-build for Asset-Importer-Lib by using the Visual Studio project files generated by CMake please follow these instructions:

  • Make sure that you are using a supported cmake ( 2.8 or higher at the moment )- and Visual-Studio-Version ( on the current master VS2010 is deprecated )
  • Clone the latest master Asset-Importer-Lib from github
  • Generate the project files with the command: cmake -G”Visual Studio 14 Win64″
  • Open the project and build the whole project
  • Enjoy the 64-bit-version of your famous Asset-Importer-Lib

This should help you if you a struggeling with this feature. We just learned that just switching to code generation for 64bit does not work.

If you are looking for the latest Asset Importer Lib build: we are using appveyor
( check their web-site https://ci.appveyor.com, its free for OpenSource projects ).
as the Continuous Integration service for windows. If the build was successful it
will create an archive containing the dll’s, all executables and the export
libraries for Windows. At the moment we are supporting the following versions:

    – Visual Studio 2015
    – Visual Studio 2013
    – Visual Studio 2012

I am planning to support the MinGW version as well. Unfortunately first I have to
update one file which is much too long for the MinGW-compiler ( thanks to the
guy’s from the Qt-framework ).

Do you know the assert-macro? It is an easy tool for debugging: You can use it to
check if a pointer is a NULL-pointer or if your application is in a proper state
for processing. When this is not the case, if will stop your application,
when you are using a debug mode, in release mode normally nothing happens.
Depending on your platform this can vary a little bit. For instance the
Qt-framework prints a log-message if you have a failed assert test to stderr when
you are currently using a release build. So assert is a nice tool to check
pre-conditions for you function / method. And you will see your application crashing
when this precondition is not fulfilled. Thanks to some preprocessor-magic the
statement itself will be printed to stdout. So when you are writing something
like:

void foo( bar_t *ptr ) {
  assert( NULL != ptr );
  ...
}

and your pointer is a NULL-pointer in your application you will get some info on
your stdout like:

assert in line 222, file bla.cpp: assert( NULL != ptr );

Great, you see what is wrong and you can start to fix that bug. But sometimes you
have to check more than one parameter or state:

global_state_t MyState = init;

void foo( bar_t *ptr ) {
  assert( NULL != ptr && MyState == init );
  ...
}

Nice one, your application still breaks and you can still see, what went wrong?
Unfortunately not, you will get a message like:

assert in line 222, file bla.cpp: assert( NULL != ptr && MyState == init );

So what went wrong, you will not be able to understand this on a first look.
Because the pointer could be NULL or the state may be wrong or both of the tests
went wrong. You need to dig deeper to understand the error.

For a second developer this will get more complicated, because he will most likely
not know which error case he should check first, because he didn’t wrote the code.s

So when you have to check more than one state please use more than one assert:

global_state_t MyState = init;

void foo( bar_t *ptr ) {
  assert( NULL != ptr );
  assert( MyState == init );
  ...
}

Thanks!

Dear reader,

 

someone hacked my webspace and all older posts were deleted. Sorry, I wil start to rework on them as fast as possible.