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


GuestBook
Sign My GuestBook

Message

From


Google Search


Computer Dictionary:



Wiki Search



Random Websites

Weather at My part of the world
Weather at Sunnyvale

 


Add Bookmark


This page was last modified on: 09/08/04