CompuServe Messages

> You don't give up that much. C is quite efficient, and compiles into fast >code. There are also ways of arraging to trim out much of the "canned code" >(I'm referring to c.o and some of the stuff it invokes) if you're familiar with >your C compiler's environment. For instance, Jim is referring to code that might do behind the scenes start-up stuff, for instance, command argument processing. There are also other things that can be done with the canned stuff (for instance, bringing in a printf that doesn't use floating point, etc). Equally, I think it is important to agree that in general, the "expense" of things like start-up code, or printf, is quickly insignificant for any non-trivial application. And when say bloat is a concern, say when ROMing, or trying to squeeze a product onto a floppy or something, options are available. >Assembler coding is always faster and more compact .. IF YOU'RE AN EXCELLENT >PROGRAMMER. But some optimizing C compilers can put out code that's as compact >and efficient as many (not all) programmers would write. I think that's an overstatement. I'd rather just say that most compilers, even the non-optimizing ones, can put out good enough code. In case where it matters, yes, the optimizer can help. In cases where it cannot, it is still up to the programmer. Perhaps the programmer was just sloppy in allocating too many arrays, and their respective sizes, for instance (and hence many opt for dynamic allocation with the known size, etc). As well, instead of second guessing, the programmers should obtain a profiler and check out where their app might be being bottlenecked and work from there. Etc.