Atom plugins for C++ development

I work a lot on Ubuntu, and Linux is one of the targets of Minko. As soon as Github’s Atom was released, I wanted to test it as an actual development environment for such C++ applications.

Here are two plugins I think are major additions to Atom for C++ development.

autocomplete-clang

Autocomplete is a major feature for any IDE. In the case of C++, it’s even more important because of the complexity of the language. The autocomplete-clang plugin uses clang static analysis to parse headers. It then extends Atom’s autocomplete feature to properly autocomplete C++.

autocomplete-clang

The plugin works great. It’s less tightly integrated than VisualStudio’s Intellisense. So it’s not as fast. Still, the lack of speed is not a big issue compared to the ease the plugin brings. Using pre-compiled headers should speed things up, but I haven’t tried them yet: I guess it says a lot about how not much of a problem this lack of performance might be…

linter-clang

Compiling your code to check its syntax is not a very efficient process. You keep Alt-Tabing between your editor and the terminal where you run compilation. It’s a given clang’s output is a lot more readable than GCC’s. Still, it’s not as integrated as VisualStudio real-time analysis.

linter-clang

The linter-clang plugin fixes that. Once again, it uses clang’s static analysis to check your code and properly report errors in real-time. No need to try to compile your code: linter-clang will check for errors as you type and will report them visually directly in the editor, just like Eclipse or VisualStudio do it.

Using those plugins with Minko

Both those plugins will need to call clang with the proper flags. And those flags depend on your very project. In the case of autocomplete-clang, those flags can be setup in a .clang_complete files at the root of your project (this method is actually inspired from Vim’s popular clang autocomplete plugin). But linter-clang does not support .clang_complete files, so I made a patch available here (that patch will hopefully be merged soon as you can read here).

To generate such .clang_complete files, Minko’s build system has been updated with a “clang-complete” action. This action will automatically create the .clang_complete files for each Minko project (the core framework, the plugins, the tutorials…) or your own project with a single command line :

Instead of solution/project files, this premake action will generate .clang_complete files with each project’s specific flags.

Flyweight design pattern with C++11

To optimize the memory consumtion of the Minko engine, we started by profiling the memory allocations using tools such as the integrated Visual Studio 2013 memory profiler or Massif.

One of the heaviest source of memory allocations was for  std::string  objects. It’s not really a surprising considering one of Minko’s biggest feature is dynamic data binding between the engine data – on the CPU – and the shader data – on the GPU. And “dynamic” means we have to create those bindings according to some naming conventions and explicit declarations made in “effect” files using JSON. Read: we use lots of strings.

We use strings for material property names, but also for the camera properties or the geometry vertex attribute names. It makes the engine very flexible and extensible while keeping some important aspects of strict typing using templates. But it uses a lot of memory because each property names is stored multiple times.

Materials for example are highly likely to share most (if not all) of their property names. If you have 10 of those materials, the property name strings will use 10 times too much memory.

To solve this, I’ve implemented the flyweight design pattern.

Continue reading “Flyweight design pattern with C++11”

From ActionScript 3 to C++ 2011

During the last Flash Onlince conference, I had the chance to share the latest work I’ve been involved in at Aerys with the rest of the Minko team. We’ve been working a lot on the next major version because we really want it to be a game changer for 3D on mobiles and the web.

You can read the original announcement for more details. But the big picture is that Minko is going to support WebGL. To introduce this new major feature we’ve created a first technical demonstration:

To do this, we are completely rewriting Minko using C++ 2011. This new version will include bindings for ActionScript 3 (and obviously Javascript too). So if you’re an AS3 developer: do not panic! You’ll still be able to leverage your AS3 skills with Minko. Yet if you want to learn new tricks now would be a good time and C++ is a good choice.

To understand the process of working with C++ code targeting the Flash platform and HTML5/Javascript, you can start by reading my slides:

To help AS3 developers migrating to C++, I’ve decided I’ll start gathering resources here on this very blog. If you are interested you can start by:

If you have suggestions regarding what you need to know in particular regarding C++ and especially cross-compilation targeting the Flash platform or Javascript, please let me know!

What I like about C++ 2011

C++ 2011, AKA C++0x, is the new version of what is maybe considered as the king of programming languages. I was a C++ programmer before I ever became a Flash developer. But what I truly love about this new version of C++ is how it makes a lot of things simpler without sacrifying performances.

So this will be the first post in a series to detail what I like about C++ 2011. One of the new things I like the most are shared pointers.

Handling memory properly has always been a problem in non managed languages. The garbage collector performance impact is debatable (and a very complicated debate indeed), but when you’re working with C++ that’s out of the question anyway. You have to allocate memory with “new” and release it with “delete”.

For quite some time now libraries such as Boost provided what was commonly called “smart pointers”. This concept is now part of the C++ STL with the std::shared_ptr class, AKA “shared pointers”. The idea is simple: shared pointers will store a reference counter and delete the actual pointer it holds whenever that counter goes to 0.

Working with shared pointers is just as easy as creating an std::shared_ptr object and passing a pre-allocated pointer or even better using the std::make_shared:

The latest is better since it makes a single memory allocation:

As an API developer, it makes it a lot easier for me to provide a clean API that will enforce an efficient memory management. Sure, shared pointers have a little overhead. The general consensus is a 5% memory/CPU hit in the worst cases. Working with references or leveraging copy elision should make things easier. Still, that’s a little price to pay for a 0% memory leak performance!

If you chose to, you can even force your users to use only shared pointers by making the constructor private:

Whether that constructor should really be private or users simply incentivized to use the create() method is something I have not firmly decided yet. The first solution is a very strong statement: I don’t want you to deal with my memory. The second one is more flexible: I give you the choice to crash everything.

What do you think?

How to: handle C++ exceptions with Adobe Alchemy

Alchemy is a great project that enables C++ code to be transformed to ActionScript 3.0 bytecode. But some of the C++ features are not available. Exceptions handling is one of them. It is a big issue because any decent C++ project uses exceptions.

Exception objects are actually properly created and raised. But try/catch blocks have no effect. As far as synchronous Alchemy functions are concerned, this causes an uncatchable exception to be raised when the C++ methods or any sub-routine raises an exception. Even the new global error handler can not catch those exceptions. When using asynchronous Alchemy functions, it is even worse: the main thread crashes and your application exits immediatly.

Sample code right after the jump…