Information hiding

[mattia]

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? I've also read that is preferred to use only struct
and avoid typedef struct. Can anyone help? Use as example:
struct list {
int my_data;
struct list *next;
}
Thanks,
Mattia

[John Bode]

On Apr 8, 8:35 am, mattia <[e-mail]:

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? I've also read that is preferred to use only struct
and avoid typedef struct. Can anyone help? Use as example:
struct list {
int my_data;
struct list *next;}

Thanks,
Mattia

In your header file, you include an incomplete definition of an ADT
and declare the functions that will create and modify objects of that
type:

/** list.h */

#ifndef LIST_H
#define LIST_H

struct list;
typedef struct list list;

extern list *newList(void);
extern void deleteList(list **theList);

extern void addValue(list *theList, int value);
extern int getValue(list *theList);
extern void removeValue(list *theList, int value);

extern list *getNext(list *theList);

/* return TRUE if no elements in list */
extern int listEmpty(list *theList);

/* return TRUE if at end of list */
extern int listEnd(list *theList);

#endif

Then your implementation file will complete the definition of list:

/** list.c */

#include <stdlib.h>
#include "list.h"

struct list
{
int my_data;
struct list *next;
}

list *newList(void)
{
list *p = malloc(sizeof *p);
if (p)
{
p->my_data = 0;
p->next = NULL;
}

return p;
}

etc., etc., etc.

You should be able to figure out the rest from here.

[dan]

On 08 Apr 2008 13:35:26 GMT, mattia <ge****@gmail.comwrote:

>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? I've also read that is preferred to use only struct
and avoid typedef struct. Can anyone help? Use as example:
struct list {
int my_data;
struct list *next;
}

Information hiding is the idea that someone has access to your struct,
but does not have access to some of the data contained inside the
struct without going through your interface.

You can accomplish this by writing the functions which implement the
linked list. Like:
list* Initialize(int my_data);
void AddItem(list *l, int my_data);
void PrintList(list l);

The difficulty of doing this in C is that when you give someone a
reference to an instance of your struct, that person now has access to
everything in the struct and there is no guarantee that the person
will use your functions.

One way around this is to use static global variables. A static
global is local to the file which defines it, which means that it is
hidden from everyone else. Of course this will have all of the
typical restrictions you encounter when using global variables.

Another (better) way to implement information hiding is through
misdirection. Write all of your linked list functions but instead of
having the functions take a reference to an instance of the linked
list, have them take an identifier (like an int). And then you
maintain the map which converts the identifier to the proper
reference.

[mattia]

Ok, thanks for the advice, all clear. For the same reason in my header
file I declare extern the functions that I let the user call. Then in my
implementation file I will have to implement the various functions,
without the extern special character, _but_ the static character for my
private functions, isn't it?

[mattia]

#ifndef LIST_H
#define LIST_H

typedef struct _list list;
struct _list {
int my_data;
list *next;
};

Will be the same?

[Richard Heathfield]

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.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

mattia said:

#ifndef LIST_H
#define LIST_H

typedef struct _list list;
struct _list {
int my_data;
list *next;
};

Will be the same?

No, for two reasons. Firstly, you were just shown how to hide the
implementation details, and you have unhidden them again by waving them
around in the header instead of keeping them nicely hidden in the
implementation file. Secondly, you've invaded implementation namespace
with your _list identifier. Avoid leading underscores when naming
identifiers, to avoid clashing with implementations.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:

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.his 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) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Keith Thompson said:

Richard Heathfield <rj*@see.sig.invalidwrites:

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

Right, and...

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.

....right again. The point I was making was not that it is wrong to reject
the typedef, but that it is wrong to claim that rejecting the typedef is
"preferred" in any universal or near-universal sense. That is, it is
reasonable to claim that opinion is divided, but unreasonable to claim
that either one method or the other "is preferred" as if it had some kind
of overwhelming majority mindshare.

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.

Right.

The type FILE in <stdio.his a good example.

Hmmm...

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.

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.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Harald van =?UTF-8?b?RMSzaw==?=]

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.

[Richard Heathfield]

Harald van D?k said:

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.

Braino. Thank you. Anyway, I *think* my point remains. :-)
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[mattia]

On Tue, 08 Apr 2008 11:11:40 -0700, Keith Thompson wrote:

Richard Heathfield <rj*@see.sig.invalidwrites:

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

Ok, thanks, you all were really useful.

[Richard Tobin]

In article <87************@kvetch.smov.org>,
Keith Thompson <ks***@mib.orgwrote:

>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

[CBFalconer]

Walter Roberson wrote:

>

.... snip ...

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

Especially when C may provide the getc and putc as macros,
precisely to avoid this sort of nonsense. However, that provision
is what prevents proper hiding of the FILE structure.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **