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(unsi gned int size, hash h, comp c);
void ccFreeHashTab(c cHashTab *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]

"Serve La" <ik@veranderhet al.com> wrote in message
news:bj******** **@news3.tilbu1 .nb.home.nl...

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(unsi gned int size, hash h, comp c);
void ccFreeHashTab(c cHashTab *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(espec ially if you don't access ccHashTab
members directly)

in hashtab.h

typedef struct ccHashTab * ccHashTabRef;

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

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

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

[E. Robert Tisdale]

Serve La wrote:

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_creat e(unsigned int size, hash h, comp c);
void ccHashTab_destr oy(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]

Serve La <ik@veranderhet al.com> wrote:

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(unsi gned int size, hash h, comp c);
void ccFreeHashTab(c cHashTab *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]

"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > wrote in message
news:3F******** ******@jpl.nasa .gov...

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 ccConstructHash Tab 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]

Serve La wrote:

E. Robert Tisdale wrote:

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 ccConstructHash Tab
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_creat e(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]

"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > wrote in message
news:3F******** ******@jpl.nasa .gov...

ccHashTab ccHashTab_creat e(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]

"Serve La" <ik@veranderhet al.com> wrote:

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(unsi gned int size, hash h, comp c);
void ccFreeHashTab(c cHashTab *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?

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[LibraryUser]

"E. Robert Tisdale" wrote:

Serve La wrote:

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_creat e(unsigned int size, hash h, comp c);
void ccHashTab_destr oy(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.

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>

--
Replies should be to the newsgroup
Chuck Falconer, on vacation.

[Serve La]

"Paul Hsieh" <qe*@pobox.co m> wrote in message
news:79******** *************** ***@posting.goo gle.com...

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?

Huh?
Because OO is not bound to C++