Alaric.us: Yea, that code seems like it should be able to compile. If, when running it, you screw up and try executing
meaning without giving it an
int that it expects, only then should it error out.
I guess all languages and all compilers are different in how they handle things.
Kind of like ... people on a forum. o_O
nipsen: Oh, come on, we were really just about to agree on how everything is this time :p
But yeah, probably there will be warnings, errors or possible uninitiated values no matter what compiler you're using. But because you pass a basic type, there has to be a value assigned to it, and you imply the evaluation in the loop is valid. If it's an object class, and it has evaluation methods for the object declared and implemented, that then you can use in these checks, and so on, you end up being able to tell at compiletime if the check is valid.
Really neat stuff. So you could create an object that must be inside valid ranges based on some criteria you set, for example. Whether you use enums or just make something from scratch, seems to work well. And then the compiler stops you from allowing a possible fail condition like this, was the point :p
This.. still is a sort of metaphor for the forum rules, isn't it..
C can be a bit confusing in this respect. If there is a function prototype in scope, the compiler can and will check against the prototype. So, in my example, if we had the prototype for printf(const char *, ...) in scope, the compiler won't let me pass an integer as the first argument. (I note that, if the prototype ends with "...", the remaining arguments are not checked.)
If there is no function prototype, then no type checking is done. Variables smaller than ints are converted to ints, and floats are converted to doubles. (This means that if the original function expects a float, and it is called from another file with no prototype in scope, you will likely get the wrong result.) If the number of arguments doesn't match, the call will be allowed to go through, and if there weren't enough arguments passed, the function will just use whatever happens to be in the next register or stack location (depending on the C ABI in use), and if the stack is used, I could see an assignment to such variables overwriting important information on the stack.
Modern compilers can warn against many cases that you would expect to fail, but not all, and some of them not unless you enable all warnings. Remember, C does not check these sort of things.
One thing that C *does* prevent that assembly language lets you do is forgetting the return instruction. If you forget to return at the end of a function, the CPU will just continue executing whatever happens to be next in memory, with potentially unpredictable results. There's also the stack; in assembly (assuming the CPU has a hardware stack), if you don't pop the same amount you push, then the return instruction will jump to the wrong location in memory, leading to unpredictable results (possibly including an "Illegal instruction" error).