Subj : Re: OO compilers and efficiency
To   : comp.programming
From : Rob Thorpe
Date : Thu Jul 21 2005 03:06 am

Flavius Vespasianus wrote:
> "Rob Thorpe" <robert.thorpe@antenova.com> wrote in
> news:1121849306.769176.300410@g43g2000cwa.googlegroups.com:
>
> > Flavius Vespasianus wrote:
> > Calling a virtual function may be though.  For example, the code
> > must:- <add the offset of the function in question to the base vtable
> > pointer> <from that address load the function pointer>
> > <save caller saved registers on the stack>
> > <construct call frame for the passed args, possibly not needed>
> > <call the function>
> > <make a stack frame>
> > <return from the function>
> > <restore caller saved registers>
>
> Calculating the address of the virtual function can usually be done
> through indexed mode addressing.

It need not take that many instructions, it may in the case of a
machine without an indexed addressing mode such as MIPS.  On MIPS you
must load both numbers into registers, add them, then branch to the
address (4 instructions).
On some x86 machines the microarchitecture may break the indexed
operation into smaller steps internally.

There are also several machines that support indexed addressing but on
specific registers, such as the stack and instruction pointers.

> The stack frame setup is the same no
> matter what language you use. Using temporaries can cause problems. Use
> const references to get around most of them.

Yes, getter and setter functions should not use temporaries, so no
stack frame need be built for them.

> >> The alternative, in the absence of OO is a large case statement;
> >> hardly efficient either.
> >
> > What the OP is talking about is using getter and setter functions
> > rather than global variables.  So, in this case a load from memory
> > could be used instead.
>
> If it can be done in one or two instructions, there's no reason the C++
> can't inline it into the same number of instructions.

Yes, so long as the method is not virtual, which was my point above.

> > Interesting, personally I think C is a beautiful programming language.
> > There are many better languages today, the problem is that they are
> > not so well known.
>
> For elegance in systems software, you should see BLISS. Too bad AT&T was
> giving C away for free while Digital was charging $40,000 (10 times what
> it charged for C) for Bliss. Bliss had an unbelieveable macro language
> that you could build all kinds of tables with. Bliss also allowed you to
> lay out structures down to the bit level, something great for systems
> work.

Yes, many languages have been made that are safer and better than C.  I
was saying that despite it's flaws C is an elegantly designed language.

> It's unfortunate that language usage has been driven by hype and
> marketing factors rather than actual usability. I find it amazing that
> there are people out there who actually think that C# or Java are
> improvements over C++.....or that the Java byte code was an original
> idea.

I know, it's a pity.

> I do a lot of code conversion from C++ to Object Pascal and every time I
> find many programming errors in my C++ code because of Pascal's much
> better error checking.
>
> For my main project, it takes several minutes to compile the C++ version.

That's an odd thing to do.  You convert code from a standard language
with many compiler vendors, to a non-standard language with only one
compiler vendor and a smaller base of skilled programmers.  Still, if
you want.

> The equivalent Object Pascal code compiles in less than a second.

There are many reasons for this, the biggest three are:
1. The object pascal compiler is very fast because it doesn't optimize
much
2. Many C++ programmers write very sub-optimal makefiles
3. C++ has syntax that is difficult to parse, compared to C or Pascal
for example

I only consider #2 to be really a fault of the C language.

.