drhowarddrfine
Why I do not like to use pure gdb: http://www.catb.org/esr/writings/unix-koans/oldhand.html
Why I do not like to use pure gdb: http://www.catb.org/esr/writings/unix-koans/oldhand.html
I am sorry guys, I have used gdb numerous times, but having a GUI (I am talking about an X-window desktop environment - xfce, kde, gnome, you name it- with windows etc, and I do not consider dozens of tiled terminals as a GUI) and being able to see locals, your watched variables, stack etc. makes life easier....
I ran pkg install codeblocks and all was working fine. So far the easiest IDE to work with for simple console applications.I tried installing devel/codeblocks but after displaying its logo it just core dumped.
Any suggestions on what to look for?
I believe the purpose is to have an IDE to be able to create .so and .lib and manage the projects easily with a specific compiler.If you do not want to install or you don't need a glitzy GUI styled IDE or Emacs (actually a pretty friendly environment written by Richard Stallman), you can use vim or you can simply use the built-in debugging UI of GDB, by executing gdb with the “-tui” option:
View attachment 4253
Here it's shown debugging a simple OS kernel from Visopsys.org. The advantage of using the bare gdb debugger is that it will teach you the basics of debugging, without a fancy front-end GUI that may shield details that could help deeper understanding. Emacs works via direct interaction with the debugger as well. Maybe that combo could be a sort of intermediate step to get you going, since it's a very simple command line startup. Instant gratification, and not much prior knowledge needed.
I kinda like emacs for small projects (grin). Here's what tha man has to say about it:
I agree with your statement. I was impressed at clang vs gcc and compiling once my project with clang convinced me it is a far superior providing useful feedback tot he developer.(Quite an old post but...)
If you are just starting out with development, then codeblocks is great. However if you are looking at honing your skills professionally, then IDEs are simply too inflexible and the better developers that I have worked with avoid them.
Perhaps try the following instead:
1) clang (C Compiler) or clang++ (C++ compiler)
2) gedit (simple text editor) or vim, emacs (more advanced text editors)
3) gdb, (Debugger so you can set breakpoints, step through the program)
One of the main reasons why IDEs are limited is because they don't well integrate the following important tools:
cmake (cross platform build system. Visual Studio .sln or code::blocks .proj files are not often used by other developers)
valgrind (runtime memory checker)
splint (static analysis)
doxygen (generating callgraphs / reverse callgraphs is very important for large teams)
jenkins / hudson (Build systems work with the command line. They often have very limited support for IDEs)
git / svn (version control support is always lacking in IDEs because the proj files or settings files do not merge well).
root@baikal:~ # cd /usr/ports/editors/codelite/ && make install cleanThis is one thing I am missing as well....CodeBlock was "okay" but the port has been broken for a while...
I may give a go to editors/codelite, seems like the best bid I (we) have... I have never been a java/eclipse fan to be honest, hence do nto want to go down the Eclipse + CDT track.
The main thing I am looking is a decent integration with gdb.
PS : Lately, I have done some iOS development, hence used Xcode and I think it rocks...
Testing netbeans. Interesting chicken and egg situation to use a java netbeans to implement a C solution - remains pragmatic though.I'm a big fan of java/netbeans but as its location implies that's mostly because of my Java development. However, Netbeans also supports C/C++ these days and to my understanding also has excellent debugging support (including step traces). Unfortunately I program more with Java than C/C++ so I can't share hands on experience.
An IDE should allow you to manage/build projects into a solution offering an easy a simple syntax highlight edition. Debugging/tracing is a nice to have (like a cherry on a cake) but the cherry does not make the cake to my personal view.With an IDE I should be able to set breakpoints and view variables, but programming serial ports is a bit out of my league. I couldn't see any outputs from any printf's but maybe I couldn't figure out where code:blocks shows outputs. Maybe I'll try using gdb...
I have by the way issues running the GBD from code blocks: it simply does not run properly.Code blocks opens a separate window for your stdout.
One IDE not yet mentioned is JuCi++. It uses CMake as its build system.
Pros: Well integrated with clang. Where Code Blocks would display some obscure STL template header file while single-stepping the debugger (currently it only knows GDB even when compiling with clang/clang++), JuCi shows me the actual source location in my code. Auto-complete in JuCi makes editing a CMakeLists.txt file much easier.
Cons: UI in JuCi is very barren. A few commands (like clean / rebuild-all or closing out a project), are either not there or not obvious.
Thanks to JuCi, I don't hate on CMake as much as I once did.
> pkg install juci
In the future, in order to avoid such confusion, why not backup and lock the threads forcing newcomers like me to start a new thread.ahrkahrg This thread was started over five years ago and ended four years ago. It would be wise to start a new one.
I personally find the debugger a tool allowing easy/lazy programming. I believe a true developer should be able to point out a bug or issue using printf on the console. This night be difficult for GUI application but a log file can do the trick. Working without a GBD forces you to think and analyze the code instead of test and try.
Personally, I have experienced that debugging in a multiple thread environment, most of the time, the debugger leads you to wrong places. In a multiple thread env. Temporal Logic and a good analysis of the code prevails certainly when you are facing an overrun on one thread jeopardizing another. In that case a debugger is useless (but that is from my experience)You still need the debugger to get backtraces.
And debug by printf, although clearly the most successful general debug method , introduces artificial synchronization in multithreaded code, so sometimes you can't use it.
Then there are undo debuggers that can execute code backwards, which are very useful.