Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!mips!ardent!jra!jss
From: jss@jra.ardent.com
Newsgroups: comp.lang.c++
Subject: Re: Newline hook needed in streams
Message-ID: <9811@ardent.UUCP>
Date: 22 Dec 89 22:53:06 GMT
References: <1989Dec18.132745.5187@odi.com> <9804@ardent.UUCP> <1989Dec22.124143.19874@odi.com>
Sender: news@ardent.UUCP
Reply-To: jss@jra.ardent.com ()
Organization: Ardent Computer Corp., Sunnyvale, CA
Lines: 51

In article <1989Dec22.124143.19874@odi.com> benson@odi.com (Benson I. Margulies) writes:
>
>In general, a half-dozen "virtual" markings in streambufs and streams
>would make this sort of thing trivial. Since the stream library is
>supposed to be the basis of whatever wild flights of imagination the
>rest of us can come up with, IMHO allmost everything should be
>virtual.
>

There is a school of thought that member functions ought to
be virtual unless there is good reason not to.  I subscribe
to the opposite opinion.  Member functions ought to be 
non-virtual unless there is a good reason to make them virtual.
There are costs associated with making functions virtual.
(in terms of the cleanliness of the interface, not just the 
overheads of calling a virtual function.)

In C++, designing the "protected interface" of a class (the
interface seen by derived classes) is an important part of
the design of a class.  It is one of the ways that C++ differs
from other "object oriented languages" is that the public 
interface and the protected interface will normally be different.

When I describe the interface for a non-virtual public member function 
I state certain things about what it is supposed to do.  These are
gurantees for the callers.  They imposes constraints, but 
within those constraints there is a significant amount of freedom
on the implementation.  I don't specify how it manipulates the class'es 
private data, when it is called by other member functions, what malloc 
calls it makes, and so on.  When I specify a virtual member for
the protected interface I must specify much more detail, and that
specification imposes constraints on future implementation.

For example, suppose opfx were virtual. Could it change
formatting flags?  Would that have an effect on the formatting 
that is currently going on?  Many inserters call opfx more
than once (because they recursively call other inserters) are
we constraining when they look at the formatting flags?

I suppose this kind of interface could be worked out, but it would
be a mistake to just make opfx a virtual without thinking very
hard about it.

And, of course there is the performance issue.  At the moment
iostream output is slower than stdio's and there are people who
refuse to use it for that reason.  However, I can imagine an improved
implementation (or improved compilers) that would improve the
performance, but if the interface imposes a function call for every 
character then there would be no hope.

Jerry Schwarz