Subj : Re: "File Scope" objects
To   : comp.programming,comp.software-eng
From : Peter Ammon
Date : Thu Aug 18 2005 12:34 am

Phlip wrote:
> Chris Sonnack wrote:
> 
>>>>...no sane programmer would name a non-local, 'buff'.....
> 
> 
> A flag for the records of physically fit individuals?
> 
> 
>>>I have my own feelings about otherwise sane programmers wantonly
>>>using file scope objects... but I'll keep those feelings local
>>>for now.
>>
>>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.)
>>
>>The thought was they were similar to (private) class variables,
>>which I found an interesting, undisagreeable point of view.
> 
> 
> Give everything the most restricted scope possible.
> 

I agree, but it's odd that you proceed to bring up C++ after stating 
this.  In C++, there's often a tradeoff between restricted scope and 
performance.

for (;;) {
    string s;
    if (cin >> s) do_something_with(s);
}

is slower but more "correct" than

string s;
for (;;) {
    if (cin >> s) do_something_with(s);
}	

> For C++, many classes should live only inside a .cpp file. (Put another way, 
> many C++ newbies think that all class definitions only belong in header 
> files, which is wrong.)
> 
> This discussion uses .h to mean "file included by #include for the usual 
> reasons", and uses .cpp to mean "translation unit".
> 
> The book /Large Scale C++ Software Design/ reveals how we should prefer the 
> leanest possible .h files, including by creating private functions inside 
> .cpp files. Private classes are an extension of this concept.
> 
> C++ supports two kinds of encapsulation, logical and physical. A logically 
> private class, inside a public class, inside a .h file, is not physically 
> private. Changing the class forces every .cpp file that directly or 
> indirectly includes that .h file to recompile.
> 
> Design is about enabling changes, so C++ nicely maps good design principles 
> onto its ancient C-style compiling and linking technologies. So prefer 
> public interfaces in .h files, and everything else hidden in .cpp files, to 
> keep them logically and physically easy to change.
> 

This is an interesting line of thought.  How do you create these private 
functions, though?  Either the private functions need to have all of the 
  data they need passed to them, which is not consistent with 
encapsulation, or they must be declared as friends in the header, which 
requires you to modify the header.

-Peter

-- 
Pull out a splinter to reply.

.