style question

[Serve La]

When I write a medium to large sized C application I tend to create
structures first, then makeStruct and freeStruct functions that dynamically
allocate/free the struct and then I create a bunch of functions that operate
on the struct. Example:

typedef struct ccHashTab
{
.....
} ccHashTab;

ccHashTab * ccMakeHash(unsigned int size, hash h, comp c);
void ccFreeHashTab(ccHashTab *table);
void *ccHashFindSym(ccHashTab *table, void *symbol);
......

This is a bit the object-oriented way, because I never touch the struct
members directly, only inside the hash functions.
Now I'm wondering if this is a style that other C programmers use in their
work or if they're using something different. I just want to know some
opinions, maybe I'll get some new insights.

 

[Peter Slootweg]

When I write a medium to large sized C application I tend to create
structures first, then makeStruct and freeStruct functions that dynamically
allocate/free the struct and then I create a bunch of functions that operate
on the struct. Example:

typedef struct ccHashTab
{
....
} ccHashTab;

ccHashTab * ccMakeHash(unsigned int size, hash h, comp c);
void ccFreeHashTab(ccHashTab *table);
void *ccHashFindSym(ccHashTab *table, void *symbol);
.....

This is a bit the object-oriented way, because I never touch the struct
members directly, only inside the hash functions.
Now I'm wondering if this is a style that other C programmers use in their
work or if they're using something different. I just want to know some
opinions, maybe I'll get some new insights.

to hide the details of struct ccHashTab and make it a bit more OO I would do
something like the following(especially if you don't access ccHashTab
members directly)

in hashtab.h

typedef struct ccHashTab * ccHashTabRef;

ccHashTabRef ccMakeHash(unsigned int size, hash h, comp c);
void ccFreeHashTab(ccHashTabRef table);
void *ccHashFindSym(ccHashTabRef table, void *symbol);

in hashtab.c
#include "hashtab.h"
struct ccHashTab
{
....
}

ccHashTabRef ccMakeHash(unsigned int size, hash h, comp c)
{
....
}
void ccFreeHashTab(ccHashTabRef table)
{
....
}
void *ccHashFindSym(ccHashTabRef table, void *symbol)
{
....
}

 

[E. Robert Tisdale]

When I write a medium to large sized C application I tend to create
structures first, then makeStruct and freeStruct functions that dynamically
allocate/free the struct and then I create a bunch of functions that operate
on the struct. Example:


typedef struct ccHashTab {
// ...
} ccHashTab;

ccHashTab ccHashTab_create(unsigned int size, hash h, comp c);
void ccHashTab_destroy(const ccHashTab* pTable);
void* ccHashTab_find(ccHashTab* pTable, void* pSymbol);
.....

This is a bit the object-oriented way
because I never touch the struct members directly,
only inside the hash functions.
Now I'm wondering if this is a style
that other C programmers use in their work
or if they're using something different.
I just want to know some opinions, maybe I'll get some new insights.

Try to avoid functions that return a pointer to memory
allocated from the free store.

 

[Kevin Easton]

When I write a medium to large sized C application I tend to create
structures first, then makeStruct and freeStruct functions that dynamically
allocate/free the struct and then I create a bunch of functions that operate
on the struct. Example:

typedef struct ccHashTab
{
....
} ccHashTab;

ccHashTab * ccMakeHash(unsigned int size, hash h, comp c);
void ccFreeHashTab(ccHashTab *table);
void *ccHashFindSym(ccHashTab *table, void *symbol);
.....

This is a bit the object-oriented way, because I never touch the struct
members directly, only inside the hash functions.
Now I'm wondering if this is a style that other C programmers use in their
work or if they're using something different. I just want to know some
opinions, maybe I'll get some new insights.

Yeah, that's fairly common. If you want to stop the user from accessing
the internals of the structs, you can declare them incompletely in the
header file:

typedef struct ccHashTab ccHashTab;

then fully define the struct in the .c file that implements the hash
table:

struct ccHashTab {
...
}

