Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!bbn!oberon!panarea.usc.edu!english From: english@panarea.usc.edu (Joe English) Newsgroups: comp.lang.c++ Subject: Re: C++ : A free lunch ? Message-ID: <13179@oberon.USC.EDU> Date: 1 Nov 88 05:00:21 GMT References: <4164@tekgvs.GVS.TEK.COM> Sender: news@oberon.USC.EDU Reply-To: english@panarea.usc.edu (Joe English) Organization: University of Southern California, Los Angeles, CA Lines: 31 In article <4164@tekgvs.GVS.TEK.COM> jans@tekgvs.GVS.TEK.COM (Jan Steinman) writes: >[...] however, in >order to make best use of its object-oriented features you should count on the >run-time overhead that virtual functions, constructors, and destructors impose. > If you aren't going to write object-oriented code, stick to C -- it's much >simpler. Why do constructors and destructors impose run-time overhead? It doesn't matter whether or not your code is "object-oriented," (whatever that might mean) you still have to initialize, and you still have to clean up. Either you do it by hand or the compiler does it for you, but it still has to be done. True, a virtual function call has more overhead than a standard call, but you can only make a standard function call when you know what type of object you're operating on. In many case where virtual functions would be appropriate, that overhead must appear many times over in determining the type of the object. (For example, a graphics device driver which supports multiple devices, and every function begins with a big switch() statement to determine which device is selected. Or it could use a function table, which amounts to virtual functions anyway, and is still less efficient.) C was designed to do low-level programming very efficiently. C++ was designed to do high-level programming very efficiently, and the overheads it imposes are minimal. /|/| "If you think this is bad, you should see what it looks like -----< | | Joe English in *here*!" O \|\| english%lipari@oberon.usc.edu