style question

[E. Robert Tisdale]

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]

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]

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]

"Serve La" <[email protected]> wrote:

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.

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