Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > RE:How to realize the OOP in C?

Reply
Thread Tools

RE:How to realize the OOP in C?

 
 
pvii
Guest
Posts: n/a
 
      01-19-2004
I am reading "concepts of programming languages".
I think the oop is just a concept.
#include <stdio.h>
#define new /*"new"keyword,but it is no usage */
typedef
struct o{
/* data of object*/
char *s;
int *i;
int n;

/* here two function point and I think they are more like abstract
methords.
However, we can see them as polymorphism
*/
void (*toString)(char *,int *);
void (*init)(char *,int *,int );

/* "extend" is used to realize inheritance*/
struct o *extend;
} object;

void tS(char *s,int *n)
{
int i;
printf("My name is %s\n",s);
printf("number is %d\n",*n);
}
void IT(char *a,int *b,int n)
{
a=(char*)malloc(n*sizeof(char));
b=(int*)malloc(sizeof(int));
}
/* abstract methord are initialized */
void createp(object *p)
{
p->toString=tS;
p->init=IT;
}
object *Object(int n)
{
object *p;
p=(object*)malloc(sizeof(object));
createp(p);
p->s="object";
*(p->i)=n;
return p;
}
main()
{
object *demo;
demo=new Object(1);
demo->init(demo->s,demo->i, 10);
demo->toString(demo->s,demo->i);
getch();
}




 
Reply With Quote
 
 
 
 
E. Robert Tisdale
Guest
Posts: n/a
 
      01-19-2004
pvii wrote:

> I am reading "concepts of programming languages".
> I think the Object Oriented Programming (OOP) is just a concept.


Correct.

>
> #include <stdio.h>
> #define new /*"new"keyword,but it is no usage */
> typedef struct object {
> /* representation */
> char *s;
> int *i;
> int n;
>
> /* here two function point
> and I think they are more like abstract methods.
> However, we can see them as polymorphism */
>
> void (*toString)(char *,int *);
> void (*init)(char *,int *,int );
>
> /* "extend" is used to realize inheritance*/
> struct o *extend;
> } object;
>
> void tS(char *s, int *n) {
> int i;
> printf("My name is %s\n",s);
> printf("number is %d\n",*n);
> }
>
> void IT(char *a,int *b,int n) {
> a=(char*)malloc(n*sizeof(char));
> b=(int*)malloc(sizeof(int));
> }
>
> /* abstract method are initialized */
> void createp(object *p) {
> p->toString=tS;
> p->init=IT;
> }
>
> object *Object(int n) {
> object *p;
> p=(object*)malloc(sizeof(object));
> createp(p);
> p->s="object";
> *(p->i)=n;
> return p;
> }
>
> int main(int argc, char* argv[]) {
> object *demo;
> demo = new Object(1);
> demo->init(demo->s,demo->i, 10);
> demo->toString(demo->s,demo->i);
> getch();
> return 0;
> }


This is awful!

I used Google:

http://www.google.com/

to search for

"Object Oriented Programming in C"

and I found lots of stuff including:

http://www.accu.org/acornsig/public/articles/oop_c.html


Take a look at
The ANSI C Numerical Class Library

http://www.netwood.net/~edwin/svmtl/

Also, run-time polymorphism has been discussed at length
in the comp.lang.c newsgroup. See Google Groups

http://groups.google.com/

and search for

Tisdale Shape group:comp.lang.c.*

Both Re: "class" in C and Re: C version of C++'s virtual functions
contain an ANSI C implementation of Bjarne Stroustrups Shape class.

 
Reply With Quote
 
 
 
 
xarax
Guest
Posts: n/a
 
      01-19-2004
