Re: Productive C

Khookie <chris.khoo@xxxxxxxxx> writes:
OK, some stuff not necessarily related to the C spec, but please read
- I would really appreciate advice from your collective experience.
[...]
For
example earlier today, I forgot to update the header file when I
repositioned a few char pointers in a struct. This stuffed me for
about 2 hours - I couldn't figure out why reading struct values in
another module had completely different values than to the module
itself. Anyhow, I digress :-).

If you do things correctly, this particular kind of error should be
nearly impossible to make in the first place. It sounds like you
either have definitions for the same struct in two different places,
or you're accessing members of the struct by some means other than
referring to their names.

Define the struct in a single header. Any source file that needs
access to the struct definition has a #include for that header. The
layout will never get out of synch because there's nothing to get out
of synch.

Another possible way to have this kind of problem would be to change
the definition, but forget to recompile files that depend on it. A
good build environment should prevent that from happening by forcing a
file to be recompiled whenever something it depends on changes. <OT>A
Makefile lets you specify the dependencies, but doesn't automatically
guarantee you've specified them correctly.</OT>

[...]

I also considered implementing the project in Python and then porting
to C once it reaches maintenance mode... but then I'm not sure whether
the gains made by sorting out a nice program structure quicker and
having lots of libraries will be outweighed when I need to bring it
over to C? Maybe I should check out an alternate language like C++/D?
[...]

At a previous job, I had planned to prototype a large chunk of code in
Perl, and then reimplement in C for speed. It turned out the Perl
code was more than fast enough (the major bottleneck was elsewhere),
so rewriting in C wouldn't have helped significantly. (Whether Perl
or C would have been a better implementation language in the first
place is another question.)

--
Keith Thompson (The_Other_Keith) <kst-u@xxxxxxx>
[...]
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.

Relevant Pages

  • [patch 2/15] fs/logfs/logfs_abi.h
    ... * Public header for logfs. ... * I0_BLOCKS is the number of direct block pointer in each inode. ... * remaining five pointers are for indirect pointers, ... +struct logfs_disk_super { ...
    (Linux-Kernel)
  • [Patch 02/18] include/linux/logfs.h
    ... * Public header for logfs. ... Later the inode size was doubled and there are now ... * remaining five pointers are for indirect pointers, ... +struct logfs_disk_super { ...
    (Linux-Kernel)
  • [PATCH 2/3] add open iscsi netlink interface to iscsi transport class
    ... * iSCSI Kernel/User Interface Events ... +struct iscsi_stats_custom { ... * iSCSI Template Message Header ... +/* Command Response PDU flags */ ...
    (Linux-Kernel)
  • Re: API design
    ... typedef struct device device; ... typedef struct device *device; ... code to a new pair of header and source files? ... A source file for each function, ...
    (comp.lang.c)
  • [Patch 04/18] include/linux/logfs.h
    ... * Public header for logfs. ... Later the inode size was doubled and there are now ... * remaining five pointers are for indirect pointers, ... +struct logfs_disk_super { ...
    (Linux-Kernel)