C4 – C in 4 functions

Post by bjornsing » Wed, Nov 05, 2014, 3:52 PM UTC

  $ time ./c4 c4.c c4.c hello.c 
  hello, world
  exit(0) cycle = 9
  exit(0) cycle = 22614
  exit(0) cycle = 9273075

  real	0m0.067s
  user	0m0.067s
  sys	0m0.000s
  $ time ./c4 c4.c c4.c c4.c hello.c 
  hello, world
  exit(0) cycle = 9
  exit(0) cycle = 22614
  exit(0) cycle = 9273075
  exit(0) cycle = 933197195

  real	0m5.834s
  user	0m5.827s
  sys	0m0.000s
  $ time ./c4 c4.c c4.c c4.c c4.c hello.c 

Post by maffydub » Wed, Nov 05, 2014, 5:06 PM UTC

peterfirefly wrote: post #110

maffydub wrote: post #107

Earlier quoted context omitted.

It's taking an integer (representing an operation) and printing out the name of that operation. First thing to say is that "* ++le" is the integer representing the operation to perform. This basically walks through the array of instructions returning each integer in turn. Starting at the beginning of the line, we have "printf" with a format string of "%8.4s". This means print out the first 4 characters of the string…

How is that not self-documenting if one knows C?

Post by DSMan195276 » Wed, Nov 05, 2014, 5:40 PM UTC

MrTortoise wrote: post #95

DSMan195276 wrote: post #73

Earlier quoted context omitted.

I agree with you completely - The code explains what you're doing, comments explain why you did it that way. Ideally, any comments that explain what you're doing would end-up being redundant when looking at the code. I think this code details a special case of the above though, in that it comments what the enums are instead of just naming the enums. I give that a pass strictly because this code needs to be able to co…

Its not that simple though, error fixes and edge cases often obfuscate something that was understandable. A why comment is never bad, but a what comment is often as valuable as a test

Post by vajrabum » Wed, Nov 05, 2014, 6:24 PM UTC

ajkjk wrote: post #78

_wmd wrote: post #43

Earlier quoted context omitted.

Unless you're talking about a large piece of software composed entirely of single character functions and variable names, I pretty much disagree. Verbose variable names do not magically teach those reading a piece of code how it works, simultaneously they tend to make it impossible to write many kinds of expressions concisely, and consequently they regularly damage the readability of more complex pieces of code (e.g.…

I mostly strongly disagree. I see no value in naming a variable 'tk', 'pp', or 'bt'. It can only help to make the code more readable with less context. I do not need to understand compilers in detail to know what this program is doing, except, for the names being useless. And if I do understand them but have not spent half an hour or probably much more to digest the exact system by which it operates, I would be compl…

    tk,       // current token

Post by moron4hire » Wed, Nov 05, 2014, 7:09 PM UTC

peterfirefly wrote: post #126

maffydub wrote: post #123

Earlier quoted context omitted.

I think you and I might disagree on the meaning of self-documenting. ;)

I don't think we really do. It is impenetrable black magick if one "knows" C -- but quite clear if one /actually/ knows C.