Too much encapsulation?

[copx]

I have recently read "Everything you ever wanted to know about C types" by
Peter Seebach (1), and learned about incomplete types. Now, I realise the
value of encapsulation, but I wonder whether it is proper C style to use
that much of it. By using incomplete types you end up with something like
this:

object_set_colo ur(object, RED);
colour = object_get_colo ur(object);

instead of:

object->colour = RED;
colour = object->colour;

If the type of "object" is incomplete, you could not write object->colour or
something like that, because accessing data of incomplete type is not
possible. Only the file which contains the get/set rountines defines the
type. You end up with something that looks very much like OOP + a terrible
overhead. Keep in mind that you need to keep the get/set functions + the
actual type definition in a seperate file to get the encapsulation effect.
That means that no mainstream C compiler will be able to optimize those
function calls away (AFAIK neither GNU, nor MS, nor Borland can inline
functions from other files).

So do you consider that proper C style?
Personally, I am not sure what to think of this. It seems to scream "Why do
you not use C++ already?!".

Link:
http://www-128.ibm.com/developerwork...&Search=Search

[user923005]

On Jun 14, 3:28 pm, "copx" <[e-mail] wrote:

I have recently read "Everything you ever wanted to know about C types" by
Peter Seebach (1), and learned about incomplete types. Now, I realise the
value of encapsulation, but I wonder whether it is proper C style to use
that much of it. By using incomplete types you end up with something like
this:

object_set_colo ur(object, RED);
colour = object_get_colo ur(object);

instead of:

object->colour = RED;
colour = object->colour;

If the type of "object" is incomplete, you could not write object->colour or
something like that, because accessing data of incomplete type is not
possible. Only the file which contains the get/set rountines defines the
type. You end up with something that looks very much like OOP + a terrible
overhead. Keep in mind that you need to keep the get/set functions + the
actual type definition in a seperate file to get the encapsulation effect.
That means that no mainstream C compiler will be able to optimize those
function calls away (AFAIK neither GNU, nor MS, nor Borland can inline
functions from other files).

MS VC++ can do it.
And if you do the cheesy, sleezy include trick all of them can do it:

/* main.c starts here... */
#include "file1.c"
#include "file2.c"
#include "file3.c"
#include "file4.c"
#include "file5.c"
int main(void)
{
return some_important_ function();
}
/* main.c ends here... */

So do you consider that proper C style?
Personally, I am not sure what to think of this. It seems to scream "Why do
you not use C++ already?!".

Link:http://www-128.ibm.com/developerwork...lts.jsp?search...

If I want C++, then I code in C++.

If I want to write a Unix style filter, I will use C.

On the other hand, I have no problem reading or even enjoying C code
written in a C++ style.

On the other, other hand, I have seen programs where everything is
typedef-ed into some abstract type (even things like loop indexes) and
find those programs to be a lot less transparent to understand than
one more simply written.

IMO-YMMV.

[Ben Bacarisse]

"copx" <co**@gazeta.pl writes:

I have recently read "Everything you ever wanted to know about C types" by
Peter Seebach (1), and learned about incomplete types. Now, I realise the
value of encapsulation, but I wonder whether it is proper C style to use
that much of it. By using incomplete types you end up with something like
this:

object_set_colo ur(object, RED);
colour = object_get_colo ur(object);

If you end up with this you don't really *have* any encapsulation.
All you've done invent new syntax for:

instead of:

object->colour = RED;
colour = object->colour;

as you have spotted.

Incomplete types are at their most useful when the interface you have
to define is small compared to the complexity (or probable
variability) of the implementation that is hidden behind it.

--
Ben.

[Ian Collins]

copx wrote:

I have recently read "Everything you ever wanted to know about C types" by
Peter Seebach (1), and learned about incomplete types. Now, I realise the
value of encapsulation, but I wonder whether it is proper C style to use
that much of it. By using incomplete types you end up with something like
this:

object_set_colo ur(object, RED);
colour = object_get_colo ur(object);

instead of:

object->colour = RED;
colour = object->colour;

If the type of "object" is incomplete, you could not write object->colour or
something like that, because accessing data of incomplete type is not
possible. Only the file which contains the get/set rountines defines the
type. You end up with something that looks very much like OOP + a terrible
overhead. Keep in mind that you need to keep the get/set functions + the
actual type definition in a seperate file to get the encapsulation effect.
That means that no mainstream C compiler will be able to optimize those
function calls away (AFAIK neither GNU, nor MS, nor Borland can inline
functions from other files).

