Adding the ability to add functions into structures?

[Albert]

So structures are useful to group variables, so you can to refer to a
collection as a single entity. Wouldn't it be useful to also have the
ability to collect variable and functions?

Ask K&R say, C programs consist of variables to store the input and
functions to manipulate them.

This would make C object-oriented - how cool would that be?

Are there any problems with adding the ability to have functions
encapsulated in structures?

 

[Walter Roberson]

So structures are useful to group variables, so you can to refer to a
collection as a single entity. Wouldn't it be useful to also have the
ability to collect variable and functions?

Are there any problems with adding the ability to have functions
encapsulated in structures?

structures are data, functions are code. Having the ability to store
functions (instead of function -pointers-) into structures would
require mechanisms by which data become executable. Some
architectures (e.g., the Harvard architecture) cannot do that.

In architectures that do allow it, you would allow -all- of
your data to be executable (in which case you have all of the
classic stack overflow problems) or else you need a mechanism
to -dynamically- indicate that a particular block of memory is
executable; the existance of such a dynamic method is not at
all certain on any particular system.

 

[Chuck F.]

structures are data, functions are code. Having the ability to
store functions (instead of function -pointers-) into structures
would require mechanisms by which data become executable. Some
architectures (e.g., the Harvard architecture) cannot do that.

In architectures that do allow it, you would allow -all- of your
data to be executable (in which case you have all of the classic
stack overflow problems) or else you need a mechanism to
-dynamically- indicate that a particular block of memory is
executable; the existance of such a dynamic method is not at all
certain on any particular system.

Methinks the OP wants lisp.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

 

[Jack Klein]

So structures are useful to group variables, so you can to refer to a
collection as a single entity. Wouldn't it be useful to also have the
ability to collect variable and functions?

Ask K&R say, C programs consist of variables to store the input and
functions to manipulate them.

This would make C object-oriented - how cool would that be?

Are there any problems with adding the ability to have functions
encapsulated in structures?

It's already been done. They discuss it in comp.lang.c++, down the
hall. And in comp.lang.java, and I'm sure also in whatever group it
is on Microsoft's server that is devoted to C#.

I know I'll get flamed for this, but with the exception of inheritance
this is really nothing but syntactical sugar. You can write object
oriented programs in C right now.

A perfect example is the FILE data type, declared an <stdio.h>. It
has a creator, fopen(), a destructor, fclose(), and all sorts of
methods you can invoke on it via its pointer, such as fprintf(),
fscanf(), fread(), fwrite(), between its successful creation and its
destruction.

 

[Artie Gold]

Methinks the OP wants lisp.

Methinks too much credit you offer to the OP.

--ag

 

[Richard Heathfield]

Jack Klein said:

I know I'll get flamed for this,

FLAME ON!!!

but with the exception of inheritance
this is really nothing but syntactical sugar. You can write object
oriented programs in C right now.

Oh. Was that it? Sheesh. Flame off again. (sigh)

A perfect example is the FILE data type, declared an <stdio.h>. It
has a creator, fopen(), a destructor, fclose(), and all sorts of
methods you can invoke on it via its pointer, such as fprintf(),
fscanf(), fread(), fwrite(), between its successful creation and its
destruction.

This is pretty much how I do it, yes. Just a minor nit - FILE isn't (quite)
a perfect example, in at least two ways:

1) FILE should, in my opinion, be a truly opaque type, with the structure
definition hidden internally. typedef struct _iobuf FILE; is already more
than we need to know. The whole schmeer is far, far more than we need to
know.

2) I wish I wish I wish that fclose took FILE ** rather than FILE *, don't
you?

 

[Chuck F.]

.... snip ...

I know I'll get flamed for this, but with the exception of
inheritance this is really nothing but syntactical sugar. You
can write object oriented programs in C right now.

A perfect example is the FILE data type, declared an <stdio.h>.
It has a creator, fopen(), a destructor, fclose(), and all sorts
of methods you can invoke on it via its pointer, such as
fprintf(), fscanf(), fread(), fwrite(), between its successful
creation and its destruction.

