tags:

views:

200

answers:

4

how does compiler determine there is run-time error ? Is it run the code and then decide whether code executable or not?

Another question: Are there any program which are capable to determine complexity of my executable code?

Are there any code which is for measuring the time when code start to execute up to finish?

+4  A: 

Compilers don't determine if there is a run-time error, they handle syntax errors only. A run-time error is, by definition, something caught at the time of running the program.

The few tools I've used for measuring program complexity have been pretty useless. They tended to work on simple programs but most of the code we put through them either broke them or solicited inane suggestions (I'm pretty certain our code is as complex as it needs to be, and no more). But, for measuring run-time and resource usage of programs, you have a wide variety. Probably the most common is the time utility in UNIX and its brethren.

It actually runs the program inside a "wrapper" which measure elapsed and CPU times.

Alternatively, you can do on process accounting and collect all sorts of CPU, I/O and memory stats on all processes for later analysis.

paxdiablo
@paxdiablo. Compilers don't do it, but there are tools which try and predict runtime errors without actually running the program.
Moron
"Try" being the operative word :-)
paxdiablo
@pax. Yup, but some of them are pretty good, actually.
Moron
@Moron: If you mean some programs can flag constructs that are likely to cause runtime errors, that's true. I rather doubt programs can do a good job of predicting runtime errors in general, and I know that it's impossible to do a perfect job.
David Thornley
@David: Yes, that is what I meant.
Moron
+4  A: 

Homework or not, you need to read up on the Halting problem if you think there are such algorithms that are guaranteed to work.

Hint: a program that could determine if another program will throw a runtime exception would solve the halting problem ...

catchmeifyoutry
+3  A: 

The compiler doesn't determine run-time errors. The compiler is responsible for checking syntax errors, type-checking and other things. Run-time errors occur after the compiler has done it's job. An example would be checking an array with a subscript higher than the number of elements (segmentation fault). The operating system kills the program when it does this because the program could be trying to do something malicious (like over write other areas of memory that don't 'belong' to it) but in general its considered 'undefined behavior.'

I don't know of any programs that determine complexity but if there is it would probably be very specialized to specific cases.

and here's a code snippet of a simple timed program

#include <stdio.h>
#include <time.h>

int main() {

 clock_t before, after;

 before = clock();
 int i;
 for(i=0; i<1000; i++);
 after = clock();
 printf("%.2f seconds to run 1000 iterations of a blank for loop\n", (double)(after - before)/CLOCKS_PER_SEC);

 return 0;
}
Tom
I have to say that's an unwise way to check performance. The `clock` call measures elapsed time so will depend entirely upon other system loads - the 1000 loops may mitigate that problem somewhat but you're better off using a tool that gives you CPU times rather than elapsed times.
paxdiablo
orly? I was under the impression clock() returned the number of clock ticks the program used since the program was launched. I tried looking it up but the docs I found don't specify whether clock() counts clock cycles used by other programs or the OS so you could be right. It does say that the initial moment of reference can vary between systems, hence calling it twice and subtracting for a consistent reading.
Tom
A: 

If you are using a unix-like OS, you can use the time command to tell you just how much CPU time your program is taking.

Example:

The program:

#include <stdio.h>

int main(void)
{
   puts("Hello, world!");

   return 0;
}

The result:

tpost@tpost-desktop:~$ time ./hello
Hello, world!

real    0m0.001s
user    0m0.000s
sys     0m0.000s

Its handy to see of 'optimizations' are actually doing anything good.

Tim Post