"pvii" <(E-Mail Removed)> wrote in message news:bufo8o$hr2$(E-Mail Removed)99.com...
> I am reading "concepts of programming languages".
> I think the oop is just a concept.
> #include <stdio.h>
> #define new /*"new"keyword,but it is no usage */
> typedef
> struct o{
> /* data of object*/
> char *s;
> int *i;
> int n;
>
> /* here two function point and I think they are more like abstract
> methords.
> However, we can see them as polymorphism
> */
> void (*toString)(char *,int *);
> void (*init)(char *,int *,int );
>
> /* "extend" is used to realize inheritance*/
> struct o *extend;
> } object;
>
> void tS(char *s,int *n)
> {
> int i;
> printf("My name is %s\n",s);
> printf("number is %d\n",*n);
> }
> void IT(char *a,int *b,int n)
> {
> a=(char*)malloc(n*sizeof(char));
> b=(int*)malloc(sizeof(int));
> }
> /* abstract methord are initialized */
> void createp(object *p)
> {
> p->toString=tS;
> p->init=IT;
> }
> object *Object(int n)
> {
> object *p;
> p=(object*)malloc(sizeof(object));
> createp(p);
> p->s="object";
> *(p->i)=n;
> return p;
> }
> main()
> {
> object *demo;
> demo=new Object(1);
> demo->init(demo->s,demo->i, 10);
> demo->toString(demo->s,demo->i);
> getch();
> }


Probably way off topic here.

Generally, you want the object instance to
be a pointer to a standard structure like:

================================================
/* forward reference to the object structure */
typedef struct object_of_fubar * ObjectOfFubarP;

typedef struct class_of_fubar
{
/* instance method: gorko */
int (*gorko)(ObjectOfFubarP,char*);

/* instance method: snafu */
void (*snafu)(ObjectOfFubarP,int,int);
} ClassOfFubar, * ClassOfFubarP;

typedef struct instance_data_of_fubar
{
/* whatever instance data you want */
int snarf;
short grib;
} InstanceDataOfFubar, * InstanceDataOfFubarP;

typedef struct object_of_fubar
{
/* points to class structure */
ClassOfFubarP classOfFubarP;

/* points to the object's instance data */
InstanceDataOfFubarP instanceDataOfFubarP;
} ObjectOfFubar;
================================================

Instance methods always receive their first
parameter as a pointer to the object that
was used to invoke them (ObjectOfFubarP),
followed by any other parameters they need.

Instance methods are defined as function
pointers in the class structure, so they
have a local namespace. Multiple classes
can use the same function names, because
they are simply fields within the class
structure (defined as function pointer types).

The object reference points to the structure
that has two pointers: Pointer to the class
structure and pointer to the instance data
for the object.

Single inheritance is simply extending these
structures by adding new methods or new instance
fields onto the end of the parent structure. When
an object is instantiated by a constructor function,
space is allocated for the instance data and the
object structure, then the pointers are filled-in.
Note that the class structure is allocated only
once and a pointer to it is stuffed into each object
that is allocated. The constructor uses a singleton
class structure that is specific to its class, and
it must call its parent constructor to let the parent
fill-in its own fields before the constructor assigns
values for its own extensions.

Multiple inheritance is more complicated, but it
is still possible to resolve a method call in
constant time.

There's much more to it, but that's the
gist of it.



--
----------------------------
Jeffrey D. Smith
Farsight Systems Corporation
24 BURLINGTON DRIVE
LONGMONT, CO 80501-6906
http://www.farsight-systems.com
z/Debug debugs your Systems/C programs running on IBM z/OS!
Are ISV upgrade fees too high? Check our custom product development!


 
Reply With Quote
 
Jack Klein
Guest
Posts: n/a
 
      01-19-2004
On Mon, 19 Jan 2004 13:09:43 +0800, "pvii" <(E-Mail Removed)> wrote
in comp.lang.c:

> I am reading "concepts of programming languages".
> I think the oop is just a concept.


Perhaps you should actually learn the C language before you decide to
extend it.

> #include <stdio.h>
> #define new /*"new"keyword,but it is no usage */
> typedef
> struct o{
> /* data of object*/
> char *s;
> int *i;
> int n;
>
> /* here two function point and I think they are more like abstract
> methords.
> However, we can see them as polymorphism
> */


Why does everyone thing that object orientation requires polymorphism?
It most surely does not.

> void (*toString)(char *,int *);
> void (*init)(char *,int *,int );
>
> /* "extend" is used to realize inheritance*/
> struct o *extend;
> } object;


> void tS(char *s,int *n)
> {
> int i;


Local variable i defined but never initialized or used.

> printf("My name is %s\n",s);
> printf("number is %d\n",*n);
> }


