Path: utzoo!utgpu!watmath!clyde!att!rutgers!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!hp-pcd!hplsla!jima From: jima@hplsla.HP.COM (Jim Adcock) Newsgroups: comp.lang.c++ Subject: Re: goodbye cpp ??? (macros vs. inline functions) Message-ID: <6590075@hplsla.HP.COM> Date: 29 Nov 88 18:08:50 GMT References: <3637@pt.cs.cmu.edu> Organization: HP Lake Stevens, WA Lines: 25 > In other words, with new constructs that will have to resemble #include > in many ways, except that they will undoubtedly be more complex. Why bother? Well, for one thing, people are publishing long articles on notes on how to fine tune (by hand) .h files so that you can compile c++ programs in a reasonably finite amount of time. Why not let the compiler figure out these "optimizations" for the user? Also if .h files were kept around in "compiled" form, there could be time savings over recompiling this code whenever the class is used by another class. Also, the .h separation from the .cc file [or whatever extension you use] is just not a natural way to program -- far better to have your class definitions up front in an export section, followed by your functions. As long as there is .h files you cannot do true data hiding of the implementation. Presently compilers have no way of knowing what is really export material verses import material, so that multiple vtables get generated. Of course you can prevent this with a compile time option -- another hack. Finally, is not specification of which classes you really want to build your classes on top of really part of the language? If so, why not recognize this, why force a hack into every .cc file, every class that gets written?