«

Richard Heathfield <> writes:
> mattia said:
>> Hi everybody, I'm wondering how to realize a simple pattern in C:
>> information hiding, to hide detail implementations of a data structure.
>> How can I do that?
>
> John Bode has explained (correctly, as far as I can see) how to create
> opaque types.
>
>> I've also read that is preferred to use only struct
>> and avoid typedef struct.
>
> And I've read that Elvis is still alive.

There's a school of thought that says it's a good idea to declare a
typedef for a struct type, so that you have a one-word name you can
use to refer to it. There's another school of thought that prefers
not to add the typedef, and to use the name "struct foo" directly
whenever referring to the type.

Note that this issue has very little to do with information hiding --
except that if you want a type that's implemented as a struct to be
opaque (i.e., code that uses it shouldn't depend on its being as
struct), typedef'ing it is probably a good idea.

The type FILE in <stdio.h> is a good example.

Note that FILE is typically implemented as a typedef for a struct.
The struct declaration is usually (perhaps always?) *not* hidden.
This isn't a problem in practice, because programmers typically don't
write code that depends on how FILE is implemented.

--
Keith Thompson (The_Other_Keith) <kst->
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Tue, 08 Apr 2008 19:17:45 +0000, Richard Heathfield wrote:
> I'm not sure whether FILE's details are /allowed/ to be hidden - or
> rather, I'm fairly sure they're not. That is, I believe the following
> program to be strictly conforming:
>
> #include <stdio.h>
>
> int main(void)
> {
> printf("%lu\n", (unsigned long)sizeof(FILE)); return 0;
> }
>
> ...which won't compile if FILE is opaque.

<nit>

That is not a strictly conforming program. The number it outputs is
unspecified, and I'm sure you didn't mean to suggest otherwise. It must
be accepted by any conforming hosted implementation, because it's a
_correct_ program, not a strictly conforming one.

Harald van Dijk <> writes:
> On Tue, 08 Apr 2008 19:17:45 +0000, Richard Heathfield wrote:
>> I'm not sure whether FILE's details are /allowed/ to be hidden - or
>> rather, I'm fairly sure they're not. That is, I believe the following
>> program to be strictly conforming:
>>
>> #include <stdio.h>
>>
>> int main(void)
>> {
>> printf("%lu\n", (unsigned long)sizeof(FILE)); return 0;
>> }
>>
>> ...which won't compile if FILE is opaque.
>
> <nit>
>
> That is not a strictly conforming program. The number it outputs is
> unspecified, and I'm sure you didn't mean to suggest otherwise. It must
> be accepted by any conforming hosted implementation, because it's a
> _correct_ program, not a strictly conforming one.

But this is strictly conforming:

#include <stdio.h>

int main(void)
{

printf("%d\n", sizeof(FILE) > 0); return 0;
}

and must print 1.

My point about FILE is that it's a good example of something that's
*used* as an opaque type. A non-portable program theoretically could,
assuming that FILE is a typedef for a structure, mess around with the
members of that structure:

#include <stdio.h>
int main(void)
{
/* NON-PORTABLE: */
printf("stdin->_file = %d\n", stdin->_file);
printf("stdout->_file = %d\n", stdout->_file);
printf("stderr->_file = %d\n", stderr->_file);
return 0;
}

but I've seen remarkably few actual examples of that kind of thing.

--
Keith Thompson (The_Other_Keith) <kst->
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

In article <>,
Keith Thompson <kst-> wrote:
>A non-portable program theoretically could,
>assuming that FILE is a typedef for a structure, mess around with the
>members of that structure:

> /* NON-PORTABLE: */
> printf("stdin->_file = %d\n", stdin->_file);

>but I've seen remarkably few actual examples of that kind of thing.

I have seen several unix programs directly access the file descriptor
field of a FILE structure and do something with that field
(e.g., dup() or read()). It always counter-productive to me,
considering the perfectly good fileno() function that POSIX provides
and which Unices provided long before POSIX was standardized.
Why go through the trouble of using a non-portable field name when
a portable function to get at the value is handy?? Misplaced
notions about the efficiency improvements of not having a function
call??
--
"The whole history of civilization is strewn with creeds and
institutions which were invaluable at first, and deadly
afterwards." -- Walter Bagehot

In article <>,
Keith Thompson <kst-> wrote:

>But this is strictly conforming:

> printf("%d\n", sizeof(FILE) > 0); return 0;

On the other hand, the very fact that it must print 1 shows that it
can be compiled without knowledge of the contents of FILE. Though
presumably it would be non-conforming to make sizeof(struct foo) > 1
work in general when struct foo was an incomplete type, even though
it must be true.

> printf("stdin->_file = %d\n", stdin->_file);
....
>but I've seen remarkably few actual examples of that kind of thing.

Years ago I used something similar to test whether there was any buffered
data waiting, to implement a stdio-level version of select().

One reason you don't see it often is that your particular useful
example is encapsulated as fileno() on Posix systems.

-- Richard
--
:wq