Thread: Marching coordinates

It is. It's a minimum of 512 AFAIK, though on some of my computers it's 8192. It's used for setbuf etc. I like to use it as the amount of memory to increase a string by when I run out (see codeform).

[edit] What's that about a double-linked list? (I think it's "double-linked" and not "doubly-linked" BTW. It's like "fine-toothed comb", which is actually "fine tooth-comb"; there was once a fine type of tooth-comb. ) [/edit]

Well, here are the arguments that I'm aware of (for anonymous enums):

FOR
enum values are compile-time constants, so the compiler can give you better error messages if, for example, you try something like this:

Code:

enum { X = 10 };
int X = 10;  /* whoops */

Also, debuggers are better with enum values (which is more readable, 10 or X?)

AGAINST
enums are not supposed to be used in that way, so it could become harder to read or something.

And for #defines:

FOR
#defines are processed by the preprocessor, so you can change their values via the command line and Makefiles etc.

AGAINST
See FOR for enums.

I think I'd prefer to use enums for values like string lengths, but #defines for things like the path to ls (that you might want to change without edited the source).

[edit] Basically a restatement of brewbuck's post above. [/edit]

Originally Posted by twomers

>> [edit] What's that about a double-linked list? (I think it's "double-linked" and not "doubly-linked" BTW. It's like "fine-toothed comb", which is actually "fine tooth-comb"; there was once a fine type of tooth-comb. ) [/edit]

It was in your first point where it went into 1(a) and 1(b). Very impressive. Two lists. But in one. And I said a doubly listed list. Not linked.

>> It is.
But then why not simply use that instead of your enum? Seems similar to hearing a zebra run!

Sorry, I'm so used to reading "double-linked list" that I see it everywhere . . . but I bet you'd have said "doubly-linked list" if you'd mentioned one.

Because I might want to change it.

Code:

enum { STRING_LEN = BUFSIZ*2 };
enum { STRING_LEN = USHRT_MAX };

The preprocessor will turn that into "int 10 = 10;" and the compiler will barf. No problem there.

No, but it will give you an error like "invalid variable name" you you'll think, "what? X? invalid???". Whereas if you have an enum by the same name it will give you a much more palatable error. (I should imagine anyway.)

I'm aware of the const-ness of string literals. I just use #defines for them because I like inserting them into strings with the preprocessor's string concatenation.

Code:

fprintf(stderr, PROGRAM " version " VERSION " by " AUTHOR "\n");

Because I usually use puts() instead. It's a case of premature optimization. You're right, it's not a good idea . . . I think I'll avoid it in the future.

I still like enums though. The main reason being that, in C++, you can put them in namespaces etc. No doubt const variables would be a better idea in that case, though.

It was in your first point where it went into 1(a) and 1(b). Very impressive. Two lists. But in one.

You could always say a "nested list".

Me too, for multiple lines usually. Sometimes I run into a GCC error message to the effect of "string length is longer than the C89 standard of 509 characters". I think that's for 509 chars + 1 NULL + 2 chars for string length to fit into 512 characters, but I'm just guessing.

Originally Posted by joerg

x[0]=0;
y[0]=0;

for(i=0;i<N-1;i++)
{
if(x[i]<1) x[i+1]=x[i]+Vx*dt;
else x[i+1]=x[i]-Vx*dt;

Help! I want the coordinates x[i] change from 0 over +1 to -1 and back as often as i<N. The program counts from 0 up to 1 - O.K. - but then oscillates from 1 to 0.9 and so on.

Have you considered a lookup-table type of thing for the x[]?

Code:

#include <stdio.h>

double foo(int i)
{
   static const double a[] = 
   {
      +0.0,+0.1,+0.2,+0.3,+0.4,+0.5,+0.6,+0.7,+0.8,+0.9,
      +1.0,+0.9,+0.8,+0.7,+0.6,+0.5,+0.4,+0.3,+0.2,+0.1,
      +0.0,-0.1,-0.2,-0.3,-0.4,-0.5,-0.6,-0.7,-0.8,-0.9,
      -1.0,-0.9,-0.8,-0.7,-0.6,-0.5,-0.4,-0.3,-0.2,-0.1,
   };
   return a[i % (sizeof a / sizeof *a)];
}

int main(void)
{
   int i;
   for ( i = 0; i < 1000; ++i )
   {
      printf("%4g%c", foo(i), i % 10 == 9 ? '\n' : ' ');
   }
   return 0;
}

Actually that's what I was suggesting with the memoization, but figured it wasn't worth it since the lookup table would be 40 elements. Plus I was using an algorithm to generate the lookup table, which I realized I could just bypass the lookup table and just use that algorithm to calculate the values themselves by modulating them over 40.

What's the "static" do when you say "static const double a[]"? I'm familiar with static from Java, but have never seen it used in my short time with C, since C isn't object oriented, and static from Java is an object-oriented term.

Originally Posted by IsmAvatar2

What's the "static" do when you say "static const double a[]"? I'm familiar with static from Java, but have never seen it used in my short time with C, since C isn't object oriented, and static from Java is an object-oriented term.

The static causes the array to be allocated statically (like global variables) instead of on the stack. If it were on the stack, the program would have to copy the contents of the array into a new array on the stack for every single call to the lookup function. But because it is static, the array "just exists" and the function refers to it without having to construct it.

EDIT: In this case, it means pretty much the same thing as "static" in Java -- the data belongs to the "class" (running program) instead of the "instance" (function invocation). The "static" keyword was taken from C for use in Java, so it's no surprise the idea is similar.

If something is a static global variable, it means something slightly different -- the global variable is exactly like any other module-level variable (e.g. globals) but it cannot be referenced outside the module it is declared in. So "static" means two different things in C.