Subj : Re: "File Scope" objects
To   : comp.programming,comp.software-eng
From : Phlip
Date : Thu Aug 18 2005 02:27 am

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.

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.

-- 
  Phlip
  http://www.greencheese.org/ZeekLand  <-- NOT a blog!!!

.