«

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?

In article < .com>,
Albert <> 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

Walter Roberson wrote:
> Albert <> 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.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/>

On 30 Dec 2005 17:12:33 -0800, "Albert"
<> 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.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

Chuck F. wrote:
> Walter Roberson wrote:
>
>> Albert <> 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!"

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)

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

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)

"Jack Klein" <> 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.

Richard Heathfield wrote:
> 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.

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