ssimmons@convex.com (Steve Simmons) (10/05/90)
Why not place all of the instantiations of your global objects in the same file? The ARM does define the ordering of statically allocated object's constructors in the same file. Personally, I think that this is more modular and allows explicit ordering of the constructor's execution among the different global objects. Thank you. Steve Simmons
weh@dryer.ATT.COM (XGPB30000-HopkinsWE(DR9274)237) (10/10/90)
From article <ssimmons.655134998@convex.convex.com>, by ssimmons@convex.com (Steve Simmons): > > > Why not place all of the instantiations of your global objects > in the same file? The ARM does define the ordering of statically > allocated object's constructors in the same file. Personally, > I think that this is more modular and allows explicit ordering > of the constructor's execution among the different global > objects. Given that one of the advantages of object-oriented design & C++ is extensibility and reuse, having to place all file scope objects in the same file negates (some of) the basis for using C++ in the first place. There are two perspectives to this issue: that of the library supplier and user, and that of developer working on an existing base. The library supplier might want to provide some file scope objects (e.g., cout, cin, and cerr in iostreams) as part of the package. To include all file scope objects in one file, the library would have to supply source code the define its objects and the user would have to include that (and all the other file scope object definitions from the other libraries) in a single file. One could no longer simply expect that the necessary definitions would be loaded automatically from the library. This approach places a much greater burden on the library user, especially when you consider how many different libraries and classes one can be using in the same process. For developers working on an existing base, having a single file for all file scope objects introduces the inconvenience that anyone who wants to create a new file scope object would have to have exclusive rights to change the file (the bigger the programming project, the bigger the problem). It creates dependencies between all of the classes that uses any file scope object and the implementation of those objects. Any use of any single object in the file pulls in the rest, and along with them goes (at the very least) their constructors and everything that the constructors use. One of the systems I work on is designed to have users extend it by deriving new classes from the provided base classes. It has the nice characteristic that users only need to load in the files containing their extension; no modification to the existing base is necessary so provision of the source is also not necessary. This is made possible by some of the techniques mentioned earlier on this topic. Lastly, I prefer distribution of knowledge in principle. No single part of the system should have to, in fact should not be allowed to, have access to anything except that with which it deals directly (for the many more pragmatic reasons I've already mentioned). (I can think of more problems with placing all file scope objects in the same file, but I think this get the point across). Bill Hopkins AT&T Bell Labs 11900 N. Pecos St. Denver, CO 80234 w.e.hopkins@att.com