Quote:
The main (no pun intended) problem would be if it tried to compile in the middle of me writing a function. I would stop to think, and then it would spit out a block of errors at me.
Quote:
Not sure about it. Most of the time the code would be "incomplete", unclosed braces, unfinished statements...
Quote:
You'd need some heuristic to spot when the user had stopped typing otherwise it would just nag you to death with every character you typed.
As I explained in my original post, this shouldn't be a problem. The compiler should be unobtrusive and polite, like syntax colouring. The code could be coloured to point out syntax errors etc as you type. If you stop typing for a second, and there are no current syntax errors, then the compiler would start silently, constantly updating the various columns to show its progress.
You're still thinking of the compilation process being something which spits out streams of error messages. What I had in mind was a very dynamic/interactive process.
Code which is incomplete would be coloured to show that it contains syntax errors.
Code with warnings might be underlined, and the warning would be shown when you move the cursor to that line.
Code with errors would be another colour, and would go back to the correct colour when the error is fixed. - Why wait until I press 'compile' to tell me about these things.
My PC is 3GHz. !Three Gigahertz! We've become so complacent about computer speeds, we forget that a PC might trivially be able to spare a billion instructions every second. When I'm writing code, is it really too much to ask that my PC spare some time to help me out, instead of just wasting 200W of power waiting for me to press another key?
Quote:
> - How many instruction cycles does each line take to perform.
A totally meaningless metric IMO. You should be focussing on things which matter, and which the compiler is oblivious of, like the Big-O complexity of the algorithms you choose.
I guess I should explain that I had this idea while I was writing firmare for our robots (http://www.shadowrobot.com). As in much microcontroller code, time complexity is never an issue. There are no sorting, searching, or massive data structures to deal with, just lots of linear, real-time critical code. In which case it's very important to know that you're not accidently setting off the creations of large temporaries etc (this is especially true in C++).
Also, when writing firmware for portable devices, the number of instructions taken has a direct effect on battery life. And in a battery life competitive market, that is a *very meaningful* metric. When I wrote the firmware for a digital watch recently, moving from C to assembler increased the battery life of the watch from 6 months to 1.5 years!
Hugo