typedef /struct and the scope problems

[Jordan Abel]

[re starting identifiers with an underscore]
It can be useful on struct members as a "suggestion" to users of an API
that the member is "private".

Surely a more effective suggestion is to have the API pass pointers
to an incomplete struct type, and not let the users see its contents
at all.

Not if you also want public members. Or even allow for macros to access
bits of the struct

 

[Michael Wojcik]

[Sorry for the late reply; I have been out of the office.]

[re starting identifiers with an underscore]
It can be useful on struct members as a "suggestion" to users of an API
that the member is "private".

Surely a more effective suggestion is to have the API pass pointers
to an incomplete struct type, and not let the users see its contents
at all.

Not if you also want public members.

Obviously, but that's another advantage of my suggestion: it avoids
mixing public and private data in the same type, which is a Bad Idea.

If you really can justify a mix of public and private data in one type,
make it a struct of public members and a pointer to an incomplete
struct containing the private ones. There, that wasn't so hard, was
it?

Or even allow for macros to access bits of the struct

Premature optimization, generally. Unless an accessor call is in a
time-critical section of code, this trades robustness (from opacity
and abstraction) and ease of maintenance (because the calling code
needn't change) for a dubious - sometimes nonexistent, thanks to
caching effects - performance gain.

OO programmers are finally coming around to the understanding that
public members are bad for software maintenance. It'd be nice
(though unrealistic) to think that most experienced C programmers had
already figured that out.

--
Michael Wojcik (e-mail address removed)

Advertising Copy in a Second Language Dept.:
Tapestry of the encounting and the farewell, the birth and the death.
You can hear the human being's song running through the 100 years.
-- Squaresoft

 

[Jordan Abel]

[Sorry for the late reply; I have been out of the office.]

[re starting identifiers with an underscore]
It can be useful on struct members as a "suggestion" to users of an API
that the member is "private".

Surely a more effective suggestion is to have the API pass pointers
to an incomplete struct type, and not let the users see its contents
at all.

Not if you also want public members.

Obviously, but that's another advantage of my suggestion: it avoids
mixing public and private data in the same type, which is a Bad Idea.

If you really can justify a mix of public and private data in one type,
make it a struct of public members and a pointer to an incomplete
struct containing the private ones. There, that wasn't so hard, was
it?

Or even allow for macros to access bits of the struct

Premature optimization, generally.

Not all optimization is premature, and the point in time at which the
optimization takes place does not change the possible techniques
involved.

In a typical C library, there are plenty of macros that access members
of FILE.

 

[Michael Wojcik]

[re starting identifiers with an underscore]
It can be useful on struct members as a "suggestion" to users of an API
that the member is "private".

Surely a more effective suggestion is to have the API pass pointers
to an incomplete struct type, and not let the users see its contents
at all.

Not if you also want public members.
Or even allow for macros to access bits of the struct

Premature optimization, generally.

Not all optimization is premature,

Gee, if only I had qualified my "premature optimization" claim...
oh, I did.

and the point in time at which the
optimization takes place does not change the possible techniques
involved.

Fine. Make that "pointless optimization, generally".

In a typical C library, there are plenty of macros that access members
of FILE.

Yes, and so what? No doubt that's a tremendous boon to the tiny
proportion of programs which use stdio macros to perform actions on
FILE objects within a time-critical section of code, for some
unguessable reason, and which are mysteriously not I/O-bound as a
result.

For all other programs, making those macros function calls and
keeping FILE opaque would be fine; indeed, it would be better, since
it would discourage the foolish from poking about in stdio.h and
manipulating the contents of FILE structures directly.

So, as I said: *generally* not a useful optimization.

--
Michael Wojcik (e-mail address removed)

The lecturer was detailing a proof on the blackboard. He started to say,
"From the above it is obvious that ...". Then he stepped back and thought
deeply for a while. Then he left the room. We waited. Five minutes
later he returned smiling and said, "Yes, it is obvious", and continued
to outline the proof. -- John O'Gorman