home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++
- Path: sparky!uunet!spool.mu.edu!sol.ctr.columbia.edu!ira.uka.de!slsvaat!us-es.sel.de!dada
- From: dada@us-es.sel.de (David Ashley Davies)
- Subject: Re: Virtual methods
- Message-ID: <1992Sep15.095940.13974@us-es.sel.de>
- Keywords: interrupt handler virtual methods
- Sender: news@us-es.sel.de
- Organization: SEL-Alcatel LTS Dept. US/ES
- References: <#7vnafk.feustel@netcom.com> <1992Sep14.145950.7661@us-es.sel.de>
- Date: Tue, 15 Sep 92 09:59:40 GMT
- Lines: 26
-
- In article <1992Sep14.145950.7661@us-es.sel.de>, brendan@us-es.sel.de (Dalton) writes:
- |> feustel@netcom.com (David Feustel) writes:
- |>
- |> |> Coplien's book "Advanced C++" makes the point that very little overhead
- |> |> would be incurred in most programe even if all functions were declared
- |> |> virtual and that some programs might even run faster than equivalent C
- |> |> programs using switch constructs to achieve the same effects.
- |>
- |> This reminds me of a question which I've been meaning to ask for some
- |> time now. Ignoring performance issues, why would one not declare every
- |> method in a class virtual? What circumstances might preclude its use?
-
- 1/ Interrupt handler. Has to be static.
- (Or does anyone out there know of some wonderful o-o hardware that
- gets around this problem?)
-
- 2/ Prevent subclass override of method definition.
-
- As far as overhead is concerned, there were reported speed improvements of
- 10-20% using object pascal (all virtual) and the MacApp class library against
- conventional case (switch) code processing the event loop. On the other hand,
- the bloat in executable size was also about 20%. Swings and roundabouts.
-
- David.
- _______________
- David A. Davies
-