So do you consider that proper C style?

Yes, and it's a very common idiom (have you ever manipulated a FILE
object?). Sometimes you want to use encapsulation to present a
consistent interface over a number of platforms. Other times you may
wish to provide a stable interface to an object that is liable to change
between releases of you application.

Personally, I am not sure what to think of this. It seems to scream "Why do
you not use C++ already?!".

Nothing to do with C++, unless you are using a similar idiom with opaque
types, C++ classes lay their innards bare for all to see.

--
Ian Collins.

[Eric Sosman]

copx wrote:

I have recently read "Everything you ever wanted to know about C types" by
Peter Seebach (1), and learned about incomplete types. Now, I realise the
value of encapsulation, but I wonder whether it is proper C style to use
that much of it. By using incomplete types you end up with something like
this:

object_set_colo ur(object, RED);
colour = object_get_colo ur(object);

instead of:

object->colour = RED;
colour = object->colour;

If the type of "object" is incomplete, you could not write object->colour or
something like that, because accessing data of incomplete type is not
possible. Only the file which contains the get/set rountines defines the
type. You end up with something that looks very much like OOP + a terrible
overhead. Keep in mind that you need to keep the get/set functions + the
actual type definition in a seperate file to get the encapsulation effect.
That means that no mainstream C compiler will be able to optimize those
function calls away (AFAIK neither GNU, nor MS, nor Borland can inline
functions from other files).

So do you consider that proper C style?

"Proper" is a judgmental term I won't try to address.
As for the pattern, yes: It's a perfectly good and useful
way to use C. Let's modify your example a little bit:

colour_set_rgb( &hue, RED, 1.0); /* RED to 100% */
cyan = colour_get_cmy( &hue, CYAN); /* get CYAN value */

That is, suppose there is a colour object that supports several
different perceptual color models: RGB, CMY, CMYK, CIE, ... You
can set the components of any model, and read back the components
of any other model: the object takes care of the transformations .
You can even do mixed-mode operations:

colour_set_rgb( &hue, RED, 1.0); /* red to the max */
colour_set_hsv( &hue, VAL, 0.2); /* ... but make it dim */
black = colour_get_cmyk (&hue, BLACK); /* how much black? */

Now: How are you going to accomplish this with the struct->element
approach? By using mutators and accessors, you give yourself an
opportunity to do some processing at interesting moments, to
defend against bogus settings (colour_set_rgb (&hue, RED, -42e9)),
and in general to change the internal representation of the object.

This freedom isn't always important, and it's silly to be a
slave to encapsulation orthodoxy for no purpose. But it can also
be a potent tool, capable of simplifying designs and easing
debugging. The trick is to know when to indulge and when to
abstain.

Personally, I am not sure what to think of this. It seems to scream "Why do
you not use C++ already?!".

Because you'll go straight to Hell, of course. Where your
body, like your name, will be mangled.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Stephen Sprunk]

"copx" <co**@gazeta.pl wrote in message
news:f4******** **@inews.gazeta .pl...

>I have recently read "Everything you ever wanted to know about C types" by
Peter Seebach (1), and learned about incomplete types. Now, I realise the
value of encapsulation, but I wonder whether it is proper C style to use
that much of it. By using incomplete types you end up with something like
this:

object_set_colo ur(object, RED);
colour = object_get_colo ur(object);

instead of:

object->colour = RED;
colour = object->colour;

If the type of "object" is incomplete, you could not write object->colour
or something like that, because accessing data of incomplete type is not
possible. Only the file which contains the get/set rountines defines the
type.

That's one way to do it, in particular if you're writing a library to be
used by others and there's a substantial risk that versions will get out of
sync (for instance, you change your library code but they don't recompile
their application).

The other way to do it is to define function-like macros or static inline
functions in the header file that the application includes, which allows the
compiler to optimize away the encapsulation. This is safe as long as you
trust coders using your interface not to peek at the implementation and both
sets of code will always be recompiled if you change the internals.

You end up with something that looks very much like OOP + a terrible
overhead.

There is no guarantee it will perform worse if you do end up with a
function-call interface. Sure, it's likely, but (a) compilers continually
get better at optimizing, (b) CPUs get better every year at executing bad
code, and (c) you shouldn't worry about optimization until your program is
correct and you can prove there's a performance problem that merits writing
less-maintainable code.

