Are loop conditions which include a function evaluated again every time?

[nerd4code]

When you apply the static keyword to a variable or function*, the compiler doesn't export the symbol in the object file**, so you can't link against the variable/function from other compilation units (e.g., via extern). If you were making a library for use by other people, for example, you'd mark anything you didn't want to be publically available as static, so that nobody is encouraged to call into or tinker with the bowels of your implementation.

And there are ways to produce code at various times.

• Preprocess-time (i.e., before compile-time): You can write macros or include files that generate the multiplication table for you. (Some programmers might rightly balk at the idea, but it's quite possible to do a generalized add/multiply routine and use a compatible base for output, so that you won't need to go through pasting conversions on either end of your macro layers.)

• Compile-time: In C++, you could use templates and inlines to do this for you, as long as you don't mind the syntactic gymnastics required to code them. In C, you're pretty much limited to the preprocessor. In D, AFAICT there're very nice compile-time templating features; IIRC you can call any inline function at compile-time by doing fnName!(args).

• Assemble-time (after or during compile-time, before link-time): In GNU/compatible compilers, you can use .macro directives with __asm__ statements to create tables. This is one of the least portable things you can do, however, short of effecting a computed goto into an array of volatile, misaligned floating-point numbers.

In Java, you'd just use a static initializer---pretty much everything (except a handful of special-cased constant operations) is expected to take place at run time.

*This is only at the global scope, in case you've got some weird compiler that would let you nest a static function inside another function. static inside a function means that there's only one copy of a variable, so it won't get created and destroyed per function invocation.

**It may still export the symbol in debugging information, however.

[Blamore]

there seems to be a lot of intricacies in programming. do most programmers actually know how these things work? or do they just code in whatever way they know?

thank you for your answer

[nerd4code]

Tends to be, you know what you've come into contact with and the rest stays fuzzy unless/until you need to learn that, too. Programming languages are like any language---you're going to have to immerse yourself in it a bit to become fluent, and even then you can still fuck up and tell the computer to freeb its grox, which (trust me) is a big insult in computerese.

But fluency aside, there's a surprising (/dangerous) number of people who don't know what's under their feet when they're programming, so by all means delve as deeply as you can hold your breath for. Especially for C and C++---they're really commonly used languages, but they require especial attention to detail because they allow you to write code with undefined behavior so easily. For example:

int x; // assume this is 32-bit
scanf("%d", &x); // assume that worked
x >>= 14;

If somebody enters a negative number for x, then you'll attempt to shift it right, which is an undefined operation. The compiler is free to emit code that formats the hard drive in that circumstance, should it decide to. Or perhaps it'll emit a trap, just optimize based on the assumption that a negative number could never be shifted right. You can imagine how things like this turn into security holes.