blv@hpctdlk.HP.COM (Bob Vixie) (08/29/89)
I have a problem with inline constructors. We are building a large library of classes that make up our system. Each class is separately compiled and archived into the library. It seems as though each inline constructor is placed in each object file as a static function. My guess is cfront creates these functions because new() requires the address of a constructor as a parameter. I noticed in the man page that the +e0 and +e1 options solve this problem for virtual function tables. Are there similar options for inline constructors? If so, I haven't found them. I am using cfront 2.0 beta 6. -- Bob Vixie blv@hpctdlb.hp.com
bright@Data-IO.COM (Walter Bright) (08/31/89)
In article <1990010@hpctdlk.HP.COM> blv@hpctdlk.HP.COM (Bob Vixie) writes: >I have a problem with inline constructors. We are building a large >library of classes that make up our system. If you make your constructors global functions instead of inline, I suspect you'll discover a major decrease in the size of your program with practically no performance penalty. C++ has a problem in that its syntax makes it easier to make a member function inline than not, so many programmers go overboard with inlines. Some general rules for if a function should be inline or not: 1. Constructors should not be inline. The reason is that even though the body of the ctor looks trivial, the compiler may insert a bunch of hidden stuff (such as base class constructor calls) that can cause a surprising amount of bloat. Grouping all the ctors into one module also portably solves the problem of multiple vtbls without kludges like +e0 and +e1. 2. Member functions should be inline if they consist of one expression, otherwise they should be global.
shankar@hpclscu.HP.COM (Shankar Unni) (09/01/89)
> 1. Constructors should not be inline. The reason is that even though > the body of the ctor looks trivial, the compiler may insert a > bunch of hidden stuff (such as base class constructor calls) that > can cause a surprising amount of bloat. Grouping all the ctors Point well taken. However, if cfront were a little smarter about things like null constructors and constructors for auto objects, this would not be such a problem. (For auto objects, cfront actually tosses out code inline to check to see if the object's address is NULL (!) and calls "new" otherwise. ---- Shankar.