Keep in mind that you need to keep the get/set functions + the actual type
definition in a seperate file to get the encapsulation effect.

That means that no mainstream C compiler will be able to optimize those
function calls away

That doesn't mean they need to be in a separate .c file; see above.

(AFAIK neither GNU, nor MS, nor Borland can inline functions from other
files).

There do exist compilers that can optimize, including inlining, across
translation units. I don't know the status of the ones you list; ask Google
about "Whole-Program Optimization". My understanding is that's fairly rare
today; at best you get inter-procedural optimizations within a single
translation unit with most compilers. That argues for (today) sticking with
the latter encapsulation strategy I describe above, rather than the one
you're assuming, if you can show the latter causes performance problems.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
--
Posted via a free Usenet account from http://www.teranews.com

[Roland Pibinger]

On Fri, 15 Jun 2007 13:06:01 +1200, Ian Collins wrote:

>copx wrote:

>If the type of "object" is incomplete, you could not write object->colour or
something like that, because accessing data of incomplete type is not
possible.

[...]

>So do you consider that proper C style?

Yes, and it's a very common idiom (have you ever manipulated a FILE
object?).

Unfortunately you frequently see generous 'un-encapsulation' in C
code. Structs are defined completely in the header file but only
pointers to functions are used in the function declarations (other
'private' elements (defines, macros, enums) are also unnecessarily
placed into the header). Many programmers seem to be unaware of gratis
encapsulation.

>Personally, I am not sure what to think of this. It seems to scream "Why do
you not use C++ already?!".

Nothing to do with C++, unless you are using a similar idiom with opaque
types, C++ classes lay their innards bare for all to see.

but not for all to access. Encapsulation is independent of language
and paradigm (it's not an original OO feature).

--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

[copx]

"Eric Sosman" <es*****@acm-dot-org.invalidschr ieb im Newsbeitrag
news:w6******** *************** *******@comcast .com...
[snipping example of sensible use]

This freedom isn't always important, and it's silly to be a
slave to encapsulation orthodoxy for no purpose. But it can also
be a potent tool, capable of simplifying designs and easing
debugging. The trick is to know when to indulge and when to
abstain.

Yes, I think that is probably the way to go.

[snip]

[Al Balmer]

On Fri, 15 Jun 2007 01:50:34 +0100, Ben Bacarisse
<be********@bsb .me.ukwrote:

>"copx" <co**@gazeta.pl writes:

>I have recently read "Everything you ever wanted to know about C types" by
Peter Seebach (1), and learned about incomplete types. Now, I realise the
value of encapsulation, but I wonder whether it is proper C style to use
that much of it. By using incomplete types you end up with something like
this:

object_set_col our(object, RED);
colour = object_get_colo ur(object);

If you end up with this you don't really *have* any encapsulation.
All you've done invent new syntax for:

>instead of:

object->colour = RED;
colour = object->colour;

as you have spotted.

Not quite. With the first variation, you don't need access to the
components of object, or even to know their names or other properties.

>
Incomplete types are at their most useful when the interface you have
to define is small compared to the complexity (or probable
variability) of the implementation that is hidden behind it.

--
Al Balmer
Sun City, AZ

[Ben Bacarisse]

Al Balmer <al******@att.n etwrites:

On Fri, 15 Jun 2007 01:50:34 +0100, Ben Bacarisse
<be********@bsb .me.ukwrote:

>>"copx" <co**@gazeta.pl writes:

>>I have recently read "Everything you ever wanted to know about C types" by
Peter Seebach (1), and learned about incomplete types. Now, I realise the
value of encapsulation, but I wonder whether it is proper C style to use
that much of it. By using incomplete types you end up with something like
this:

object_set_co lour(object, RED);
colour = object_get_colo ur(object);

If you end up with this you don't really *have* any encapsulation.
All you've done invent new syntax for:

>>instead of:

object->colour = RED;
colour = object->colour;

as you have spotted.

Not quite. With the first variation, you don't need access to the
components of object, or even to know their names or other
properties.

Good point. And you also have a place to put checks and debug tests,
which can be quite handy. But you are still not getting the most from
the *idea* of encapsulation if this is what most of the interface
looks like.

--
Ben.