What exactly do you think the code above does? It certainly doesn't
do whatever it is you think.

> void IT(char *a,int *b,int n)
> {
> a=(char*)malloc(n*sizeof(char));
> b=(int*)malloc(sizeof(int));


The two calls above invoke undefined behavior as there is no prototype
for malloc() in scope. The (questionable at best in C) cast of
malloc's return value will prevent the compiler from issuing an
otherwise required diagnostic. There are implementations on which
this code will fail badly.

The best way to write these allocations, after including <stdlib.h>,
is this:

a = malloc(n * sizeof *a);
b = malloc (sizeof *b);

> }


Of course the pointers a and b essentially local to the function IT.
Their values are abandoned when the function returns, and you have
created a memory leak. Most specifically, the function does not
change the value of any pointers in the calling function.

> /* abstract methord are initialized */
> void createp(object *p)
> {
> p->toString=tS;
> p->init=IT;
> }
> object *Object(int n)
> {
> object *p;
> p=(object*)malloc(sizeof(object));


Again, undefined behavior due to lack of prototype, and it is almost
never necessary to use the sizeof operator on a type. Much better:

p = malloc(sizeof *p);

> createp(p);
> p->s="object";


This is OK, sets the p member of the structure to the address of a
string literal.

> *(p->i)=n;


Oops, back to undefined behavior again. The i member of the structure
is an uninitialized pointer. Any use of an uninitialized value is
undefined, but using an uninitialized pointer to store a value is
particularly bad news.

> return p;
> }
> main()


int main() or int main(void), please. Implicit int is illegal under
the current C language standard.

> {
> object *demo;
> demo=new Object(1);
> demo->init(demo->s,demo->i, 10);
> demo->toString(demo->s,demo->i);


Your whole "looks like C++" metaphor breaks down here, in a true
object oriented environment, the caller would not have access to the s
and i members.

> getch();


No such function in the standard library. Also, even though you
defined your main() to return an (implicit) int, you did not return
one.

> }


The problem is that most people who try to do object oriented
programming in C have far too little imagination. What they are
actually trying to do is to write C++ in.

C already has perfectly good object oriented operations, although some
don't recognize them as such because they don't look like C++.

Consider the FILE opaque object in <stdio.h>. It is an opaque type,
in that the C standard does not define its contents at all. It has a
creator named fopen() that indicates whether or not it successfully
created an object. It has a variety of "methods" that can operate on
a valid FILE object, and only on a valid FILE object, such as fread(),
fwrite(), putc(), getc(), and many more. It even has a "destructor"
named fclose(). But because you pass the object to be acted on (a
particular pointer to FILE) as an ordinary parameter instead of as a
hidden "this" pointer.

If you really want C++ (or C#, or Java, or the flavor of the month)
you know where to get it. If you want object orientation in C, look
at <stdio.h>. There are situations in C where it makes sense to store
function pointers inside structures, but simulating C++ is probably
not one of them.

--
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++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
 
Reply With Quote
 
Michael B Allen
Guest
Posts: n/a
 
      01-19-2004
On Mon, 19 Jan 2004 00:09:43 -0500, pvii wrote:
> /* here two function point and I think they are more like abstract
> methords.
> However, we can see them as polymorphism
> */
> void (*toString)(char *,int *);
> void (*init)(char *,int *,int );
>
> /* "extend" is used to realize inheritance*/ struct o *extend;
> } object;

<snip fancy OOP in C stuff>

What is the point of this? Just use C++. Otherwise you can usually
achive the same overall behavior without using OOP techniques. OOP
is so overrated. People think it's some kind of key to organize your
programs. When you isolate the concept of a task and write your code to
handle that generically then you program is well organized. You don't
need OOP to do that. For certain problems it makes a lot of sense but
it's only one facet of may techniques that can be used.

If you're going to write C use it for what it's good at; direct, precise,
fast, low-level type of work. Don't try to get fancy.

Mike
 
Reply With Quote
 
Bruno Desthuilliers
Guest
Posts: n/a
 
      01-19-2004
