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]

In article <11************ **********@z14g 2000cwz.googleg roups.com>,
Albert <al************ *****@gmail.com > wrote:

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.
--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes

[Chuck F.]

Walter Roberson wrote:

Albert <al************ *****@gmail.com > wrote:

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.

Methinks the OP wants lisp.

--
"If you want to post a followup via groups.google.c om, 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]

On 30 Dec 2005 17:12:33 -0800, "Albert"
<al************ *****@gmail.com > wrote in comp.lang.c:

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.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Artie Gold]

Chuck F. wrote:

Walter Roberson wrote:

Albert <al************ *****@gmail.com > wrote:

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.

Methinks the OP wants lisp.

Methinks too much credit you offer to the OP.

--ag

--
Artie Gold -- Austin, Texas
http://goldsays.blogspot.com (new post 8/5)
http://www.cafepress.com/goldsays
"If you have nothing to hide, you're not trying!"

[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?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Chuck F.]

Jack Klein wrote:

.... 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.c om, 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:

Jack Klein wrote:

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

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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Malcolm]

"Jack Klein" <ja*******@spam cop.net> wrote

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.

[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)(Arr ayList &AL);
// Is this collection read only?
int (*IsReadOnly)(A rrayList &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)(ArrayLi st &AL,void *str);
} ArrayListInterf ace;

3) I define the object
struct _ArrayList {
ArrayListInterf ace *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