IDE for C with debugging

Two options are vi(m) and emacs. A nice debugger is gdb. While they may not qualify as IDEs, both are powerful, but require a time investment before you can harness that power. Search the forum and the web for details.
 
Twister said:
Advise please about IDE for C with ability of debugging.
Click to expand...
Full-blown IDEs that (as far as I know) support C are Netbeans (requires Java to run) and Eclipse. Both are available in ports somewhere. There may be others, but I wouldn't know because personally I don't like/need an IDE.

Fonz
 
I never felt comfortable using eclipse for C development, seems to me the IDE is made for something different. I don't use Anjuta, so I cannot express, I use day by day QtCreator which is more a Qt based IDE than a C++ one and it works quite well. I used kdevelop and it worked fine too. And I use emacs for editing everything when I don't need an IDE.
 
gkontos said:
Why is it broken? I successfully build devel/kdevelop-kde4 just yesterday on a FreeBSD 9.0-STABLE desktop.
Click to expand...

Well, last time I tried to use it on a sufficiently large source base KDevelop died on the import. Building it does not mean it can do what it is thought of being capable.
 
I have not much experience on Unix C/C++ development, however my habit is a bit 'deviated', I feel comfortable with eclipse for debug and for the header indexing to watch/search defines, structs and classes on the fly (most for system headers) and it's multiplatform. I still have to try kdevelop, it should be a good IDE (and java free, nothing bad about java but resource expensive). anjuta... no feeling with automake/autoconf based projects, played a few with it's options but nothing more.
 
drhowarddrfine said:
I've been using multiple terms for more than a decade. Nothing's beat it yet.
Click to expand...

Well once you use IDE wrappers for a month for such functions as compile time error highlighting/shortcuts, debugger shortcuts (breakpoint line set, indicators), links to object declarations/definitions just be clicking on it's name, object index for source files, frontends for revision control systems to indicate changes and possible conflicts on the fly, you will think how much time you would have saved producing code all this time when you were using multiple terminals. There is little wrong with not using an IDE for small projects, but when you dealing with a huge code base and multiple people working together its just a big waste of time using anything else than a properly configured IDE.
 
expl said:
There is little wrong with not using an IDE for small projects, but when you dealing with a huge code base and multiple people working together its just a big waste of time using anything else than a properly configured IDE.
Click to expand...
Complete nonsense and totally biased.

Not that there's anything wrong with your preference, but it's exactly that: your preference.

Fonz
 
It's far from being completely nonsense. Terminal editors and tools have nothing to offer over modern IDEs other than being capable to be executed from shell and over ssh, while IDEs (can take eclipse as example) can provide vim/emacs functionality from plugins and much more since they are actual IDEs and not text editors.
 
I'd rather use vim and emacs. The only thing an IDE can offer us is better tracking of object files but I'd bet there's a tool to do that and we haven't taken the time to find that. But that's our workflow and we like to do things our way, not the method provided in an IDE.
 
My vote goes for KDevelop... sorry, but I don't feel like reinventing the wheel in the shell and stressing up my tendons in the process.
All the features that simple text editors doesn't have and that @expl mentioned are quite crucial.

But people is different, for sure ... and people is naturally more productive with certain workflows (worse or better? up to the eyes of the people talking about it), as long as it works for them, I guess it's fine.
In my case, I can't imagine myself hardfscking my tendons (I also study piano, so they are already stressed enough so I can't play with my dear tendons) re-typing functionality and reinventing it, when someone already wrote it, made it cute, and provided that in a IDE.

One of the points I like the most is that KDevelop integrates itself quite well with CMake, so I avoid myself all of the ugliness of Makefiles and I have a portable, efficient and easy to maintain build system.
That if we consider also the powerful parsing capabilities, integrated documentation and such.

Regards, Alex.
 
There is a thing like the right tool for the right job, so let's say each to his own, let's agree to disagree, shall we?

KDevelop may be a great tool, but I must say it failed me here. When you have a source base of >1GB and a lot of teams working on it, merging in things from other contributors, ... you end up with N local definitions of some classes and you really need some clever thing to find out what the variable is you are currently looking at. Is there some command line tool for that, which works on such a large base and does not scan it repeatedly when I want to know who is calling this method or where the definition for this class is?
 
Crivens said:
There is a thing like the right tool for the right job, so let's say each to his own, let's agree to disagree, shall we?
Click to expand...
My point exactly, thank you very much.

Besides, the OP specifically asked about an IDE and has been given some suggestions. The rest is pure thread hijacking. And I do not think I'm wasting my time while coding, like somebody felt compelled to claim earlier in this thread. On the contrary.

Fonz
 
My friend uses Visual Studio for code writing (but, of course, not for compiling or debugging). :)

He downloaded all headers, setup properly all the Include directories and enjoys MSVS with its IntelliSense, Visual Assist and other cool features and plugins. I'm planning to try the same. :)

Re the topic, I prefer devel/kdevelop-kde4.

P.S. Sorry for the off-topic.
 
drhowarddrfine said:
Yes. Talk about off-topic...
Click to expand...

In my previous post I meant that my friend uses MSVS for writing programs for FreeBSD/Linux because MSVS provides a lot of nice features which quicken the code writing process (talking from my personal experience).

I know that this is not what the topic starter was asking for but it still might be interesting information for those who haven't yet decided on IDE. You never know - maybe MSVS + GDB or MSVS + WinGDB will become a perfect match for someone.
 
I'd throw in Codelite. I downloaded it yesterday and it seems like a simple and nice IDE. Of course, there's some serious programming to be done before the final verdict, but for the start it looks OK.
 
@vand777 - How is he using VS on FreeBSD? How is making that work with intellisense? And then compiling with gcc and all that to boot? Doesn't make sense to me.
 
drhowarddrfine said:
@vand777 - How is he using VS on FreeBSD? How is making that work with intellisense? And then compiling with gcc and all that to boot? Doesn't make sense to me.
Click to expand...

As far as I understood him (we just briefly touched the subject), he only writes code in MSVS (he downloaded all system headers to his Windows machine and setup properly Include directories in the MSVS settings), then moves source code to FreeBSD (for example, commits to SVN), then compiles code into native FreeBSD app on FreeBSD machine, tests it.

Also he uses CI server to run unit tests on each commit and integrations tests during the nightly build.
 
He also mentioned WinGDB to me. Do not know the details yet but planning to experiment by myself.

WinGDB's webpage says:

Features:
  • An Add-In for the Visual Studio IDE providing integration with the VS debugger interface.
  • Support for the GDB debugger as a backend (support for other debuggers is planned for the future).
  • Remote Linux debugging through SSH connection.
  • Indirect Linux debugging through SSH connection with gdbserver.
  • MinGW and Cygwin local debugging.
  • Embedded Linux systems and OpenOCD/JTAG debugging.
  • Palm webOS debugging.
  • Seamless integration with standard Visual Studio projects.
  • Project configuration wizard.
  • The "Launch process" command, allowing to start debugging remote or local processes with GDB. The program to debug can be selected using a remote file system browser. Configuration includes, among others: process arguments, environment, working directory, additional source directories, custom initialization scripts.
  • The "Attach to process" command, allowing attaching to remote or local processes with GDB. The process to attach can be selected using a remote process browser.
  • The "Examine core dump" command, allowing to examine core dump with GDB.
  • Mapping source directories allows to map local directories with source code to their remote equivalents.
  • Remote source code browsing in the Visual Studio editor. The files are fetched as needed using SCP protocol and cached over a session.
  • Remote creation/edition of the source code in the Visual Studio editor. Edited file is automatically sent back to the target machine after saving it.
  • Remote build - run make or other build command on remote or local machine. The output of compiler/linker dumps to Visual Studio Console and Tasks windows. User can comfortably navigate between errors and warnings in the source code.
  • Makefile generator - automatically generates makefiles from Visual Studio projects.
  • Visualizers (aka "pretty printers" or "auto expanders") allow easy inspection of complex data structures, like STL containers. This feature is based on Python scripting available in GDB 7.0 and higher.
  • Custom initialization scripts for additional configuration (useful for embedded devices).
  • User runtime scripts to automate repetitive actions.
  • Basic debugger commands: Run, Step over/into/out, Break All, Continue, Run to cursor, Set Next Statement.
  • Breakpoints: setting in remote source files browsed locally. Setting by function name or through call-stack window. Additional breakpoint properties: conditions, hit counting, temporary disabling.
  • Data breakpoints (write-watchpoints in GDB nomenclature).
  • Call stack window.
  • Watch window.
  • Locals window.
  • Autos window.
  • Processes window.
  • Modules window.
  • Threads window.
  • Memory window.
  • Registers window.
  • Signals window.
  • Disassembler view.
  • Console window for debugged process I/O, emulating a XTerm terminal.
  • Generating core dump.
  • Follow fork mode for debugging daemons.
  • Exceptions.
  • Support for 64-bit applications.
  • Byte order support (Big-Endian/Little-Endian).
  • Controlling GDB Server on embedded Linux systems.
  • All settings are remembered per Visual Studio project or solution.

From FAQ:

What about other Unix systems?
When we say "Linux", we think "Linux, or FreeBSD, or OpenSolaris, or OSX, or ...". In general, every platform that GDB and SSH work on, should also work with WinGDB. However, currently available version of WinGDB is being tested only with several popular Linux distros (x86/x86-64), Solaris / OpenSolaris (SPARC/x86/x86-64) and Palm webOS.
Click to expand...
 
You must log in or register to reply here.
Back
Top