 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
C Programming Tips (And stuff that goes around it)
I came across these simple reasons in some site why we love C, and I concur completely:
- C is simpler and more compact
- The reference book is thinner
- It's usually easier to work out what the program's doing
- It generates smaller executables (much smaller in the case of MFC)
- It's more portable
- With good structure and coding practices, it's often just as "safe" as OOP
- Programs written 20 years ago are still just as valid today as they were then
- We're old luddites who hate learning new tricks
If you think you have some problem related to C (On *nix environments only, you do not do programming on Windows!!), mail me at indiangeek (AT) gmail.com, and I'll see if I can solve the problem.
The ISO C standard is available for sell as a PDF at the site of ANSI. No, it's not free. But you do not need it mostly if you do not want to get into those geeky conversations about what 5["abcde"] means.
The best book on C is "The C Programming Language" by Kernighan and Ritchie.
However, it might not be suitable for the beginners. There are some
online tutorials
which can get you started.
Although you can use Visual C++ or some other windows based compilers, I would
strongly strongly recommend using a *nix machine AND, more importantly, gcc
compiler for C. That is where C started from, and that's where you'll find the
most authentic and portable C. In case you do not have access to any *nix (Unix/Linux) machine, check out
CygWin. It's FREE and it will
give you a unix like environment (with all the shell, compiler, library
support) on your Win-doze machine.
C is an elegant language. But, it is quite easy to mess it up, structurally and
functionally. I'll try to cover some of the common areas people make mistakes
on. I'm assuming the reader has at least some programming knowledge, and is at least slightly familier with C.
Process of a C program becoming a runnable one from a text file
GCC Cheat Sheet
Gmake Gotchas
Today I faced a strange Makefile issue with gmake. Assume the makefile as:
%.x %.z:
echo "$(@) $(suffix $(@))"
all:a.x a.z
According to gmake manual:
Similar commands work for all the targets. The commands do not need to
be absolutely identical, since the automatic variable `$@' can be used to
substitute the particular target to be remade into the commands (see section
Automatic Variables). For example:
bigoutput littleoutput : text.g
generate text.g -$(subst output,,$@) > $@
is equivalent to
bigoutput : text.g
generate text.g -big > bigoutput
littleoutput : text.g
generate text.g -little > littleoutput
So, I expected my makefile to generate:
echo "a.x .x"
a.x .x
echo "a.z .z"
a.z .z
But instead it generates
echo "a.x .x"
a.x .x
and ignores the a.z rule.
The problem happens to be that gmake does not really extend an implicit rule to multiple rules, so, after executing it once, it decides to not execute it again.
The solution to this is to use static pattern based rules. Using that, the makefile will look like the following that will solve the problem:
a.x a.z:a.%:
echo $(@)
all:a.x a.z
Weather at My part of the world
