Andy Armstrong wrote:
>
> GOMEZ Henri wrote:
> >
> > >The reason would be to keep the implementation details of the structure
> > >private so that people aren't tempted to access the fields
> > >directly. All
> > >the caller gets is an opaque handle. Think of it as 'objects lite' for
> > >C.
> >
> > I could understand the OO construction if we were using C++
> > but in strict K&R when you need to have access elements in
> > a struct you need to know about them ?)
> >
> > The goal is to have functions defs in .c and data defs in .h
> > preparing scandoc task
> >
> > So what about that repartition ?
>
> No, I think it's right as it stands. Just because we're working in C
> doesn't mean we can't do encapsulation. This is a perfectly valid idiom
> to express the concept of some.c and some.h working together to
> implement a 'class' which is only accessed through a functional
> interface. The encapsulation benefits are the same as for Java or C++.
> For one thing it means that the implementation in some.c can change
> without impacting client code.
>
> I haven't looked at any of the specific cases you're talking about, but
> in general I would say that this is good programming style.
An example (partial only, toto should be allocated in stinternal.c):
st.c:
+++
struct jk_map;
typedef struct jk_map jk_map_t;
main()
{
jk_map_t *toto;
printtoto(toto);
}
+++
stinternal.c:
+++
struct jk_map;
typedef struct jk_map jk_map_t;
#define SMALL_POOL_SIZE 32
struct jk_map {
int p;
char buf[SMALL_POOL_SIZE];
char **names;
void **values;
unsigned capacity;
unsigned size;
};
printtoto(jk_map_t *toto)
{
printf("%d\n",toto->size);
}
+++
The part
+++
struct jk_map;
typedef struct jk_map jk_map_t;
+++
Could be in an include st.h. used both by st.c and stinternal.c, but the jk_map
structure elements are only accessible in stinternal.c
An other point is that I prefer homogeneous code and I plan to use the following
for APR:
#ifdef HAS_APR
typedef apr_socket jk_socket;
#else
typedef int jk_socket;
#endif
>
> --
> Andy Armstrong, Tagish