Xref: utzoo comp.object:2453 comp.lang.c++:11352 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!apple!ames!sgi!shinobu!odin!sgi.com!linton From: linton@sgi.com (Mark Linton) Newsgroups: comp.object,comp.lang.c++ Subject: Re: Inheritance and Information Hiding Message-ID: <1991Jan29.221121.20642@odin.corp.sgi.com> Date: 29 Jan 91 22:11:21 GMT References: <1991Jan23.224203.3206@runx.oz.au> <1991Jan24.214652.18515@Think.COM> <27A44871.5586@tct.uucp> Sender: news@odin.corp.sgi.com (Net News) Reply-To: linton@sgi.com (Mark Linton) Organization: sgi Lines: 31 In article <27A44871.5586@tct.uucp>, chip@tct.uucp (Chip Salzenberg) writes: |> According to tynor@hydra.gatech.edu (Steve Tynor): |> >In practice, I've found C++ `private's to be overly restrictive and in |> >violation of the rule "it is not the buisiness for a class to decide how |> >it may be extended in the future" (paraphrased from OOSC). |> |> An interesting "rule" -- one with which I happen to disagree. |> |> In any case, language features don't stand up and say, "Use me!" Who |> can say that there will never be good reason to make members private? |> Not I -- even though I use "protected" five times more often than I |> use "private". |> |> >It's another example of a C++ feature that actually reduces the reusability |> >of C++ classes (non-virtual member functions being the other obvious one). |> |> Virtual functions are available when appropriate; but I'm just as glad |> that I need not pay the performance penalty when I don't need them. Private is for things that might change. If you make them protected and then change them, you break subclasses. So if you're not willing to commit to keeping something around, then you should make it private. After starting with the attitude that I should make things by default protected, I now believe the appropriate default is private. If I make something available to a subclass, I should think carefully about what I am giving out. As for virtual functions, if you can't live with cost of a virtual function call you are unlikely to be happy with the cost of a direct function call. A virtual function call typically adds a few memory references on top of what is likely a considerably more expensive operation, involving register save/restore and a branch.