[H-GEN] C code.

[In memory of Mighty]

On Tue, 28 Oct 1997, Anthony Towns wrote:

> Reading in a nice GUI with a 1024x768 or better resolution on a 17"
> (or better) monitor is the _only_ way to code.

	I like my 6 simultaneous vt editing sessions in the old text
mode...

> > There is a serious lack of vertical whitespace,
> Somewhat agreed. The only places I really noticed it is in the
> allocation function and the test harness. Elsewhere the indenting
> works fine for me.

	Well, this was before I actully tried to comprehend any code at
all.  I was just studing code density.  It was exaggerated somewhat by the
fact that lynx only lets you (well, me) move up and down about 1/3 page at
a time.

> > Oh.  You've got it in the header file as an extern char.  That
> > comes close to making sense, but the only reason you would do it is to
> > prevent having to rewrite header files... 
> No, the real reason is to avoid duplicating the array's contents in
> every place that includes the header file.

	That's compiler stuff.  Nothin' to do with me <smile>  I'm more
interested in beatiful code then saving a 40 bytes.  I would have at least
put a comment into the .c pointing at the corresponding .h definitions
(and vica versa).

> > 	Ahh, I should have read the comments in the header file before
> > devling into the C. 
> Like _duh_.

	Hey!  You're supposed to be able to understand a .c without having
to go to the .h except for precise type definitions etc.  Well, I think so
anyway <shrug>

> > The EXIST and NEXIST are success results... So one
> > function returns ERROR/NEXIST/EXIST, and another returns ERROR/OK.  I
> > still don't like it though.  I would seperate them into two types of
> > return value (both integer naturally). 
> Both enumeration types, you mean, surely.

	Well, yes.  I said integer because I was thinking about
comparisions.  The end user would have the option of saying something like
if (return>0).  I like having specific ranges of failure and success...
maybe a few extra #defines stating the boundaries.

> > I can see that you want to avoid straight
> > boolean because of the common confusion as to when a return value should
> > be true, and when false, but this amalgamation is... but then I'm picky.
> Bah. "if ( AddValueToTable(...) )" reads perfectly unambiguously.

	That's true in this case, but over the course of a large program
with many people working on it, it can be difficult to orgainise a
coherent standard.  My project group hit this problem when it came to
implementation, standard fix: !x.

> true/false returns are ambiguous only where they shouldn't have been
> used in the first place. Returning whether something existed already
> or not is an excellent example.
> 
> Hmmm.
> 
> Another way to do that might be:
> 
> bool AddValueToTable( Table *t, void* v, void** oldv );
> 
> where oldv is NULL if there was no old element and points at the old
> element if there was. It still mixes return values, but possibly does
> it mildly better that way.
>  
> > 	A bit ugly having to alloc twice during init, but no real way
> > around it... not unless you want to got the dirent way and put an array[1]
> > at the end, then just malloc what you need <cringe>
> 
> Yeah. That's also not entirely legal C, either.
>  
> > Oh, and I don't like ==.  One
> > of my phobias coming from numerical maths.  I know and you know that your
> > code is written using unsigned in,
> In any case, having a negative number is beyond meaningless (it has
> negative meaning?) so if I, personally, found someone trying to
> maintain that piece of code who didn't realize what was going on
> I'd... Well. I'd ask Bruce for advice. Put it that way.

	But the same can be said about a zero value.  It's not documented
that a 0 will put in a default size.  I would make all such invalid values
into the default size range, and probably raise a warning if HASH_DEBUG.
I just hate seeing even remotely possible undefined behavior in a
program...

> > You're only undefining it to define it again with comments around
> > it.  I hope none of those strings have close comment characters in them
> > <evil grin>.  
> Comments are removed before macros are substituted in.

	<thinks for a moment>  Are they removed from the macro lines?  I
would guess not.  If so, then you're just left with empty code.  If not,
then you've got unstripped comments in your code.  I'm assuming it
compiles and runs, so it must strip them out of #defines... that's ugly.
I really don't like macro definitions used in this way.

> > I'd personally make it another function.  That way it can
> > accept non-fixed strings, doesn't have to comment the code out, and
> > doesn't need a complex definition.  
> And it requires a function call that just plain isn't necessary.

	<sigh>  A function call provides clarity.  It is nessisary.  If it
turns out to be a performance hit (meaning it's within a very tight inner
loop) then you -optimize-.  That of course means finding a compiler that
does inline functions!

> C isn't a hard language. It's not unreasonable to expect people who
> code in it to actually _know_ it, IMAO.

	I disagree.  Everyone reading your code should be treated like an
idiot.  They should be able to understand it after not sleeping for three
days, and having lost their mother tongue.  Clear code is almost always
better than unclear code.

> > It can include an ifdef HASH_DEBUG
> > around the code within it, and I would probably give the compiler a pragma
> > to inline it, just to be sure it didn't cost a performance hit on release
> > day.
> 
> You can't inline C functions.
> You can with gcc, and you can in C++, but you can't in C.
> At least, not until C9X comes out.

	Well, if the compiler doesn't understand the pragma, it'll ignore
it.  If it really is a big enough performance hit to go through all this
hassle, then you might as well take the time to install gcc.

You have been enlightened       | The fresh air coming through a window
by the fuzzy one                | reminds me of the outside world.
                                | It's something I don't want to
Forsaken I sit in with a radio  | remember right now.
blaring.  When did my fire burn |
so low?                         | s335810 at cello.it.uq.edu.au
                                |
memory at techie.com (personal)    | It's now I despise my humanity.


----------------------- HUMBUG General List --------------------------------
echo "unsubscribe general" | mail majordomo at humbug.org.au # To Unsubscribe