It's not a good idea to use a typedef to hide the fact that it's a
pointer (which you haven't done anyway, but one of the other replies in
this thread does) - if the user knows it's a pointer they know they can
safely do things like assign it to a void * and back again, and compare
the constructor function return value against NULL to check for errors.

- Kevin.

 

[Serve La]

Try to avoid functions that return a pointer to memory
allocated from the free store.

That is IMO only good for simple structs where all data is known at
compile-time. If a struct gets complicated I don't want to put the burden on
allocating the struct on a client programmer. Chances are she forgets a NULL
check somewhere or does it wrong.
What I do now is create an extra function ccConstructHashTab that performs
the role of a constructor. This function doesn't care if the pointer is
pointing to dynamic memory or not.
But most of my structs are too complicated for static storage

 

[E. Robert Tisdale]

That is, IMO, only good for simple structs
where all data is known at compile-time.
If a struct gets complicated,
I don't want to put the burden on allocating the struct
on a client programmer.
Chances are she forgets a NULL check somewhere or does it wrong.
What I do now is create an extra function ccConstructHashTab
that performs the role of a constructor. This function doesn't care
if the pointer is pointing to dynamic memory or not.
But most of my structs are too complicated for static storage.

You are confused. A pseudo constructor like

ccHashTab ccHashTab_create(unsigned int size, hash h, comp c);

places *no* "burden" on the application program.
It works well no matter how complicated the data structure.

People have been doing this sort of thing for a very long time.
Take a look, for example, at The ANSI C Numerical Class Library

http://www.netwood.net/~edwin/svmtl/

It allows you to construct vector and matrix objects from either
automatic or free storage. You might also look at
The GNU Scientific Library (GSL)

http://sources.redhat.com/gsl/

 

[Serve La]

ccHashTab ccHashTab_create(unsigned int size, hash h, comp c);

places *no* "burden" on the application program.
It works well no matter how complicated the data structure.

People have been doing this sort of thing for a very long time.
Take a look, for example, at The ANSI C Numerical Class Library

http://www.netwood.net/~edwin/svmtl/

It allows you to construct vector and matrix objects from either
automatic or free storage. You might also look at
The GNU Scientific Library (GSL)

http://sources.redhat.com/gsl/

I can't unzip those, could you give an example?

Here's a fairly complicated struct that I now allocate in a function:

typedef struct Inner
{
ITypeInfo *info;
TYPEATTR *attr;
BSTR name;
int index;
} Inner;

typedef struct SomeStruct
{
GUID libid;
ITypeLib *lib;
Inner *info;
UINT ntypeinfo;
BSTR filename;
BSTR helpstring;
BSTR helpfilename;
UINT currentiter;
} SomeStruct;

 

[Paul Hsieh]

When I write a medium to large sized C application I tend to create
structures first, then makeStruct and freeStruct functions that dynamically
allocate/free the struct and then I create a bunch of functions that operate
on the struct. Example:

typedef struct ccHashTab
{
....
} ccHashTab;

This typedef is unnecessary and doesn't really do anything useful,
except confuse C++ people (in C++ struct ___ doesn't create a new name
space, the "struct" can be dropped.)

ccHashTab * ccMakeHash(unsigned int size, hash h, comp c);
void ccFreeHashTab(ccHashTab *table);
void *ccHashFindSym(ccHashTab *table, void *symbol);
.....

I do it this way:

/* constructor/destructor */
struct ccHashTab * newCcHash (unsigned int size, int (* keyFn)(void
*));
int destroyCcHash (struct ccHashTab *table);

int clearCcHash (struct ccHashTab *table);
int iterateCcHash (struct ccHashTab *table,
int (* cb) (void * ctx, void * entry), void * ctx);
int insertCcHash (struct ccHashTab *table, void * entry);
int deleteCcHash (struct ccHashTab *table, void * entry);
void * findCcHash (struct ccHashTab *table, void * entry);
/* and other "methods" */

is put in hash.h, and the struct ccHashTab definition is only in the
hash module. Knowing that its a pointer to a struct doesn't really
ruin its opaqueness, if you don't know the structure contents.
However, it makes it clear that you cannot copy it without a copy
method.

