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]

"Serve La" <[e-mail]> 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(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]

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_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]

Serve La <[e-mail]> 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(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]

"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 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]

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

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

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]

"Serve La" <[e-mail]> 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(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?

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

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.com> wrote in message
news:79**************************@posting.google.c om...

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

[Malcolm]

"Serve La" <[e-mail]> wrote in message

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

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]

Serve La wrote:

E. Robert Tisdale wrote:

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.

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]

On Fri, 12 Sep 2003 22:40:33 +0200, "Serve La" <[e-mail]>
wrote in comp.lang.c:

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]

Jack Klein 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;

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]

Jack Klein wrote:

On Fri, 12 Sep 2003 22:40:33 +0200, "Serve La" <[e-mail]>
wrote in comp.lang.c:

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.

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.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Serve La]

"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote in message
news:bk**********@newsg4.svr.pol.co.uk...

"Serve La" <[e-mail]> wrote in message

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

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.

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]

"Jack Klein" <ja*******@spamcop.net> wrote in message
news:im********************************@4ax.com...

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.

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]

On Fri, 12 Sep 2003 20:40:33 UTC, "Serve La" <[e-mail]>
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:

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.

--
Tschau/Bye
Herbert

eComStation 1.1 Deutsch Beta ist verügbar

[Serve La]

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

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]

On Sun, 14 Sep 2003, Serve La wrote:

"Jack Klein" <ja*******@spamcop.net> wrote...

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.

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

[E. Robert Tisdale]

Serve La wrote:

E. Robert Tisdale wrote:

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?

You mean like the ncl_dchandle member in the ncl_dcsubmatrix object?

Please take the time to download and study the CNCL.
I will be happy to answer any questions that you may have about it.

[E. Robert Tisdale]

Malcolm wrote:

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.

No.

C++ classes allow you to "hide" the actual data representation
by labeling the data members private:
You would need to use "opaque" types in C
to hide data members effectively.
Unfortunately, opaque data types preclude the use of
inline functions or even C preprocessor macros
to access private data members efficiently.

[E. Robert Tisdale]

The Real OS/2 Guy wrote:

With C there is more help to encapsulate things.
Think OO, but write procedural.

1. a header file that holds the external interfaces.
- an [opaque] type name
- function [declarations]
2.. a translation unit that holds the data descriptions
and the functions [definitions] used to get anything done.

The problem with opaque types is that the methods cannot be
implemented as inline functions of C preprocessor macros.
This virtually precludes the use of opaque types
in many high performance applications.

[Dave Thompson]

On 13 Sep 2003 06:54:42 -0700, qe*@pobox.com (Paul Hsieh) wrote:

"Serve La" <[e-mail]> wrote: <snip>

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

This isn't quite true. In C++ a (struct, class, union, or enum) tag
can be used alone as a type name, *if* the same name is not declared
in the same (or inner) scope as an ordinary identifier; in the latter
case, you must use an elaborated-type-specifier, that is the keyword
struct, class, union or enum plus the tag, just as you always do in C.

And to be clear this is only on references; the keyword is always
required on the declaration of the struct etc. itself.

<snip> 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.
Are you relying on a convention that the ctor is declared first, and
uses the struct tag in its return type, to avoid problems with the tag
being "confined" to prototype scope? I think I would put in a "struct
ccHashTab /*opaque*/ ;" to be more robust, and IMVHO clearer.
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.

I don't follow this. You mean you are returning a pointer *value*
stored, by a previous insert_, in the table? That should work fine
for a const tabtype * table, even if the contained and returned
pointer is not to const. (Even in C++, which allows adding const
"further away" than C does, but not the reverse of restricting
removing them.) Can you be more specific about the problem?

- David.Thompson1 at worldnet.att.net