Subj : Re: "File Scope" objects
To   : comp.programming,comp.software-eng
From : Chris Sonnack
Date : Fri Aug 26 2005 02:55 pm

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?)

>> The thought was they were similar to (private) class variables,
>> which I found an interesting, undisagreeable point of view.
> 
> [...long bit about class variables vs: instance variables...]

Right.

> Much simpler to encapsulate the hidden information within a struct.
> Keep the struct def private, only /declaring/ it in the header. And
> then pass a "this" pointer around the place. That is almost the way
> C++ does it,....

In the snipped part, you seemed to recognize and agree that we were
talking about, as I said, private class variables, but this bit seems
to be going on about instance variables.

I'm confused.  (But, yes, this is one way you can do "Objects" in C.)

> ...the principal differences being (a) that the 'this' pointer is
> done for you via  a little syntactic sweetener, and (b) C++ doesn't
> bother to hide the fieldnames from the user-programmer, relying on
> a syntax error rather than information hiding!
> 
> Of these, I think (a) is a plus, and (b) is a minus. Of course, you
> /can/ hide the fieldnames of a C++ class if you want, but it takes
> a bit of extra work, that's all.

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, 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.


But what does this have to do with file scope (private) variables?

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.


-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

.