One of the things that's always bothered me is that I cannot put
"const" on the table declaration in the findCcHash function. The
reason is that you are returning a pointer that table is pointing to,
and thus the compiler cannot figure out whether or not you might
modify its contents.

This is a bit the object-oriented way, because I never touch the struct
members directly, only inside the hash functions.

Of course the burning question, then is, why not use C++ instead of C
then?

 

[LibraryUser]

Try to avoid functions that return a pointer to memory
allocated from the free store.

This is nonsense advice, especially in this context.

To the OP: You need to evaluate the advice given in c.l.c,
dependant on the advisor. In general advice from ERT is likely to
be valueless, off-topic, and wrong.

Your general approach is worthwhile. It is also advisable to
find ways to hide the actual construction of these entities, so
that you are free to alter the implementation without affecting
the usage. For an example in my style see:

<http://cbfalconer.home.att.net/download/hashlib.zip>

 

[Serve La]

Of course the burning question, then is, why not use C++ instead of C
then?

Huh?
Because OO is not bound to C++

 

[Malcolm]

C then?

Huh?
Because OO is not bound to C++

C++ classes are only really useful when you have inheritance relationships
between them. If you are not going to base your design on a class hierarchy,
a C implementation will generally be cleaner and easier to understand and
maintain.

 

[E. Robert Tisdale]

I can't unzip those.

They are compressed UNIX tape archives.
You can probably use Stuffit

http://www.stuffit.com/win/expander/index.html

to uncompress and extract the directory.

Could you give an example?

Here's a fairly complicated struct that I now allocate in a function:

typedef struct Inner {
ITypeInfo *info;
TYPEATTR *attr;
BSTR name;
int index;
} Inner;

typedef struct SomeStruct {
GUID libid;
ITypeLib *lib;
Inner *info;
UINT ntypeinfo;
BSTR filename;
BSTR helpstring;
BSTR helpfilename;
UINT currentiter;
} SomeStruct;

#ifdef NCL_REVEAL
/* Reveal type definitions after applications are thoroughly tested. */

typedef struct { /* submatrix class definition */
/* private: */
ncl_dchandle H;
ncl_offset O;
ncl_extent N1;
ncl_stride S1;
ncl_extent N2;
ncl_stride S2;
ncl_______ _;
} ncl_dcsubmatrix;
/* A submatrix does not own the array storage that it references. */
/* It does not allocate any array storage when it is constructed */
/* nor does it deallocate any array storage when it is destroyed. */

#else /* NCL_REVEAL */
/* Conceal type definitions until applications are thoroughly tested. */

#define NCL_DCSUBMATRIX_SIZE NCL_SUBMATRIX_SIZE
typedef int ncl_dchidden_submatrix[NCL_DCSUBMATRIX_SIZE/sizeof(int)];

typedef struct { /* submatrix class definition */
/* private: */
ncl_dchidden_submatrix M;
} ncl_dcsubmatrix;
/* A submatrix does not own the array storage that it references. */
/* It does not allocate any array storage when it is constructed */
/* nor does it deallocate any array storage when it is destroyed. */

#endif /* NCL_REVEAL */

inline static
ncl_dcsubmatrix /* automatic storage constructor */
(ncl_dcsubm_create)(
ncl_dchandle h, ncl_offset o,
ncl_extent m, ncl_stride s2,
ncl_extent n, ncl_stride s1) {
ncl_dcsubmatrix M;
ncl_dcsubm_init(&M, h, o, m, s2, n, s1);
return M; }

inline static
void /* automatic storage destructor */
(ncl_dcsubm_destroy)(ncl_dcsubmatrix* pM) {
pM->_ = ~ncl_other; }

inline static
ncl_dcsubmatrix* /* free storage constructor */
(ncl_dcsubm_new)(
ncl_dchandle h, ncl_offset o,
ncl_extent m, ncl_stride s2,
ncl_extent n, ncl_stride s1) {
ncl_dcsubmatrix* pM
= (ncl_dcsubmatrix*)malloc(sizeof(ncl_dcsubmatrix));
if (pM)
ncl_dcsubm_init(pM, h, o, m, s2, n, s1);
return pM; }

