Newsgroups: comp.std.c++
Path: utzoo!utgpu!craig
From: craig@gpu.utcs.utoronto.ca (Craig Hubley)
Subject: Re: overloading vs. virtual functions
Message-ID: <1991Mar8.071056.24199@gpu.utcs.utoronto.ca>
Organization: Craig Hubley & Associates
References: <1991Feb25.201923.14554@gpu.utcs.utoronto.ca> <15488@prometheus.megatest.UUCP>
Date: Fri, 8 Mar 1991 07:10:56 GMT

In article <15488@prometheus.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes:
>From article <1991Feb25.201923.14554@gpu.utcs.utoronto.ca), by craig@gpu.utcs.utoronto.ca (Craig Hubley):
>)))The fact that C++ implements the two mechanisms [virtual functions and
>)))overloaded functions] so as to create (in my opinion) counter-intuitive
>)))effects is (in my opinion) a flaw in C++.  That is, the programmer must
>)))be very much aware of the "seam" between compile-time and run-time ...
>
>Anybody who can not handle this "seam" should be programming in LOGO.

Yeah, and anyone who can't handle raw bit-shifting should use Pascal.
While we're at it, who needs databases ?  I can open files and dig through
'em.  And who needs CASE ?  I got a gaw-damm disassemblah heah, boah!

I can "handle it".  I have programmed in LOGO, and LISP, and FORTH, and
there are definitely advantages to languages that have interpreters AND
compilers that can make the code act the same.  I have also programmed
in 6502 assembler, 6809 assembler, 68000 assembler, WSL, weird BASICs, C,
and other languages that gave access to the raw bit-level of the box.
Portable code doing this kind of manipulation is far harder to get right,
because the fact that it works on the first 10 boxes you tried it on doesn't
tell you much about the 11th.

Accordingly, modern programming languages don't force you to do much
bit-shifting, allowing you to rely on higher-level primitives most of the
time and only descend into bits when you really need to do so.  The same
is true of compile-time vs. run-time binding, as others have already quite
adequately demonstrated by comparison to other languages.

Nobody is saying it can always be hidden completely, particularly in real-
time applications.  But most of us are saying that it isn't necessary for
language syntax to force programmers to hard-code the difference into
every scrap of code they write.  Consider, what if you write a piece of
nice general source code to deal with three different kinds of objects -
and then call it in a context where, by the language definition, the
type of that argument is KNOWN, unambiguously.

I can't ask my compiler to take advantage of this potential optimization, 
if I have also asked it to guarantee me the difference between runtime 
and compile-time binding.  To deal with this situation in C++ as it stands, 
I have to write three different functions and call THOSE when I know what
the type is.  I can never let the compiler figure it out for me.  If I
want it to do so, I gotta suffer the virtual lookup overhead every time.

The much-prized machine-level efficiency you bit-bangers are so enamored of
comes much more cheaply when it can be generated by a compiler and not a 
human programmer.  In the dark ages of C, if you wanted to avoid unnecessary
function call overhead you had to rewrite your function as a macro.  Often
you had a function version and a macro version side-by-side for use in
different circumstances.  In the more enlightened C++, we use "inline" and
let the compiler do it.  Of course we are AWARE of the difference, but it
doesn't cause us anywhere near the inconvenience, doesn't make us maintain
two versions, and if "inline" doesn't always guarantee savings, then that's 
all right.  We have to profile the code anyway.

Of course, there is always the possibility that you will not understand
the rules that the compiler uses to make these decisions.  If the only
way a programmer can tell what his code will do, is to hard-code all of
its runtime behavior himself, then I suggest you go back to assembler, 
where every little choice was up to you.  And where you had to hack up
your code to make the tiniest little optimization.


-- 
  Craig Hubley   "...get rid of a man as soon as he thinks himself an expert."
  Craig Hubley & Associates------------------------------------Henry Ford Sr.
  craig@gpu.utcs.Utoronto.CA   UUNET!utai!utgpu!craig   craig@utorgpu.BITNET
  craig@gpu.utcs.toronto.EDU   {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig
