Introduction The tutorials Links Introductiontop
This is an introduction to my C tutorials (and related programming tools).
Before continuing, I would recommend you to read the excellent article Teach Yourself Programming in Ten Years.
Then you should ask yourself if you really want to learn C (or any programming language). ;-)
Theoretically, you could read through this tutorial quickly, but do not expect yourself to be a C programmer without practice, practice, and more practice.
The goal is to learn about how to use a complete development environment, including the C language, the compiler, and related tools (Emacs, make, gdb, SVN, autotools, etc.).
Why yet another tutorial:
When I learn, I prefer to learn by example.
So I created these tutorials full of examples, as much for myself as for anyone else who might have interests learning C by example.
How to learn:
Everyone has her/his preferred way to learn, of course, but my simple tip is to write a C program or a Makefile completely from scratch instead of using copy/paste - then you will see if you remember the syntax of the document you are writing, and you will learn much quicker.
Tutorials, examples, or guides?:
You should see the tutorials as a collection of examples rather than complete guides.
I have added links to manuals, guides, and other tutorials, but have avoided as much text as possible.
That is because I don't think there is a lack of information on the Net - there is just too much of it... ;-)
A word about platforms:
If you found my website, I guess you at least have some interest in UNIX/Linux-stylish platforms.
Most of the software tools described in this set of tutorials were originally developed on UNIX/Linux.
If you are on such a platform, you probably already have everything you need, already installed.
If not, you can easily install any missing software using ports, packages and/or source code.
Open Source development is available for Mac OSX using Xcode. Most the UNIX/Linux tools are available for Mac OSX as well. Check the Mac OSX developer links for details.
MS Visual Studio is not treated here. MSYS2 is the environment of choice, with package management included.
The advantage of MSYS2 (and MinGW/MSYS) is that it isn't needed to be installed on the target computer to run your developed programs, which is the case with CygWin.
There is also info about GDB on Windows, or checkout the CygWin site.
Information about how to setup (older, more obsolete, less recommended) systems are: MinGW, MSYS, msysDTK (autotools etc.).
The advantage of CygWin is that it is a more complete UNIX-like environment than MinGW/MSYS.
Finally, it is up to your taste to choose between the two.
You can also "mix" the development environment: If you have remote access to a UNIX/Linux box, but are working on a Windows box locally, use the (probably already installed) development tools on the Linux box through for example PuTTY, and use Emacs on Windows to edit the files remotely.
Check the MS Windows developer links for more details.
A word about editors:
If you already has a favorite editor and is decided to keep using it, that's fine, skip reading the rest of this section.
If you don't have a favorite editor, I recommend Emacs, just because I like it. Emacs might have a rather high learning curve, but has been developed by developers for developers, so it is really good when it comes to programming (among other things).
To avoid this high learning curve (or at least make it a little bit smoother), I wrote An absolute beginner's tutorial about editing C files with Emacs. Emacs is highly adapdted to software development, and has a mode before almost anything software related you may think of: cc-mode which highlights and indents your C source code automatically, makefile-mode which highlights and syntax checks your Makefile, you can debug your programs by running gdb inside Emacs, you can control your program versions with CVS or SVN inside Emacs, etc. etc.
Others might recommend vi, because they like it.
You can use even Notepad or Wordpad (though I would not recommend it, as both editors lack any features but basic editing), as long as you save the file in plain text format.
Check the links to lists of other text editors if you want to try something else.
If you wonder why Emacs but no other editors are mentioned in the tutorials, then you know why:
I like Emacs. :-)
C examples - for beginnersRelated links
A C tutorial for beginners.
If you aren't familiar with cc myprog.c -o myprog
then this is for you.
Get familiar with C source code and how to compile a program.
As an absolute C beginner, you may want to see some very simple C source code.
Copy the source code, paste it into your favorite editor, modify it, recompile it, run it, get your feet wet.
Programming in C (external tutorial/exercises by Dave Marshall) Related links
When you're ready to move on (or if you think the previous tutorials are just way too simple), you may continue with this very complete tutorial.
(skip the CDE section and start at C/C++ Program Compilation).
There are lots of exercises in Dave's tutorial.
Take your time, and do as many of them as possible.
Practice, practice, practice...
(I learned a lot from these exercises.)
Makefile examplesRelated links
Learn how to make the compiling of your C programs easier.
When you get tired of typing cc -a -whole -lot -of -flags -and -arguments myprog.c -o myprog
from the command line everytime you want to recompile the C source code, it is time to have a look at make.
To compile (and doing other stuff as well), you just type make myprog.
Or simply make.
Version control with SVN and/or CVS Related links
You can make backup copies of your source code using a simple cp, but there are some problems with this approach:
How will you name the backup file?
How will you name a second and a third backup file?
What did you change/add/remove since the backup from last Tuesday?
What about if you work in a group of programmers, sharing the same code, perhaps over a network?
SVN (Subversion) or CVS (Concurrent Versions System) are two similar and commonly used tools to help you.
Debugging, coding mistakes, memory leaks, performance problems (gdb, splint, Valgrind, gprof) Related links
Learn how to debug your programs with gdb.
It's ok to debug your program myprog.c once in a while by adding lines such as printf("DEBUG: The variable i=d%\n", i);
but you should get used to something more sophisticated (but not necessarily more complicated).
This tutorial shows some examples how to use gdb from inside Emacs, but it also applies to the debugger in general.
For example, you can start debugging with gdb myprog.c., step to the line you want to debug, then inside gdb type exactly the same as you would in your source code: printf "DEBUG: The variable i=d%\n", i
No more reasons for not using gdb! gdb may be run inside Emacs.
It is very convenient with a split window view, one for the debugger commands, one for the source code.
Other important tools to help you produce better code are splint (security check), Valgrind (memory leak check etc.), and gprof (performance analysis, a.k.a. profiling).
Learn the basics about how to create a static and/or shared library:
Create static: cc -g -ansi -pedantic -Wall -O2 -c myfunctions1.c myfunctions2.c ar rv libmystatic.a myfunctions1.o myfunctions2.o cp libmystatic.a /path/to/my/lib/ (optional)
Use static: cc -o executable-nameprog.c -L/path/to/my/lib -lmystatic
Create shared (may vary a lot among platforms): cc -fpic -g -ansi -pedantic -Wall -O2 -c myfunctions1.c myfunctions2.c cc -shared -Wl,-soname,libmyshared.so.1 -o libmyshared.so.1.0.0 myfunctions1.o myfunctions2.o ln -sf libmyshared.so.1.0.0 libmyshared.so ln -sf libmyshared.so.1.0.0 libmyshared.so.1
TODO: ldconfig() etc...
Make the C code of the library portable between platforms: #ifdef WIN32
... #ifdef BSD
... #ifdef LINUX
Create a library for various target platforms:
Use one of the gcc flags -shared, -G, link /DLL, -bundle etc., depending on your platform.
Optionally, archive various libraries into a single file with ar.
Don't dive to deep into the differences between platforms - a libtool tutorial is waiting for you (in the Autotools tutorial)...
Autotools, Cmake, and QmakeRelated links
Autotools (that is, autoconf, automake, and libtools) helps you with the automizing of the creation of Makefiles and the sometimes tricky task to make your code portable.
Cmake and Qmake are two alternatives to autotools.
Distribute your codeRelated links
Distribute your applications - use 'make dist' from Autotools (or Cmake, or Qmake, the choice is yours) to create tarballs, FreeBSD ports & packages, Debian ports? & packages?, Red Hat RPMs, MS Windows installers.
C examples - graphicsRelated links Xlib: To understand how a graphical environment (windows, events, etc.) really works. Xt (X toolkit): The "glue" between Xlib and widgets such as Xaw and Motif. Xaw (Athena Widgets): GUI widgets (controls), included in the X distribution. Motif: GUI widgets as an alternative to Xaw. GTK+: The GIMP Toolkit, widgets originally created for GIMP, accessing Xlib directly, not using Xt. Also for MS Windows. Glade: GUI for GTK+. wxWidgets: Cross-platform (Windows, Mac OSX, Linux, FreeBSD, etc.) GUI Toolkit. Used in aMule, Audacity, Code::Blocks, VLC, among other software. Imlib2: Graphics library for fast execution (X Windows only) SDL: Multimedia library (only graphics treated here) (multiple platforms) MagickWand/MagickCore: APIs for ImageMagick. GD (Graphics Draw): Dynamic creation of PNG, JPEG and GIF images, mostly for web site development. Qt (C++): Cross-platform (Windows, Mac OSX, Linux, FreeBSD, etc.) GUI Toolkit. Used in KDE, Opera, and Google Earth, among other software. Qt+KDE (C++): How to create a KDE application using Qt. Qt+Qdevelop (C++): Using Qt with MinGW and the QDevelop IDE. OpenGL: Cross-platform API for 2D/3D graphics.
Eclipse - Generic IDE with support for many languages, originally by IBM
MinGW - Not a graphical IDE, but a minimal UNIX development environment for MS Windows
CygWin - A non-graphical, not-so-minimal UNIX development environment for MS Windows
I chose this order for the tutorials, as I believe you should first should get acquaintanced with small, simple examples of C code and compiling/linking them from the command line, before writing learning how to write Makefiles to simplify the compiling/linking procedure.
Before learning how to use Autotools to create Makefiles and portable libraries automatically, I believe that one should understand how to write a Makefile manually and create a portable library by hand.
When you also have learned how to create your own distributions, I believe you have gone through all the necessary steps to understand how an application is created from scratch.
Then, not before, I would suggest you to try out a graphical IDE, which will do some or all things for you, sometimes without letting you know what happens behind the scenes (which is the disadvantage of using a graphical IDE). That is, if you still are interested in learning about graphical IDEs...