Subj : Re: "File Scope" objects To : comp.programming,comp.software-eng From : Randy Howard Date : Fri Aug 26 2005 08:56 pm Lines: 62 Date: Fri, 26 Aug 2005 19:29:46 GMT NNTP-Posting-Host: 71.114.224.30 X-Complaints-To: abuse@verizon.net X-Trace: trnddc05 1125084586 71.114.224.30 (Fri, 26 Aug 2005 15:29:46 EDT) NNTP-Posting-Date: Fri, 26 Aug 2005 15:29:46 EDT Xref: newsmst01b.news.prodigy.com comp.programming:223151 comp.software-eng:113499 Chris Sonnack wrote (in article ): > Richard Heathfield writes: > >>> Having not unrecently read someone speak very much in favor of >>> file scope objects, I'd be interested in a little round-about >>> on the matter, if you're willin'. (I find I have no real opinion >>> one way or the other on this one, although I do tend to not use >>> many of the critters.) >> >> I use almost none. My strategy is to assume there's no syntax for >> them, and write my code according to that assumption. Then, if >> I find myself asking my user-programmers to pass one lousy pointer >> - always the same one - into every single call of every single >> function in a large library, then I might consider "discovering" >> the syntax for a file scope object. > > (Wouldn't that use compromise thread safety?) Thread safety is a very major issue to people developing threaded software and for people writing library code which might be called by such software. But, you have to admit the possibility that not all development projects have or need such a requirement. > I suppose I might argue that one needs to make a little extra effort > to create and use an opaque struct rather than just including the > struct def in a common header. Which would have some advantages if > you ever needed to know the sizeof the thing. Which means you have exposed incorrect interfaces to the caller, otherwise they would not need to know such an internal detail. If that 'black box' theory has any weight, then it has to have some weight. :-) > Which, of course, is exactly why C++ doesn't hide them. So that you > can create local instances (actual objects, not references/pointers > to them). > > And, obviously, one can *just* as easily make opaque structs in C++ > (since C++ is, after all, a superset of C :-). One can also make > opaque classes, but it's a little more work. C++ has the almost singular ability to make almost anything, including the overall source code itself opaque. I am not convinced this is an advantage on average. > One place I've thought of where they are almost necessary is when you > have a constant data structure shared by several functions. Say a > translation table with two-way translation represented by two functions. > > The table is a private file scope datum used by both functions in > the module. That seems to me a most elegant solution. Provided that the data is read-only, or built once on initialization (suitably protected), yes. -- Randy Howard (2reply remove FOOBAR) .