In article rch@cronkite.seas.gwu.edu, obinnau@gwis2.circ.gwu.edu (Obinna C. Ugwu-Oju) writes:
> The question is why C++ does not make member funtions virtual by default
>                  its imptortance in code reuse?


This is an important question, and gets at one of the most common
misunderstandings about C++.  Bear with me a moment, because I need
to go into a little background.

C++ was designed to be a compatible successor language to C.  To
succeed at this, the language had to introduce enough new features
that programmers would be motivated to make the switch, without
being hopelessly incompatible or eliminating strengths that had
made C so successful in the first place.

One of C's long-standing strengths was its suitability for low-level
systems programming that traditionally required the high performance
of assembly language.  In fact, the first large-scale use of C was
in the development of UNIX, which was the first large-scale portable
operating system.

Now, Stroustrup came along, and the *last* thing he wanted to do was
introduce unseen overheads that would make C++ incapable of matching
C's performance in the application domains where C was traditionally
strong.  Stroustrup has said that, had he done this, C++ would not
have been accepted as a logical successor to C.  You can argue with
this reasoning, but I am inclined to agree with him.

That brings us back to virtual functions--which, for all their importance,
do introduce an extra layer of overhead that can be, in some applications,
unacceptable.  Classes that have virtual functions are also layout-
incompatible with C, and providing C compatibility was another feature
Stroustrup felt was indispensible to the acceptance of C++.

So, C++ gives you the *opportunity*  to use more-advanced features (like
virtual functions), but never forces them on you.  And, if you want a
feature that provides greater power at the expense of performance, you
generally have to ask for it.

To those who bristle at these explanations, I would only point out that
the world is full of languages that have neither the advantages, nor the
burden, of being a successor language to C.  Those who find the burden
more troublesome than the advantages have always had the freedom to look
elsewhere.


---
Marc Shepherd
Salomon Brothers Inc
mshepherd@mhfl.sbi.com  The opinions I express are no one's but mine!

In article <3nm11s$rch@cronkite.seas.gwu.edu>,
   obinnau@gwis2.circ.gwu.edu (Obinna C. Ugwu-Oju) wrote:
> The question is why C++ does not make member funtions virtual by default
>                  its imptortance in code reuse?

As soon as you make a function virtual, you are making a statement about how
that class (and that function) should be used.  You are expressing a design
decision.  More specifically, you are _loosening_ the design.

Functions should be virtual only if derived classes (which I like to call
"inheritance clients" since they are essentially clients of the inheritance
interface) may or must override them to provide specialised behaviour.  Most
functions are not virtual because they are (or at least should be!)
invariant over specialisation; they should not be redefined.

I like the idea that if you want a function to be virtual you must
specifically say so; this accords with good OO design and makes you think
about what you are saying in the design.  Consider the alternative: "if you
want a function not to be virtual you must specifically say so" seems to my
eye to be a recipe for fragile code and unintentional bugs, as leaving out
the new "nonvirtual" keyword even by accident means that you are _loosening_
the design even by accident.  It's much better to make the more restrictive
decision be the default, so that you have to specifically override it to
loosen those restrictions (for purposes of polymorphism and/or
specialisation -- I say "and/or" because the two often, but don't always,
appear together).


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Herb Sutter                 2228 Urwin, Ste 102         voice (416) 618-0184
Connected Object Solutions  Oakville ON Canada L6L 2T2    fax (905) 847-6019

In article <3nm11s$rch@cronkite.seas.gwu.edu>,
Obinna C. Ugwu-Oju <obinnau@gwis2.circ.gwu.edu> wrote:
> The question is why C++ does not make member funtions virtual by default
> its imptortance in code reuse?

One of the Stroustrup books says, or at least hints, that the reason
for this is performance.  I believe this was the consistant 5%
overhead that was eliminated, but I could be sadly mistaken.

Warner

 The question is why C++ does not make member funtions virtual by default
                  its imptortance in code reuse?