I'm coming from Java, where I'm used to things like debuggers, static type checking, and object inspectors. C seems difficult not due to the language itself so much as my inability to figure out what's going on with only print statements.
I found a bunch of tutorials on gdb, which are what prompted me to think about this. Now that I have a debugger, what other tools exist that aren't built into the language?
Is there a reason that you've chosen C? C is a fairly low level language, so some of the features you desire may not be necessary. For example since C is not considered an OOP language you will probably have problems finding "object inspectors". Also the language it's self doesn't have any tools other, than the compiler, linker, and preprocessor. Depending on your OS there may be programs to help with memory debugging, profiling, and leak detection. Also the debugger is probably one of the primary tools to debug C programs.
Visual Studios has a lot of tools.
Other than that, I'd say valgrind and gdb
Visual Studios is not recommended if you are interested in programming in C.Originally Posted by xcuseME
I believe Visual Studios does not support C11 and C99 only enough to support MS C++.
gcc and clang are the best choices for C compilers, and are available on Windows by installing cygwin or Min-GW64.
Of course, both gcc, clang, gdb, valgrind, and many other tools are best used on Linux.
Note: valgrind does not work/exist under the Windows OS.
Tim S.
"...a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are,in short, a perfect match.." Bill Bryson
I use Linux. Want to do CS 50 and then the dragon compiler book, hence my desire to learn C.
Emacs
(if you are a vi person, there is a popular configuration for evil-mode called spacemacs, to give you vi keybindings)
linters: gcc and cppcheck, among others, can be integrated into Emacs with flycheck to provide on-the-fly syntax checking.
debugging: DDD graphical debugger can be integrated into Emacs with gud-gdb. DDD uses gdb as an inferior debugger, so your normal gdb command line is visible in an emacs buffer. So you will see your mouse clicks turned into gdb commands. Or if you have a debugger command too complex for the gui to handle, you can still type it at the gdb command line.
build systems: GNU Make, Autotools, etc. You can run gcc or make in Emacs compile-mode, and stepping through the errors will take you to the appropriate place in your source code to edit. (I also use compile-mode to run other linters such as flawfinder or splint that are too annoying to integrate into flycheck.)
libraries: There are other libraries beside's the C standard library that are quite useful. Many of them are packaged up in your operating system's standard repositories. For example, Glib is packaged in Ubuntu as libglib2.0-dev. You will need pkg-config for finding libraries.
version control: Git. Emacs has a standard package included for version control that supports git, but there is another one called magit that is very popular.
There are profilers such as gprof and documentation generators, such as Doxygen, though I have not used such things.
A disadvantage? to Emacs is that you will need to learn lisp to configure it properly. Although that may be an advantage because many of the beginning computer science courses have you write a lisp interpreter as lisp syntax is simple to parse. Though I don't know if that is true for CS50.
man pages: Manual pages for POSIX library calls are in manpages-posix-dev package in ubuntu.
C is an imperativeprocedural language. It was designed to be compiled using a relatively straightforward compiler, to provide low-level access to memory, to provide language constructs that map efficiently to machine instructions, and to require minimal run-time support. Despite its low-level capabilities, the language was designed to encourage cross-platform programming. A standards-compliant and portably written C program can be compiled for a very wide variety of computer platforms and operating systems with few changes to its source code. The language has become available on a very wide range of platforms, from embedded microcontrollers to supercomputers.
Ohhh, let's copy paste Wikipedia.
C (programming language) - Wikipedia
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
It's kind of funny/ironic that you find this so difficult so far because I've programmed in C#, Java (shoot me), JavaScript, Python, etc... And I actually find C one of the easiest to debug and work with now.
The cool thing about C is that the tools are all tried and true, and they work really well. I also write and reverse x86 assembly though, so I have a slight advantage because I don't need source-level debugging and can generally handle problems at the assembly level when needed.
Even still, gdb is indeed a great debugger. You can use commands like "list" to show the source, break on specific source lines, run, then use the examine commands to view memory and CPU state as needed. This has helped me squash a lot of bugs.
If I can't do it in gdb, I end up using something like Evans Debugger on Linux or x64Dbg/x32Dbg on Windows, I break near the problem, and I step the assembly code outputted from the C compiler and see what the hell is going on.
It sounds like valgrind will serve you well for memory leaks but in case you ever do have to work on Windows, there is a very similar program called Dr. Memory that I use which is helpful.
Compiler Explorer can also be useful if you need to see a quick disassembly of your code or check how the compiler is assembling your code given different options and versions.
I use Vim and Sublime Text to write my C code, and I use the command line to compile... This seems to work for most C programmers with the exception of some game programmers I know who like to use the Microsoft Visual Studio crap for some very select things like the debugger and they also build with Microsoft's C++ compiler due to its optimization features and stuff. I'm not educated much on that, so perhaps GCC can do the same but that's just what I've seen. Also, you may wonder why I said C++ and that's because the guys I've seen writing game C code use the C++ compiler even though they basically don't use any actual C++ constructs. The Microsoft world gets murky when it comes to C vs. C++ because for example, the Win32 API supposedly is written with "C++" according to Microsoft, yet it uses absolutely no C++ constructs and so far I've been able to copy/paste and use all the APIs directly in C with a C compiler.
Last edited by Asymptotic; 03-21-2018 at 10:44 PM.
If I was homeless and jobless, I would take my laptop to a wifi source and write C for fun all day. It's the same thing I enjoy now!
Pelles C has an IDE with Bult-in Debugger. I used to work as an engineer and we made custom motherboards specific to what we did with no operating system. We didnt even use a debugger. We used an led and print statemensts, lol. Thanks Asympatotic that was a very informative post.
I'm tired of dealing with forced complexity of mandatory object-orientation found in Java. I really don't see the point to half the things I do - most of the time it's simpler and much easier to not be object-oriented.
Case in point, my version of the disc image I/O code for Playstation 1 CD-ROM disc images. It's just 3 methods in a data handler class, and 4 or 5 methods in an EDC/ECC generation class. The Java code I found that also implements disc image I/O is spread across dozens of classes; it's so convoluted that I can't follow it. I had to find and translate python code that does the EDC/ECC, and write the directory sector navigation logic myself.
Object-Orientation is nice sometimes but it's more hassle than it's worth. I don't like forcing people to install Java to run my code either, and in some environments (the more obscure Linux distros) there isn't a Java distro.
Actually, you don't need that utility to view the assembler source.
The assembler output for the compiled source will be in "hello.s". You really should only be concerned with the versions of the Distro, compilers (And options), processor, kernel, libraries, etc... you have installed, or available on your system.Code:$ gcc -s hello.c
That's cool! Care to recommend a book on gcc?
How would I do that if I were cross-compiling for a different platform, to examine the assembly source a program would create for it? And how would I specify that a specific platform doesn't have floating point operations or registers?
As for a "book on gcc", start with Using the GNU Compiler Collection
As for cross-compiling, it is not something that I do, but I would think you would need to know which processor you are cross-compiling for first. Then I would start with a simple Google Search for more information on cross-compilation.
