TITLE: The cose of inlining methods PROBLEM: mcneill@devon.co.uk (Keith McNeill) On our project we've made a rule that all member access functions should be inlined. We now have is HUGE .o's, exes (using Sun's cfront) and painfully slow complilation which I think is a large part due to all the inlining. What do folks out there on the net do as reguards to member access inlining? RESPONSE: steve@taumet.com (Steve Clamage), 16 May 93 I use this rule of thumb: If the size or speed of the body of the function is comparable to the cost of calling it, the function should be inline. Otherwise it probably should not be inline. Use care in evaluating the cost of the body of the function. You may write an empty body of a constructor or destructor, yet the compiler may be generating a great deal of code. For a constructor, the compiler will generate code to intialize all of the base classes and all of the members, even if you write no code of your own. It will also initialize the virtual table. If base classes or members have their own constructors (explicit or implicit), the generated code will include those. Similar considerations apply to destructors. Constructors and destructors of derived classes or of any class with members requiring constructors should seldom be inline. This may be the cause of your code explosion. Similarly, do not inline functions which take parameters of class type by value or return a class by value. They will each require a constructor and destructor.