CompuServe Messages

OK, Jez, but your playing a video game (apparently) and need that stuff — I can't argue with you there. In my environment I've got software to write and work to get done, we can't waste time diddling with what the object code looks like…I've (we've) got product to get out. C is the best tool we can get, given the current technology, C is the best tradeoff between assembly language and other higher level languages. Maybe your people don't really know now to program right (….I'm ducking…) but if you know how the compiler generates code and what code a certain statement will generate, then why not code in 'C?' I know (almost) exactly what the compilers will generate for code and write my 'C' program to fit the various compilers….They all 'think' about the same. Yeah, your average 'C' compiler generates a "couple" of instructions per average statement, but is there any other way to do it? You can be careful to code in a way the compiler generates code, which isn't hard — you must just realize the 'philosophy' in which the compiler thinks, I do, and it hasn't put a damper on my 'C' programming technique (will you call it?) All I'm trying to say is that I think we're arguing two different issues… Whether 'C' works efficiently and effectively to produce a reasonable product, in a reasonable time frame, which works, which performs to expectations… and whether 'C' is better than assembly language. I'm not saying specifically, hands down, etc., that 'C' is better than assembly, *BUT* practically, when you get down to (programmer) throughput and deadlines 'C' definately comes in first in my opinion. With the large memory spaces of todays machines, so what if the code's larger? It's not a big deal. Just write the major portion in 'C' and leave the rest (the real time portion) to assembly. The trade-off's between productivity and real-output seem to make your argument a moot point. It's C!