home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++
- Path: sparky!uunet!brunix!brunix!sdm
- From: sdm@cs.brown.edu (Scott Meyers)
- Subject: inline virtual functions
- Message-ID: <1992Sep15.023336.1403@cs.brown.edu>
- Sender: news@cs.brown.edu
- Organization: Brown University Department of Computer Science
- Date: Tue, 15 Sep 1992 02:33:36 GMT
- Lines: 28
-
- For all the compilers with which I am familiar, inline virtual functions
- are oxymoronic: the function bodies are never inlined, and the object file
- for each translation unit seeing the definition of the function receives a
- static copy of the function. I tested this using cfront 3.0 and g++ 2.2.2,
- and both behaved as I have described, neither issuing a warning about not
- inlining a function.
-
- Many people have discovered this behavior in current compilers, and so the
- following rule is widely followed: "never define an inline virtual
- function." This is a pity, because it's the kind of rule that is easy to
- remember, hence people will continue to follow it even when C++ compilers
- become agressive enough in their optimization to be able to generate
- inlined calls to virtual functions.
-
- I was involved in a discussion of this issue today when it was suggested
- that compilers should generate only a single copy of an out-of-line virtual
- function, and that the single translation unit in which the function
- definition should be generated should be the same as the one containing the
- class's vtbl. This seems sensible to me, so I was wondering: is there some
- reason why compiler implementers don't do this?
-
- Thanks,
-
- Scott
-
-
- -------------------------------------------------------------------------------
- What do you say to a convicted felon in Providence? "Hello, Mr. Mayor."
-