Jump to content

  • Log In with Google      Sign In   
  • Create Account

C++ IDEs for Linux


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
35 replies to this topic

#21 KnolanCross   Members   -  Reputation: 1369

Like
2Likes
Like

Posted 24 February 2014 - 05:08 PM

 

I like Visual Studio on Windows, but I actually prefer not using an IDE on Linux.

 

I like VIM + CMAKE + make at console in a Linux environment, but admittedly using VIM is somewhat self-justifying as an exercise for me to learn VIM, which itself is a useful skill (its nice to know one good non-wysiwyg text editor because you're basically guaranteed to have access to it on any system you can imagine, even minimalist linux systems and often even embedded systems like routers, and/or when you SSH into a remote system). Once you configure CMAKE and generate a make file for your system, building from the shell is as simple as 'make build'. I like VIM as my non-wysiwyg editor, but some people like Emacs, its one of the great nerd holy wars.

 

If I wanted to be a bit easier on myself, I'd probably substitute SlickEdit in for VIM. It's got powerful shortcuts like VIM/Emacs, and is Linux/Mac/Windows cross-platform, but also offers a better wysiwyg/GUI experience than gVIM.

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.

 

 

I use code::blocks when I need to develop on linux and windows at the same time (and vim when I use only linux).

The only thing I find easier to do while debugging on code::blocks is adding break points (break file:line). Other than that I find using the console much more agile (bt, up, down, print, step, continue, finish) specially because the gdb's autocomplete works so well biggrin.png

 

On topic:

You can use VIM, a makefile and some plugins/macros (for instance, I macro F2 to python <file> and F3 to make). I find it pretty fast now, but it took me a lot of time to learn it. So it is your call, I would recommend it only when the programming language is no longer a problem to you.


Edited by KnolanCross, 24 February 2014 - 05:09 PM.

Currently working on a scene editor for ORX (http://orx-project.org), using kivy (http://kivy.org).


Sponsor:

#22 Pink Horror   Members   -  Reputation: 1232

Like
2Likes
Like

Posted 24 February 2014 - 07:46 PM

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.


This used to be my primary "IDE": using vi, grep, make, and gdb all in the shell to edit C files on an Ubuntu desktop. Using the debugger live was the last resort, after logging, coming up with unit tests, or simply grabbing a call stack and going back into the code. I rarely had to do it, so each time was about 10-15 minutes fumbling around with the commands before I got into a groove, but I did it.

#23 Vincent_M   Members   -  Reputation: 749

Like
0Likes
Like

Posted 24 February 2014 - 09:25 PM

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.

The one thing that keeps me from it is how QTCreator doesn't allow me to add source files from outside that project's folder, which of course, Eclipse does as well. You can't even hide files you don't want to compile in Eclipse because it'll refresh whatever's in the directory. The reason I'd want to do that is because my engine's code base also contains a toolchain of pre-built libraries, and their respective includes of open-source libraries such as FreeImage, Box2D, etc for different operating systems. These pre-built libraries are needed for iOS, Mac, Android and Windows, but not Linux because they should be installed from a compatible repository, or built from source depending on the flavor of Linux being used, I think.

I may try QTCreator out again since I really like it's UI elements, and how its C++-like code connects to the designer portion of it. :)

I did try CodeBlocks, but I ran into crashes, and I couldn't save my workspace. I was pressed for time, and gave up on CodeBlocks. I'll go back to it, and give it another shot.

Now, KDevelop looks promising. I'm installing it, and I'll check it out. One thing I'd like to point out is that these projects will only be built for Debian for x86_64 CPUs for now. I don't plan on building any multi-platform GUI apps for Windows for this batch of projects, but it will come necessary later on. Still, KDE won't be on my arcade machine. It won't even have a desktop environment since I'll be cramped for processing power. Not sure if that'll be a problem as I'll be running a GLUT window from a command line program.

MonoDevelop also wouldn't be a bad idea. We use that at work with Unity, so I'm surprised I didn't think of that on my own lol. If it has native C/C++ support, then I could be sold there.

#24 scniton   Members   -  Reputation: 252

Like
2Likes
Like

Posted 25 February 2014 - 12:14 AM


Still, KDE won't be on my arcade machine. It won't even have a desktop environment since I'll be cramped for processing power. Not sure if that'll be a problem as I'll be running a GLUT window from a command line program.
KDevelop, like every other IDE, only requires its dependencies on your development machine. It does not force you to add any dependencies for deployment.


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.
The LGPL licensed Qt option sounds like what you'd want.
Stop twiddling your bits and use them already!

#25 Vincent_M   Members   -  Reputation: 749

Like
0Likes
Like

Posted 25 February 2014 - 02:40 AM

Just an update: I started working with Code::Blocks again since it was already installed, and I have had experience with it back in my PSP Homebrew days. It's working wonders, and I'm pretty happy with the progress I've made tonight. Thanks again for all the suggestions. When I get into GUI tools, I'll either to with GTK+ with Code::Blocks, or I'll to with QT using QTCreator or even KDevelop. KDevelop's UI looks really nice like QTCreator's.

#26 Sponji   Members   -  Reputation: 1361

Like
0Likes
Like

Posted 25 February 2014 - 06:11 AM

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.


Derp

#27 BitMaster   Crossbones+   -  Reputation: 4442

Like
1Likes
Like

Posted 25 February 2014 - 08:56 AM

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.

#28 dejaime   Crossbones+   -  Reputation: 4119

Like
1Likes
Like

Posted 26 February 2014 - 10:18 PM

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, 26 February 2014 - 10:31 PM.


#29 BitMaster   Crossbones+   -  Reputation: 4442

Like
0Likes
Like

Posted 27 February 2014 - 02:59 AM

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.

#30 TheChubu   Crossbones+   -  Reputation: 4802

Like
1Likes
Like

Posted 27 February 2014 - 03:17 AM

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.


"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

 

My journals: dustArtemis ECS framework and Making a Terrain Generator


#31 SimonForsman   Crossbones+   -  Reputation: 6324

Like
1Likes
Like

Posted 27 February 2014 - 04:10 AM

 

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.


I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#32 kaktusas2598   Members   -  Reputation: 890

Like
0Likes
Like

Posted 19 March 2014 - 03:22 PM

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


Deltron Zero and Automator.


#33 Bregma   Crossbones+   -  Reputation: 5499

Like
0Likes
Like

Posted 19 March 2014 - 03:59 PM


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.


Stephen M. Webb
Professional Free Software Developer

#34 Jason Z   Crossbones+   -  Reputation: 5428

Like
0Likes
Like

Posted 20 March 2014 - 08:36 PM

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.



#35 sindisil   Members   -  Reputation: 383

Like
0Likes
Like

Posted 18 April 2014 - 10:56 PM

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!]

#36 fluffybeast   Members   -  Reputation: 132

Like
0Likes
Like

Posted 20 April 2014 - 03:39 PM

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.

 






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS