kimcm@ambush.UUCP (Kim Chr. Madsen) (03/14/88)
In article <1185@ucsfcca.ucsf.edu> rk9005@cca.ucsf.edu (Roland McGrath) writes: >One real stupidity I've seen many, many times is the >over-use of printf. The printf functions have their uses, >and they do their job quite well, but please know what these >uses are!! Well, printf has its uses and does them remarkably well - in fact so well that almost every program does at least have one printf statement! As others claimed inclusion of code for puts and putchar et al will only make the code larger and possibly slower to execute, I will take a different approach in defending the usage of printf... The printf statement is one of the most universal I/O routines in the C language which can output in almost any way you like - this gives you the opportunity to nearly always stick to the same output routine, thus keeping your code more readable to others (and non-C-programmers). If you clutter up your code with too many output routines your code will be less understandable and more prone to be bug filled. I have nothing against non-printf output routines and uses them where appropiate, but I do not often mix them altogether in one piece of code. Best Regards Kim Chr. Madsen.
mike@hpfclq.HP.COM (Mike McNelly) (04/01/88)
> In article <960@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes:> > >Compilers do not have the ability to understand the functionality of the > >procedures being called and alter the code (and arguments!) accordingly! > What you mean to express by "understand the functionality" appears nebulous to > me. As I said before, nothing practical prevents one from including the > semantics of standard functions in compilers. Conversions from one sequence of > statements to another with equivalent semantics can be expressed using > attribute grammars. > >Apart from anything else, the "functionality" of printf and puts is only > >determined at *link* time! > Again, it is unclear to me what you mean by determination of "functionality." > It is true that in a typical compiler, the only optimisations done are > flow-of-control optimisations (e.g. induction variables reduction in strength, > live variable analysis, code motion) and computation and storage optimisations > (e.g. elimination of common subexpressions, copy propagation, constant folding, > register allocation) *within* the code being compiled. Calls to external > functions can be treated atomically, as "black boxes" -- but there's no rule > that says they *have* to be. If a function is part of a standard library, then > rules can be included in the compiler for simplification of those functional > expressions. > To take a simple example, suppose I have a standard function called expt which > takes a floating-point argument and raises it to a power. Suppose I have a > functional expression "expt(x, 2)". So rather than calling in my high-powered > expt function it would be much simpler to do a floating-point multiply of x*x. > This is a reduction in strength which encompasses an invocation of a standard > function. (Suppose I had an exponentiation operator "**" s.t. "x ** y" gives > the value of expt(x, y). Then there would be no external function involved, > and everything would be straightforward.) > So *why* do we never see semantics of standard functions included in compilers? > Because, in my opinion, it's not worth it. It makes the compiler dependent on > the standard libraries. If my compiler's rules assume a particular > implementation of a standard function, then if I change the implementation I'm > liable to have either to change the compiler or to live with inefficient code. > In summary: There is no inherent limitation of compilers which prevents their > knowing about standard functions. Despite this, we never see compilers playing > with standard functions, because that would create too much of a tangled mess > of dependencies. So Fai Lau was being unrealistic in saying that compilers > which don't do this sort of thing are unimaginable. Yet at the same time, it > is wrong to assert, as Ray Dunn does, that such optimisations are impossible. > Comments are welcome. I think that one aspect has been missed. True, the compiler can certainly understand the semantics of a routine such as printf() or sin() or whatever, most easily if the routine is within that file. However, there's no guarantee that the programmer doesn't have his own version of these routines that is intended to be linked into the a.out. Unless you reserve these names as part of the language (not C) or provide some disambiguating construct (again not C) it's not possible to determine the programmer's intent until link time. Mike McNelly hplabs!hpfcla!mike
ray@micomvax.UUCP (Ray Dunn) (04/13/88)
In article <3850011@hpfclq.HP.COM> mike@hpfclq.HP.COM (Mike McNelly) writes: I write: .Compilers do not have the ability to understand the functionality of the .procedures being called and alter the code (and arguments!) accordingly! [someone] writes (I did not see the posting): .What you mean to express by "understand the functionality" appears .nebulous to me. As I said before, nothing practical prevents one from .including the semantics of standard functions in compilers. Conversions .from one sequence of statements to another with equivalent semantics can .be expressed using attribute grammars. .etc..... Mike writes: .I think that one aspect has been missed. True, the compiler can certainly .understand the semantics of a routine such as printf() or sin() or whatever, .most easily if the routine is within that file. However, there's no .guarantee that the programmer doesn't have his own version of these routines .that is intended to be linked into the a.out. Unless you reserve these .names as part of the language (not C) or provide some disambiguating .construct (again not C) it's not possible to determine the programmer's .intent until link time. I don't think that *one* aspect has been missed. My whole point has been missed by [unknown] as clearly stated by Mike above. In *'C'* the compiler does *not* know what the definition of printf etc is. Yes, the meaning of printf *could* be restricted to some pre-defined value, the compiler *could* be given such information, or it *could* do a library search at compile time, the language *could* be defined so that general user defined procedures calls could be replaced with optimized in-line code, etc, etc. The generalizations made above by [unknown] are indeed possible, but aren't we discussing 'C' or at best 'D', which we hope would be of the same family? Ray Dunn. ..{philabs,mnetor)!micomvax!ray