Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!princeton!allegra!alice!bs
From: bs@alice.UucP (Bjarne Stroustrup)
Newsgroups: net.lang.c++,net.micro.atari16
Subject: Re.: C++ preprocessor wanted
Message-ID: <6174@alice.uUCp>
Date: Fri, 10-Oct-86 22:04:21 EDT
Article-I.D.: alice.6174
Posted: Fri Oct 10 22:04:21 1986
Date-Received: Sat, 11-Oct-86 21:09:35 EDT
Organization: Bell Labs, Murray Hill
Lines: 78
Xref: mnetor net.lang.c++:367 net.micro.atari16:2477

Moshe Braner writes:

> Regarding the need for a C compiler that would handle long
> identifiers, y'all might not know that Megamax recognizes
> the first 10 chars, and allows very long total length.
> That may still not be enough for C++ - I dunno.

You can survive with C++ and only 31 significant characters in your C
compiler and linker. Don't try with less. If you have only 31 significant
characters complain (politely) to your compiler and linker supplier. Such
complaints have been known to have a positive effect - eventually.

> (and you still need to get that C++ preprocessor...)

The C++ translator, known as cfront, is a preprocessor only in the sense
that the UNIX C compiler is a preprocessor for an assembler. Calling it
a preprocessor is misleading.

Probably the best way of thinking of cfront is as the first pass in a
classical two pass compiler: cfront does a complete syntax check, a
complete type check, expands inline functions, adds temporary variables
where necessary, makes implicit initializations explicit, makes implicit
type coercions explicit, etc.; finally it produces an intermediate form
of the program to be read by the second pass. Using C as the intermediate
form is very useful for portability.

Any error messages produced by a C compiler while processing cfront output
is considered a bug in either cfront or the C compiler. By definition cfront
does not rely on the C compiler for anything but code generation.

> BTW: I devised a method to do object-oriented programming in C.
> Not fancy but simple, and you get inheritance and even late binding
> of sorts with high efficiency (about 100 microSecs for a typical
> invocation of a method).  If anybody is interested let me know.

This made me curious about what the cost of a C++ virtual function call
really is so I ran this example on a VAX11/750:

struct s {
	virtual f();
};

s::f() {}

main() {
	s* p = new s;

	for (int i = 100000; 0<i; i--) p->f();
}

It took 4 seconds; that is, about 4 microseconds per iteration.
For comparison I also ran

f() {}

main() {
	for (int i = 100000; 0<i; i--) f();
}

It took 3 seconds; that is, about 3 microseconds per iteration.
Finally I ran:

main() {
	for (int i = 100000; 0<i; i--) ;
}

It took .5 second. All timings are averages of several several runs.

These times were a bit disappointing in that I could measure the difference
between a virtual function call and a ``normal'' function call but, I think,
not bad. You can do a fair bit of work with a million function calls.

Maybe I ought to mention that with virtual functions there is no difference
between calling one virtual function twice compared with calling two virtual
functions once (many schemes for method lookup involves a slow first call
followed by fast subsequent calls so that simply invoking the same method
a million times would be a too easy test). No trickery, inlining, optimizing,
etc. was involved.