I see no reason for any fires. The only problem with your example
is that you can't write (in general) that type in C. As a further
example I suggest my hashlib, which is written in standard C, is
also very much object oriented, offers constructors, destructors,
and methods.

It offers the opaque incomplete object "hshtbl", whose details are
completely hidden. This is unlike FILE*, which has to be
incompletely hidden because of some standards constraints. Of
course hashlib has the advantage of being designed some 30 plus
years later than the FILE system.

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

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

 

[Richard Heathfield]

Chuck F. said:

I see no reason for any fires. The only problem with your example
is that you can't write (in general) that type in C.

I must have misunderstood what you mean, because I see no reason whatsoever
why one could not write (in general) that type in C.

 

[Malcolm]

I know I'll get flamed for this, but with the exception of inheritance

^^^^^^^^^^^^^^^^^^^^^^^^

this is really nothing but syntactical sugar. You can write object
oriented programs in C right now.

A perfect example is the FILE data type, declared an <stdio.h>. It
has a creator, fopen(), a destructor, fclose(), and all sorts of
methods you can invoke on it via its pointer, such as fprintf(),
fscanf(), fread(), fwrite(), between its successful creation and its
destruction.

Inheritance is crucial.
An object is any set of data items that are "part of the same thing". C
structures are therefore objects. (The C standard further specifies that an
object must be stored contigously in memory. This is a language issue and a
fairly obvious thing to do, but not strictly necessary).

A program becomes "object-oriented" not when it uses objects, but when the
objects enter into relationships with each other. In C++ like most lanauges
that support obect-orientation, this is achieved via inheirtance. However
there are other ways, for example Microsoft Windows objects all respond to
the same message system, Java interfaces specify common methods, text
adventure objects have verb handlers.

 

[Chuck F.]

Chuck F. said:

I must have misunderstood what you mean, because I see no reason
whatsoever why one could not write (in general) that type in C.

I meant that to implement FILE you have to access such things as
ports, disks, etc. that take you out of pure C.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

 

[jacob navia]

Albert a écrit :

So structures are useful to group variables, so you can to refer to a
collection as a single entity. Wouldn't it be useful to also have the
ability to collect variable and functions?

Ask K&R say, C programs consist of variables to store the input and
functions to manipulate them.

This would make C object-oriented - how cool would that be?

Are there any problems with adding the ability to have functions
encapsulated in structures?

You can do this by defining an interface. I do this by using the
following schema:

The object has a pointer to the interface, called "lpVtbl", and other
fields.

The interface is a set of function pointers that defines the methods
available for the object.

For instance:

1) I define a forward declaration to the object
typedef struct _ArrayList ArrayList;

2) I define the interface functions:
typedef struct {
// Returns the number of elements stored
int (*GetCount)(ArrayList &AL);
// Is this collection read only?
int (*IsReadOnly)(ArrayList &AL);
// Sets this collection read-only or unsets the read-only flag
int (*SetReadOnly)(ArrayList &AL,int flag);
///SNIP /// SNIP /// SNIP
// Pushes a string, using the collection as a stack
int (*Push)(ArrayList &AL,void *str);
} ArrayListInterface;

3) I define the object
struct _ArrayList {
ArrayListInterface *lpVtbl; // The table of functions
size_t count; /* number of elements in the array */
void **contents; /* The contents of the collection */
size_t capacity; /* allocated space in the contents vector */
unsigned int flags; // Read-only or other flags
size_t ElementSize; // Size of the elements stored in this array
};

The usage is now very simple: For instance to get the count of elements
in an array list I do:

ArrayList al;
/// snip initialization, etc

int count = al.lpVtbl->GetCount(&al);

The lcc-win32 compiler uses this feature extensiveley to define
arraylists and other data structures in C.

jacob

 

[Eric Sosman]

[...]
For instance:

1) I define a forward declaration to the object
typedef struct _ArrayList ArrayList;