Jack Klein wrote:
> On Mon, 19 Jan 2004 13:09:43 +0800, "pvii" <(E-Mail Removed)> wrote
> in comp.lang.c:
>
>
>>I am reading "concepts of programming languages".
>>I think the oop is just a concept.

>
>

(snip)
>>
>> /* here two function point and I think they are more like abstract
>>methords.
>> However, we can see them as polymorphism
>> */

>
>
> Why does everyone thing that object orientation requires polymorphism?
> It most surely does not.


<OT>
Could you explain your POV with more detail ? Since IMHO, polymorphism
is one of the very most important key features of OO, I'd be interested
to learn more about your assertion.

(and since it's OT here, x-post and fu2 c.object)
</OT>


Bruno

 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      01-19-2004
Jack Klein wrote:
> "pvii" <(E-Mail Removed)> wrote
>
> > I am reading "concepts of programming languages".
> > I think the oop is just a concept.

>
> Perhaps you should actually learn the C language before you decide
> to extend it.
>

.... snip ...
>
> C already has perfectly good object oriented operations, although
> some don't recognize them as such because they don't look like C++.
>
> Consider the FILE opaque object in <stdio.h>. It is an opaque
> type, in that the C standard does not define its contents at all.
> It has a creator named fopen() that indicates whether or not it
> successfully created an object. It has a variety of "methods"
> that can operate on a valid FILE object, and only on a valid FILE
> object, such as fread(), fwrite(), putc(), getc(), and many more.
> It even has a "destructor" named fclose(). But because you pass
> the object to be acted on (a particular pointer to FILE) as an
> ordinary parameter instead of as a hidden "this" pointer.


Nothing wrong with your comments, except that many systems expose
the construction of FILE in order to implement macros such as
putc. A module that has strictly and deliberately maintained the
integrity and privacy of internal structure can be seen in
hashlib.zip, which in turn can be found at:

<http://cbfalconer.home.att.net/download/>

It is written in purely standard C, and should compile and port
anywhere. It deliberately uses oop techniques.

--
Chuck F ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!


 
Reply With Quote
 
Bruno Desthuilliers
Guest
Posts: n/a
 
      01-19-2004
pvii wrote:
> I am reading "concepts of programming languages".
> I think the oop is just a concept.


OO is just a concept. That's true. And ?

(snip code that won't work)

If you're looking for production-quality OOP stuff in C, you may want to
google for Gtk+ and/or Laurent Deniau's OOPC (this second exemple is
designed to emulate C++ on platforms where it is not available).

Now,
- as Micheal Allen said, OOP is not the only way to write good, modular
code with hi internal cohesion and low external coupling, and
- if you really need a good OO support, the logical and sensible thing
to do is probably to switch to a full blown OOPL (if possible of course).

Bruno

 
Reply With Quote
 
E. Robert Tisdale
Guest
Posts: n/a
 
      01-19-2004
xarax wrote:

>
>
> Probably way off topic here.
>
> Generally, you want the object instance to
> be a pointer to a standard structure like:
>
> ================================================
> /* forward reference to the object structure */
> typedef struct object_of_fubar * ObjectOfFubarP;


This is almost always a bad idea.

>
> typedef struct class_of_fubar
> {
> /* instance method: gorko */
> int (*gorko)(ObjectOfFubarP,char*);
>
> /* instance method: snafu */
> void (*snafu)(ObjectOfFubarP,int,int);
> } ClassOfFubar, * ClassOfFubarP;


No!
The methods are bound to the type -- not the object.

>
> typedef struct instance_data_of_fubar
> {
> /* whatever instance data you want */
> int snarf;
> short grib;
> } InstanceDataOfFubar, * InstanceDataOfFubarP;
>
> typedef struct object_of_fubar
> {
> /* points to class structure */
> ClassOfFubarP classOfFubarP;
>
> /* points to the object's instance data */
> InstanceDataOfFubarP instanceDataOfFubarP;


A Pointer IMPLementation (PIMPL) is *not* required.

> } ObjectOfFubar;
> ================================================
>
> Instance methods always


No. This is merely a convention.

> receive their first parameter as a pointer to the object that
> that was used to invoke them (ObjectOfFubarP),
> followed by any other parameters they need.
>
> Instance methods are defined as function
> pointers in the class structure, so they
> have a local namespace. Multiple classes
> can use the same function names, because
> they are simply fields within the class
> structure (defined as function pointer types).
>
> The object reference points to the structure
> that has two pointers: Pointer to the class
> structure and pointer to the instance data
> for the object.
>
> Single inheritance is simply extending these
> structures by adding new methods or new instance
> fields onto the end of the parent structure. When
> an object is instantiated by a constructor function,
> space is allocated for the instance data and the
> object structure, then the pointers are filled-in.
> Note that the class structure is allocated only
> once and a pointer to it is stuffed into each object
> that is allocated. The constructor uses a singleton
> class structure that is specific to its class, and
> it must call its parent constructor to let the parent
> fill-in its own fields before the constructor assigns
> values for its own extensions.
>
> Multiple inheritance is more complicated
> but it is still possible to resolve a method call in
> constant time.
>
> There's much more to it, but that's the gist of it.


Please elaborate.
Show us how you create and destroy an object
of type struct object_of_fubar.


 
Reply With Quote
 
E. Robert Tisdale
Guest
Posts: n/a
 
      01-19-2004
Jack Klein wrote:

> Why does everyone think that object orientation requires polymorphism?


Not everyone does.

> It most surely does not.


According to Bjarne Stroustrup,
an object oriented programming *language* must support

1. encapsulation,
2. inheritance and
3. [run-time] polymorphism.

Because the C programming language does not directly support inheritance
or polymorphism, it is not an object oriented programming language
but you can still write object oriented programs in C.

Run-time (or dynamic) polymorphism is the only kind of polymorphism
supported by Smalltalk and Java. C++ is more complicated and powerful.
Run-time polymorphism is typically implemented as a jump-table
(virtual function table) initialized with pointers to callback functions
(methods) appropriate for the type when the type is defined.
Each object includes an immutable reference to the jump table
appropriate for its type.

Classes are distinguished from objects in both Java and C++.
The difference is that each class definition automatically instantiates
an object with the same name as the class in Java.
This imposes a small overhead
that Bjarne Stroustrup thought C++ programmers would not accept.

The advantage to programming in C or C++ is that
methods need not be implemented as callback functions.
They can be inline'd to avoid the cost of a function call
and to allow the compiler to take advantage of optimizations
that are not possible unless the function is inline'd.

> Consider the FILE opaque object in <stdio.h>. It is an opaque type,
> in that the C standard does not define its contents at all.
> It has a creator named fopen() that indicates whether or not
> it successfully created an object. It has a variety of "methods"
> that can operate on a valid FILE object and only on a valid FILE
> object, such as fread(), fwrite(), putc(), getc(), and many more.
> It even has a "destructor" named fclose(). But, because
> you pass the object to be acted on (a particular pointer to FILE)
> as an ordinary parameter instead of as a hidden "this" pointer.
>
> If you really want C++ (or C#, or Java, or the flavor of the month)
> you know where to get it.
> If you want object orientation in C, look at <stdio.h>.
> There are situations in C
> where it makes sense to store function pointers inside structures,


These are *exactly* the situations
where it makes sense to use *virtual* functions in C++.

> but simulating C++ is probably not one of them.


There is *nothing* new in object oriented programming.
Good programmers have always written "object oriented" programs
and C FILE objects are just one example.
Object oriented programs like Smalltalk, Java and C++ just make
object oriented programming a little easier and more reliable.

If you don't know how to write object oriented programs in C,
you're just not a very good C programmer.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
To A.Friend (online criminals, they don't realize anything) oj Computer Support 1 10-20-2005 04:43 PM
how to realize WDS?? sjdy Wireless Networking 1 04-04-2005 05:05 AM
How to realize the communication of applet and ejb? 王崟 Java 0 08-23-2004 05:42 AM
Switching items between listboxes, and letting .net realize it. Ryan Ternier ASP .Net 1 07-25-2004 05:18 PM
How to realize user interfereing like CS program? Lei Guangfu ASP .Net 1 10-19-2003 06:31 AM



Advertisments