A major design feature of the world's
most advanced transportation system,
the capacity of the engines on the
Space Shuttle, is determined by the
of a horse's arse. In the same way,
the world's most advanced computers are
limited by the size of our naughty
How are we supposed to be perfect when
Nature only gave us 7 registers? By the
time the initial solution is half
coded, programmers usually wish they'd
written the code another way.
The problem is that it's hard to go
back and update existing code.
As a trivial example, if you want to
rename a function, you have to change
the name in the code, the header, and
everywhere the function is called. So
much time is wasted doing this, yet
this is something the computer could be
doing. It could nearly be done with a
for "*.c *.h" loop and sed.
The problem is that sed doesn't
understand C code. It wouldn't have a
clue whether the "fred(" in its buffer is
the start of a function declaration or
a function call. So Step 1 is to
write a sed that does understand C
code. Tedious but not hard.
Now we can change function names with a
"csed --funcname s/oldname/newname/".
We can now also change global variable
names without touching local variables
with "csed --global s/oldname/newname".
And update function parameters. And
insert function calls in the right
places. And delete function calls.
Lots of things like that.
If you're modifying library code that
other projects use, you can generate
csed commands to go along with your
updates. The development teams on
the other projects can then run those
csed commands on their own code (with
the "--ask" option of course!) to do
the finding, tagging and most of the
conversion for the tweaks and updates
to your new API.
Sure, it can't do everything
automatically, but you can tag csed
changes with explanations, possibly
even with URLs to relevant
documentation, which is inserted into
code above the changed functions to indicate
which parts need more attention to
complete the conversion.
You can also use this same code to grep
for what you want. Looking for a macro
definition? Type "cgrep --macdef
MACRONAME *.h". Want to know where a
function is called? How does "cgrep
--calls funcname *.c" look? Want to
know how much code depends on a
function when planning a change? Try
"cgrep --calls --descend funcname *.c".
That's quite a lot of useful
functionality for embedding a simple C
parser into grep and sed. Also allows
for a few useful extensions too.
I'm in the middle of coding this now.
It's boring, but it's one of the tools
I need for what I REALLY want to do.
The visualisation part.
More on that topic next entry.