Have you forgotten that the identifier `_ArrayList'
is off-limits?

"All identifiers that begin with an underscore and
either an uppercase letter or another underscore
are always reserved for any use."
-- ISO/IEC 9899:1999 section 7.1.3 paragraph 1

 

[Richard Heathfield]

Chuck F. said:

I meant that to implement FILE you have to access such things as
ports, disks, etc. that take you out of pure C.

Oh. I thought you meant opaque types were impossible, which they clearly
aren't.

 

[Eric Sosman]

[...]
2) I define the interface functions:
typedef struct {
// Returns the number of elements stored
int (*GetCount)(ArrayList &AL);

Whatever this language is, I doubt it's topical on
comp.lang.c.

 

[Chuck F.]

[...]
For instance:

1) I define a forward declaration to the object
typedef struct _ArrayList ArrayList;

Have you forgotten that the identifier `_ArrayList'
is off-limits?

"All identifiers that begin with an underscore and
either an uppercase letter or another underscore
are always reserved for any use."
-- ISO/IEC 9899:1999 section 7.1.3 paragraph 1

In this case I think you have forgotten that Jacob is the
implementor, and thus correctly avoiding the users namespace.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

 

[jacob navia]

Eric Sosman a écrit :

[...]
2) I define the interface functions:
typedef struct {
// Returns the number of elements stored
int (*GetCount)(ArrayList &AL);

Whatever this language is, I doubt it's topical on
comp.lang.c.

Yes, replace the "&" by "*".
lcc-win32 supports "&" as in C++, but it can be
replaced by "*". References are just pointers that
can never be NULL. A pointer will do too.

 

[jacob navia]

Eric Sosman a écrit :

[...]
For instance:

1) I define a forward declaration to the object
typedef struct _ArrayList ArrayList;

Have you forgotten that the identifier `_ArrayList'
is off-limits?

"All identifiers that begin with an underscore and
either an uppercase letter or another underscore
are always reserved for any use."
-- ISO/IEC 9899:1999 section 7.1.3 paragraph 1

Yes, you are right. Just put
typedef struct tagArrayList

Sometimes I use _ because is shorter

 

[Clark S. Cox III]

Eric Sosman a écrit :

[...]
2) I define the interface functions:
typedef struct {
// Returns the number of elements stored
int (*GetCount)(ArrayList &AL);

Whatever this language is, I doubt it's topical on
comp.lang.c.

Yes, replace the "&" by "*".
lcc-win32 supports "&" as in C++, but it can be
replaced by "*". References are just pointers that
can never be NULL. A pointer will do too.

Why do you keep posting code that, while almost C, will only work on a
single compiler, on a single platform?

 

[Keith Thompson]

Eric Sosman a écrit :

[...]
For instance:

1) I define a forward declaration to the object
typedef struct _ArrayList ArrayList;

Have you forgotten that the identifier `_ArrayList'
is off-limits?
"All identifiers that begin with an underscore and
either an uppercase letter or another underscore
are always reserved for any use."
-- ISO/IEC 9899:1999 section 7.1.3 paragraph 1

Yes, you are right. Just put
typedef struct tagArrayList

Sometimes I use _ because is shorter

Why not just use

struct ArrayList {
...
};

and then consistently refer to the type as "struct ArrayList"? What
benefit does the typedef give you? (If you think not having to type
the word "struct" is enough of a benefit, I disagree but I won't argue
about it.)

 

[jacob navia]

Clark S. Cox III a écrit :

Eric Sosman a écrit :

jacob navia wrote:

[...]
2) I define the interface functions:
typedef struct {
// Returns the number of elements stored
int (*GetCount)(ArrayList &AL);



Whatever this language is, I doubt it's topical on
comp.lang.c.

Yes, replace the "&" by "*".
lcc-win32 supports "&" as in C++, but it can be
replaced by "*". References are just pointers that
can never be NULL. A pointer will do too.

Why do you keep posting code that, while almost C, will only work on a
single compiler, on a single platform?

Well, I forgot that. It is a single compiler yes, and I do not have
the means of porting it. But what's your point?

Changing "&" by "*" will make it work in any compiler in any platform.