Sign in to follow this  
Vincent_M

C++ IDEs for Linux

Recommended Posts

Sponji    2503

My vote goes for KDevelop, it's just awesome.

 

One thing that sucks about IDEs for Linux is the autocompletion/intellisense thingie for macros and function pointers. It's sometimes quite annoying to program OpenGL related stuff if you've got used to get the information about function's parameters from the IDE. I've tried a lot of IDEs for Linux and all of them seem to have problems with the same thing. Visual Studio might be the the only one that handles this well. Of course, please tell if you know/find one which handles this well.

Share this post


Link to post
Share on other sites
BitMaster    8651

I thought QTCreator was a really nice IDE as well. I am thinking about using it to develop my GUI tools for my engine when it comes down to that point since the only tools I've developed were for Windows using c-based winapi's back in high school haha... I had a few gripes I have with QTCreator. I haven't figured out the licensing, or what kind of royalties I'd have to pay Nokia if it came down to me producing a commercial produce. From what I've seen from tutorials, there seems to be quite a bit of OpenGL wrappers involved with QT. I'm not sure if I could link to standard libraries that are already installed on my system that weren't built from QT.


QtCreator does not force you to use Qt. If you don't, you are only bound to the license of the compiler you use (if you use a bundled version, usually MinGW derivative or MSVC; otherwise whichever compiler you chose to setup).
If you use Qt you can buy a commercial license or use the LGPL license (see here). Since I'm not even sure there is a viable Qt 5 build which links statically that seems to be almost a restrictionless license.

Also, whichever way you go, Nokia does not factor in there at all. Qt is now in the hands of Digia.

Share this post


Link to post
Share on other sites
DejaimeNeto    4221

If you use Qt you can buy a commercial license or use the LGPL license (see here). Since I'm not even sure there is a viable Qt 5 build which links statically that seems to be almost a restrictionless license.

I avoid using LGPL (actually, I avoid GNU licenses altogether).

The main problem, specially when considering commercial games, is that LGPL also allows the user to use a modified version of the library (free to use). By using the LGPL licensed resource, you accepted this. It opens a wide plain of possibilities for problems. Unofficial, hacked, versions of the library would float around the Internet. Still, if your game is single player, there'll be nothing to worry about. But by the time you decide to make it multiplayer and hacking start to affect the experience of other players, you won't be able to touch cheaters. If they stay inside the library interface, there isn't much you can do. You'll see that the cheaters will probably fall into a penumbra between your TOS and the restrictions imposed by the LGPL, that states clearly:

3. Object Code Incorporating Material from Library Header Files.
The object code form of an Application may incorporate material from a header file that is part of the Library. You may convey such object code under terms [...] you do both of the following:
a) Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License.
b) Accompany the object code with a copy of the GNU GPL and this license document.

4. Combined Works.
You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications [...]

Now, whether your work is an application or a combined work differs only if you link it statically. So, no static linking or you'll also allow, beyond the usage of modified versions of the library (despite of its purpose), reverse engineering and debugging. In other words, if you use a shared link you've got problems, but if you link statically, they're really worse.

I guess this was one of the main reasons SDL dropped LGPL in favor of zlib. It surely was the main reason I avoided SDL in favor of SFML and Allegro for so long...
Why would the Qt Project provide a commercial license? If LGPL was really a good license, there'd be no reason for them to provide a better one.

Just to make sure I'm not confusing anyone, this wouldn't apply to applications that were created using the QtCreator IDE, given that you only used the IDE. It only affects things that needs libraries or actual code from the Qt Project. Edited by dejaime

Share this post


Link to post
Share on other sites
BitMaster    8651

If you use Qt you can buy a commercial license or use the LGPL license (see here). Since I'm not even sure there is a viable Qt 5 build which links statically that seems to be almost a restrictionless license.

I avoid using LGPL (actually, I avoid GNU licenses altogether).

The main problem, specially when considering commercial games, is that LGPL also allows the user to use a modified version of the library (free to use). By using the LGPL licensed resource, you accepted this. It opens a wide plain of possibilities for problems. Unofficial, hacked, versions of the library would float around the Internet. Still, if your game is single player, there'll be nothing to worry about. But by the time you decide to make it multiplayer and hacking start to affect the experience of other players, you won't be able to touch cheaters. If they stay inside the library interface, there isn't much you can do. You'll see that the cheaters will probably fall into a penumbra between your TOS and the restrictions imposed by the LGPL, that states clearly:

...

That sounds like an artificial problem for me. Having access to part of the source might or might not make it a little bit easier to manipulate a game, but if it is popular it will be hacked either way. Most TOS are pretty much useless in anyway should they ever come to be tested in a court anyway. If push comes to shove instead of banning your identified cheaters you can instead move them to the cheater-only server where the can play for the rest of their life with other cheaters.
That said, if your game is popular enough for that to even become an issue, buying a commercial Qt license should be extremely feasible, completing removing that particular issue.
 

Now, whether your work is an application or a combined work differs only if you link it statically. So, no static linking or you'll also allow, beyond the usage of modified versions of the library (despite of its purpose), reverse engineering and debugging. In other words, if you use a shared link you've got problems, but if you link statically, they're really worse.

Not being reasonably allowed to link statically is a well-known restriction of the LGPL. However, many games I see have important bits of code lying around in (well-known, often open-sourced) dynamic libraries which could be switched out just as easily.
 

I guess this was one of the main reasons SDL dropped LGPL in favor of zlib. It surely was the main reason I avoided SDL in favor of SFML and Allegro for so long...
Why would the Qt Project provide a commercial license? If LGPL was really a good license, there'd be no reason for them to provide a better one.

Of course being allowed to link as you want is nicer. At work we have been using our Qt license to statically link to Qt 4, but that was also a bit of extra work. Unfortunately I'm not sure something like that is currently possible with Qt 5 but I believe some work is happening in that area.

In my hobbyist endeavors I have often followed the path of complete static linkage as well (sometimes including assets) so that the project result was a single executable. That has a certain charm as well and a portable version of your application becomes trivially easy like that.
However, currently my internal pendulum has been swinging another way. Working with Qt adds a lot of baggage to the project but the games I'm interested in are by there nature less reliant on extremely high-performance eye candy and require more sophisticated UIs. Qt goes a very long way with QtQuick to offer a very thorough UI system that integrates well with OpenGL.

Also, should commercial exploitation of my hobbyist projects ever become an issue I'm pretty sure I could live with buying a Qt license in order to negate any lingering LGPL problems/possibilities/whatever.

Share this post


Link to post
Share on other sites
TheChubu    9446

I guess this was one of the main reasons SDL dropped LGPL in favor of zlib. 

Nope, it was literally SDL developers noticing people like you that get nervous when they hear "LGPL". So they changed their licence to something else that was less likely to flip the switches of some people.

Share this post


Link to post
Share on other sites
SimonForsman    7642

 

I guess this was one of the main reasons SDL dropped LGPL in favor of zlib. 

Nope, it was literally SDL developers noticing people like you that get nervous when they hear "LGPL". So they changed their licence to something else that was less likely to flip the switches of some people.

 

 

There is also the issue of iOS, WP and consoles, complying with the LGPL on a restricted platform is virtually impossible.

On Android you can be compliant but due to the lack of dynamic linking it is still a hassle. (you need to provide object files for re-linking the apk just like you would if you used static linking on the PC)

 

Using QT with the LGPL license on Win/Mac/Linux isn't a problem, just link dynamically.

 

These days when a large number of games has to run on mobile devices and consoles the LGPL is becoming very restrictive and its best to only use LGPL libraries for tools or for Win/Mac/Linux ports.

Share this post


Link to post
Share on other sites
kaktusas2598    953

I am very comfortable with g++, gdb,vim and make combination, but im consider switching to QT Creator for bigger programs(because ease of management), I am still not sure, though :) But, I have no idea how to build projects with additional libraries like openGL, in QT tools :( :D

Share this post


Link to post
Share on other sites
Bregma    9199


I've always wondered, how do you effectively debug a program on the command line? Do you really use GDB on the command line? I can't imagine doing that without an IDE to show me variable watches, stack, memory dump, and disassembly.

Yes, gdb from the command line.  Sure beats firing up some ghodzawful GUI monstrosity just to run a debugger.

 

Now, running gdb in batch mode when you don't have command-line access (eg. debugging the display server during startup failures) is a challenge.  Inconvenient, but doable, unless you require a GUI, in which case shove over and let someone who knows what they're doing take over.

 

Then again, I cut my teeth using real VT100 terminals and 300 bps modems, so I don't see command-line anything as an obstacle.

Share this post


Link to post
Share on other sites
Jason Z    6434

As several others have already noted, QtCreator is a viable option.  I recently saw a talk by Bruce Dawson from Valve that provides a nice 'getting started' info.  You can check it out on the Steam Dev Days page here.

Share this post


Link to post
Share on other sites
sindisil    388
I spend about half of my day job hours coding in C and C++ for embedded Linux. There, I primarily use vim/gdb/ctags/etc., mostly because of the specialized build environments and the need to flexibly build on remote servers.

When I *do* choose to use an IDE, I've only found two for Linux that really work well for me: NetBeans and Eclipse. I'm not a big Eclipse fan (the other half of my day job is spent coding Java, where I avoid Eclipse like the plague), but CDT is probably the best overall editing experience for C++ (auto-complete, refactoring, etc. all work reasonably well). If only they'd drop the damn Workspace idiom already. At least CDT can work with makefiles, so I can work around some of its more annoying aspects when I need to.

NetBeans is a close second to CDT, primarily because some of the features don't work quite as well and because NetBeans is missing some tools integration (e.g., valgrind). An example of a feature that doesn't work quite as well in NetBeans as in Eclipse CDT is the fact that, in NetBeans, semantic rename of a function parameter doesn't change the declarations, only the definition and uses -- CDT gets the declarations as well). OTOH, it's a much cleaner environment than Eclipse, and, since I often use it for Java work, it's one less set of key bindings I need to keep in memory.

I've recently made a survey of the modern alternatives, looking at reasonably current versions of Code::Blocks, CodeLite, and KDevelop. None of them come close to NetBeans or Eclipse CDT at this time, IMHO. I do need to give a current version of QTCreator a shot, though. Last time I tried it, it didn't impress me much, but I know full well that apps can evolve rapidly.

[edit: spelling and typos, oh my!]

Share this post


Link to post
Share on other sites
fluffybeast    132

I too use vim, as I like being able to write code without moving my hands away from the keyboard. It takes some getting used to, but it's worth learning. And besides, I've never found a full-fledged IDE for Linux that I like

As for compiling, I have my own crude build system which uses qmake to generate a make file which is then compiled.

And when it comes to debugging I have no problems using just the command line and gdb to get a backtrace in case of segfaults.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this