inline static
void /* free storage destructor */
(ncl_dcsubm_delete)(ncl_dcsubmatrix* pM) {
ncl_dcsubm_destroy(pM);
free((void*)pM); }

 

[Jack Klein]

When I write a medium to large sized C application I tend to create
structures first, then makeStruct and freeStruct functions that dynamically
allocate/free the struct and then I create a bunch of functions that operate
on the struct. Example:

typedef struct ccHashTab
{
....
} ccHashTab;

One style comment. I personally don't like the practice of using a
struct tag and a typedef for the same structure. One or the other,
please, but not both.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

 

[E. Robert Tisdale]

One style comment.
I personally don't like the practice
of using a struct tag and a typedef for the same structure.
One or the other, please, but not both.

Can you give us a clue why you don't like it?

 

[Richard Heathfield]

One style comment. I personally don't like the practice of using a
struct tag and a typedef for the same structure. One or the other,
please, but not both.

Hmmm, disagreeing with Jack Klein for a second consecutive article. This is
getting worrying.

Jack -- as you say, it's a style point. I use structure tags for all structs
nowadays, partly in the usual cluon economy drive, so that I don't have to
remember when I need a tag and when I don't, but also to reduce by a tiny
amount the maintenance work involved in making a struct self-referential,
at the expense of a slightly larger amount of work up front!

On the other hand, I like typedefs. Again, I use them for all structs
nowadays. I like the idea of being able to abstract away the structness of
a struct. I am of the opinion that it makes my programs more pleasant to
read, for many people at least, and perhaps even for most people.

 

[Serve La]

C then?
C++ classes are only really useful when you have inheritance relationships
between them. If you are not going to base your design on a class hierarchy,
a C implementation will generally be cleaner and easier to understand and
maintain.

I agree with that and I'll even add inheriting to the list. Only if you want
to override functions then C is not easy to use anymore. Handling virtual
function tables yourself is not easy and maintainable anymore.

 

[Serve La]

One style comment. I personally don't like the practice of using a
struct tag and a typedef for the same structure. One or the other,
please, but not both.

I was expecting that somebody would say that
But I have chosen this style because I don't see any problems with it only
advantages.

Why was C designed this way? That you have to declare a struct as a struct,
enum as an enum.....

 

[The Real OS/2 Guy]

When I write a medium to large sized C application I tend to create
structures first, then makeStruct and freeStruct functions that dynamically
allocate/free the struct and then I create a bunch of functions that operate
on the struct. Example:

That's the way I work since the first days of programming I've ever
done (and that was long before C were existent.
With C there is more help to encapsulate things. Think OO, but write
procedual.

1. a header file that holds the external interfaces.
- an abstract type name
- function prototypes
2.. a translation unit that holds the data descriptions and the
functions used to get anything done.

 

[Serve La]

typedef struct { /* submatrix class definition */
/* private: */
ncl_dchandle H;
ncl_offset O;
ncl_extent N1;
ncl_stride S1;
ncl_extent N2;
ncl_stride S2;
ncl_______ _;
} ncl_dcsubmatrix;

Ah, ok, but this struct has only valuetypes that can be easily copied. What
you said was "It works well no matter how complicated the data structure"
What if a struct contains pointers or other structs that contain pointers?

 

[Arthur J. O'Dwyer]

I was expecting that somebody would say that
But I have chosen this style because I don't see any problems
with it only advantages.

(Personally, I don't often use typedefs. But in the rare case I do,
I try to give the struct tag and the typedef-name *different*
identifiers; perhaps 'typedef struct Foo_tag { } Foo;', for example.
It's less confusing than having the same identifier mean different
things in different namespaces, IMHO.)

Why was C designed this way? That you have to declare a struct
as a struct, enum as an enum.....

I do believe you've just answered your own question.

-Arthur