Those newer to programming in C++ often fail to understand that compilers like GCC or Clang require a specific link order for the libraries in use or they don’t know what order to pick. Working on SFML and helping out in its community, I’ve had the pleasure to help people fix their linker errors many times and every now and then I’d explain a short rule of thumb one can keep in mind when specifying libraries to be linked. As such I wanted to share it here with you too.
For the development of Synth Guitar my Ludum Dare Compo entry I decided to use JetBrains’ CLion as my IDE. Ever since writing my most popular post about MinGW-w64 and an older EAP version I played around with the thought of trying it out, but never found the right project for it. For a year or two I’ve been using Code::Blocks, but was never fully satisfied (among others also because of this), however whether CLion will replace Code::Block for me is still open.
Before I had the EAP (Early Access Program) version installed on my notebook, but for my desktop PC I got to newly install the full version of CLion. As a student I get a non-commercial license for free, not only for CLion but for most of JetBrains’ products. If you however want buy CLion you’ll be paying €99 for a personal and €199 for a commercial license.
The download was very fast and with 138 MiB acceptably small. In comparison the offline installer for Code::Blocks with a compiler is 98 MiB and for Visual Studio you’ll be spending 6.9 GiB of your bandwidth, because Microsoft unfortunately doesn’t manage to provide a version just for C++.
The setup is very simple and I quite like the settings part when starting CLion for the first time. It allows you to directly change the options for design, version control integration and proper compiler detection. The later is one of the strong points compared to Qt Creator or Code::Blocks, because CLion supports and properly detected my MinGW-w64 installation, while it always seemed a bit of a hassle with Code::Blocks or you first needed to learn how Qt Creator actually handles toolchains and compilers. I wonder though why JetBrains couldn’t fully “support” the latest builds of MinGW-w64, not even with their 1.0.1 update. Then again I ignored the warning you get for it and have yet to run into any problems because of that. However CLion has stated that it can lead to freezes in certain situations.
The Build System
As someone who quite likes CMake, CLion’s native support is amazing and something I’ve been looking for quite some time. Of course Qt Creator comes with CMake support as well, but last I tried it, it did not integrate very well. With CLion you write your CMake code, link your favorite libraries through it and it will build and run just fine. One thing that seems a bit strange compared to most other IDE is, that CLion keeps by default all the build files in a temporary directory somewhere in your user directory. I mean it makes sense to not spam the source directory with all the CMake temporary files, however every now and then one might want to do something specific with the binary and has to go search it in there. My assumption is that CLion expects you to install the binaries instead. Luckily the directory can be changed with a few simple clicks if you know where to look.
One of the strange default options CLion ships with is that it allows multiple instances of the application to be run. So when you for example are debugging, you can also click on run again and the interface will switch to a different layout but still keep running in the background and a new instance will be loaded. During the Ludum Dare Compo I didn’t figure out that there’s a stop button if you switch to the correct tab, thus I ended up killing off GDB manually. I’m however really glad that pressing the stop button works, because pressing the stop button with Code::Blocks most of the time simply doesn’t work and you end up having to kill the process in the task manager. After the Compo I got a response from CLion that there’s an option to only allow one instance. This should in my opinion be the default setting given that single-instance applications are a lot more common.
I had been using Vim for some web development during a year or so and gotten quite used to some commands, however I’m still not a Vim guru, but can’t argue with the fact that it can accelerate the code-writing quite a bit. As such I tried out CLion’s Vim-Emulator and I’ve to say it’s very good. My main critique would be, that it’s not obvious in what mode you’re currently in, as such it’s really annoying when you start typing commands or text and only then notice that you’re in the visual mode. I honestly never had that issue with Vim, so all I can assume is that the indicators aren’t well placed. Something else that got me quite annoyed is that in almost all cases when you click on the editor to get the focus back, it will (accidentally) switch to visual mode. This usually lead me to keep hitting the ESC key multiple times just in case, to ensure that I ended up in command mode. Since the Vim-Emulator is a general JetBrains’ feature and not strictly related to CLion it might also just be me, who isn’t used to it.
I’m not a big fan of getting my code automatically formatted, since my style usually doesn’t match with the coding style of a lot of other C++ developers. Until I realized that CLion allows you to customized the formatting rules to about every detail, it was quite annoying to work with at times. But the customization settings are in fact so detailed that you have to be careful to not overlook the option you actually want to change. What was a bit counter intuitive however is that in order to make any changes to the formatting, you first have to create a new style setting. The ones that are installed by default are read-only. Some indication for that would be helpful and would’ve saved me a trip to the all-knowing Google.
Performance is one of my main concerns with JetBrains’ IDEs. CLion is written in Java and even though they do a great job at hiding that fact, meaning the application doesn’t feel nor look like your standard cheap Java application, the resource allocation regarding RAM and CPU time is something you might not want to overlook. To be fair though, it’s impossible to tell whether Java itself has much to do with it or if there is more improvement possible in CLion’s codebase alone.
When opening my Ludum Dare project and just letting CLion sit there, the memory allocation idles at around 1000-1200 MiB. I assume most of it is used for source code meta information to make auto-completion or similar things faster. However Synth Guitar only uses SFML as library, which makes me wonder how the memory allocation scales for larger projects with a lot of different libraries. Personally it doesn’t seem like a big issue, after all there’s plenty of free RAM and it certainly is a better alternative to keep that data in memory compared to Visual Studio’s huge IntelliSense database files.
Something that got a bit of an issue during my Ludum Dare live stream, was the CPU usage of CLion. It’s nice to see CLion using no CPU time at all, when doing nothing, but it gets quite scary when you look at it while writing code. It will jump all over the place starting off at around 30% total CPU allocation and when you start compiling something it actually maxed out my CPU. If you do CPU-heavy things like encoding live stream video and audio data at the same time, such a high CPU load can become a bit of a problem. Again it’s just a speculation, but I’d claim that optimized C++ code instead of Java code, would reduce the CPU usage for the general editing part quite a bit.
Having worked with CLion for only a short period of time, it’s kind of hard to talk about features, since I have yet to discover most of them and put them to use. But since we’re talking about JetBrains here, I think the most talked about feature is their refactoring tool. I’m very used to manually refactoring everything and as such will first need to get used to the option of having code changed automatically, as well as learn what the tool can actually do. Something that I tried to do was rename my copy of a class, but apparently that’s still a missing feature. It might have been just my lack of knowledge, but using the refactoring tool with the Vim-Emulator seemed to cause some trouble.
CLion is a solid IDE for C++ development. You really notice the long experience JetBrains had with building code editors and yet they still managed to keep up to date with the “latest tech” (Git, CMake, MinGW-w64, etc.). I really hope that performance will improve a bit and am sure that some of these early bugs and missing features will get fixed over the next few months. I wish the developers of Code::Blocks and similar IDE would take a look at the look and feel of CLion and try to aim for that as well. Especially Code::Blocks seems to not have improved noticeable over the past years, which is quite a shame.
Everyone who works a lot with CMake should really give CLion a shot. I already started another project with CLion, so who knows maybe Code::Blocks will slowly drift into the “unused” section of my PC?
As a final note: JetBrains has in the meantime released version 1.0.1.
After answering the same questions over and over and over and over again especially about compiling and linking, I thought it might be time to write down a few things, that I and maybe others could point to instead of keep repeating ourselves in the future. Given the wideness topic I’ll be writing things down in multiple parts. In this first post I’ll be explaining a few basic terms and their practical applications, the next one will go more into details on how linking against external libraries work and in the third and last part I’ll be writing down answers to some common issues. I hope this will turn out as a timesaver for all parties. – As a disclaimer I should add, that I’m a human being that makes mistakes and can have wrong models in their mind, thus if I make a mistake feel free to point them out.
Part I – Terms and Explanations
Although this should essentially be covered in any basic programming book, even the bad ones, here we go with a few “definitions”:
Looking at it in a very abstract way, an application is no different than anything else on your hard disk, because it’s just ones and zeroes, the important part however is how these numbers get interpreted. Your CPU (the heart & brain of your PC) doesn’t understand the ones and zeroes from a music file, but if you give it the data of an application it can translate them into actions that will do what the programmer intended to (hopefully).
To get such an application, your C++ code has to be turned into ones and zeroes, also known as machine code. The full processes of doing so is called building and is as such more an abstract term, because the process is essentially a composition of mainly three sub-processes: Preprocessing, compiling and linking.
Header File (*.hpp / *.h)
If you’ve done your job right, i.e. followed the correct way of writing code, then you should have all the declarations of functions, classes, structs, enumerates, templates, etc. in header files. With the help of a header file, the compiler will know how much stack and memory space is needed for the machine code that is about to be generated.
Source File (*.cpp)
The source file holds most of the implementation details, also known as code definitions. It’s where the behavior of the application itself is crated, meaning how the declared classes and functions interact with each other.
Inline File (*.inl)
This is not always needed and essentially optional, but it’s a common and good practice to put code definitions, that are required to be in the header file, into an external file and include it at the needed position in the header file. The most common use of inline files is for template definitions, which need to be in the header given that they get executed at compile time and can influence the memory layout and footprint.
Before your code gets translated into anything the preprocessor will kick-in. All the statements that start with a number sign are actually preprocessor directives and get resolved in the first step of building an application, for example all the #include will get replaced with the actual content of the included header file or for any #define X Z all X will get replaced with Z or any kind of macro will get executed.
Now that one source file will hold all required declarations the compilation can begin. Compiling is one of the terms that confuses a lot of people since it’s often used synonymously to building, which in turn isn’t too surprising given that compiling is the most crucial part, since it actually translates all the source into machine code. But you don’t end up with an application itself, but instead you end up with an object file for each source file.
Object File (*.o / *.obj)
Object files contain the translated source code in machine code. While the CPU essentially would understand the commands of the binary data, it would not know where to start exactly and miss other referenced code pieces. Thus these object files are only the building blocks used by the linker to generate the final executable.
As pointed out above the linker will be combining the object files generate by the compiler. It’s called linking because it obviously doesn’t just append or prepend the files, but actually makes “smart” links between parts of the object files – for details you might want to refer to a linker manual or other sources. But the linker doesn’t just link object files, it also links in libraries and it’s here where the difference between static and dynamic libraries are important, but I’ll go into more details in the next part, for now I’ll just say that static libraries are actually just archives of object files and thus can be linked in directly, while for dynamic libraries one just specify the interface and the “connection” between the application and the external code will be made at runtime.
Integrated Development Environments
This essentially doesn’t have anything to do with building applications, but it’s exactly that point that gets confused often. Integrated Development Environments short IDE are simply a set of tools created to work nicely (integrated) together and assist the programmer in creating code. A compiler and a linker can be considered part of this tool set, but it’s not the IDE that builds anything. Some of the most common IDEs would be Visual Studio, Code::Blocks, Qt Creator and Xcode. However one exception remains and that is, the Visual Studio compiler doesn’t really have a name of its own. Sometimes one refers to it as MSVC (Microsoft Visual C++), which in turn could also mean the IDE itself. What’s certain is, that one should not use “I built this game with Code::Blocks”, but instead “I built this game with MinGW” or “GCC”.
Having reached the end of the first part, I hope this basic information will be of some help to new beginners and depending on the response or future experience, I might add one or two paragraphs. The second part already has some words written for, so stay tuned!
And I’m back with my weekly based SFML News! Given that it’s just a bit more than two weeks, there thankfully isn’t as much content as for my last entry, but it’s also not like, nothing had been going on.
Dead or Run
seobyeongky has created a small network racing game and by racing I mean running, not driving cars. It looks interesting and the sound effects are taken from various places, thus it’s kind of fun if you recognize them. I’m not sure if there’s a hidden executable somewhere, but I couldn’t see one on the forum. You can however still enjoy the video below or if you understand Korean, you could also take a look at the source code.
I’m back from my relaxing vacations in the city Lisbon and the topics are piling up, so get ready for a longer read! But first a picture from my vacations to make everyone jealous. 😀
Whenever you’re thinking about creating a tile based game you end up with some hackish format for loading tiles. There’s no good way to edit the format and if you forget which number represents which image you’re lost.
Although I’ve never really come close to a functioning tile based game, I often failed at the map load and create functionalities. So I looked a bit around for existing editors and loading functions and there are quite a few like Tiled or Mappy, but they mostly don’t fit my needs or use some proprietary libraries I’m not willing to use, either because of the overhead (e.g. boost) or license (e.g. Qt). With that in mind I decided to create my own editor. I will work it out for quite specific properties and then try to open it up for further settings.
But since this is a blog about my development experience you can guess the editor is still in a very basic state. Once I’ve hardened the code a bit more, I’ll open new project on GitHub, until then you’ll just have to keep reading the updates on this blog.
The GUI concept is quite simple; on the left side there’s a grid which represents the tile map and on the right holds various GUI elements and a list of the existing tiles you can work with. As I was thinking about the GUI I’ve searched a software for fast prototyping with GUIs and ended up with Pencil, which can run as extension in the Firefox browser but you can also use it as native application. It’s a bit of overkill to create a concept image for this simple GUI but I did it anyways:
For the implementation part I first though about using Qt since it provides a very nice interface but since I’d then had to figure out how to use it with SFML I decided to take a better look at SFGUI. It works pretty good but it misses many features you’d expect from a GUI system but since it’s in constant development there’s more to come in near future. I’ll probably post about SFGUI separately since there are a few words more one could talk about it.
Additionally I use the Thor library for handling my resources. Thor acts as an extension to SFML and adds many higher level feature like resource manager and particle systems. For TileMapCreator it seems to be a quite big and the since I don’t really have to share my resources the manager is actually just a easy way to load resources.
I’ve chosen the icon package Grunge-Icons from icons.mysitemyway.com. I don’t really like them but I couldn’t find anything that does have a big enough resolution and not just 16×16, looks a bit non-standard and can be used freely. So if you have any suggestions please leave a comment!
That’s it for now but I’m sure there will be a few updates before this gets useable.