RE:How to realize the OOP in C?

Discussion in 'C Programming' started by pvii, Jan 19, 2004.

  1. pvii

    pvii Guest

    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();
    }
     
    pvii, Jan 19, 2004
    #1
    1. Advertising

  2. Re: How to realize the OOP in C?

    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.
     
    E. Robert Tisdale, Jan 19, 2004
    #2
    1. Advertising

  3. pvii

    xarax Guest

    "pvii" <> wrote in message news:bufo8o$hr2$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!
     
    xarax, Jan 19, 2004
    #3
  4. pvii

    Jack Klein Guest

    Re: How to realize the OOP in C?

    On Mon, 19 Jan 2004 13:09:43 +0800, "pvii" <> 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/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Jan 19, 2004
    #4
  5. 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
     
    Michael B Allen, Jan 19, 2004
    #5
  6. Re: How to realize the OOP in C?

    Jack Klein wrote:
    > On Mon, 19 Jan 2004 13:09:43 +0800, "pvii" <> 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
     
    Bruno Desthuilliers, Jan 19, 2004
    #6
  7. pvii

    CBFalconer Guest

    Re: How to realize the OOP in C?

    Jack Klein wrote:
    > "pvii" <> 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 () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Jan 19, 2004
    #7
  8. Re: How to realize the OOP in C?

    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
     
    Bruno Desthuilliers, Jan 19, 2004
    #8
  9. Re: How to realize the OOP in C?

    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.
     
    E. Robert Tisdale, Jan 19, 2004
    #9
  10. Re: How to realize the OOP in C?

    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.
     
    E. Robert Tisdale, Jan 19, 2004
    #10
  11. EventHelix.com, Jan 20, 2004
    #11
  12. pvii

    Jack Klein Guest

    Re: How to realize the OOP in C?

    On Mon, 19 Jan 2004 13:55:44 -0800, "E. Robert Tisdale"
    <> wrote in comp.lang.c:

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


    Far be it from me to argue with Dr. Stroustrup, for whom I have a
    great deal of respect, but that is his opinion. There is no ISO or
    other widely accepted official standard about what constitutes "object
    oriented" and what does not.

    These are the features that he felt C lacked to serve his purposes,
    and these are the features he added to C to serve his purposes. In
    the process he created a much larger language that can cope will with
    problem domains where C is not suitable.

    But all of that does not mean that anything lacking these features is
    by universal definition "object oriented".

    I am glad you said above that C does not "directly support" because as
    we all know, C++ compilers originally used C as an intermediate
    language. And at least one, Comeau, which is arguably the most
    standard conforming in existence today, still does.

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


    The details of how these languages implement their features is really
    not relevant.

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


    Actually there are plenty of situations where the function pointer in
    a structure is used in ways not similar to "methods" at all.

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


    I hope that this remark was intended for the OP and not me. I have
    written object oriented programs in C for a long time, and I continue
    to do so.

    The real point is that good object oriented programming in C generally
    does not end up looking like C++. C++ is available for just about all
    but the smallest embedded platforms these days. If someone wants to
    write object oriented code that looks like C++, they should probably
    use C++.

    I have yet to see a case where attempting to write C++ in C has
    resulted in anything other than poor C and poor C++.

    --
    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/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Jan 20, 2004
    #12
  13. Re: How to realize the OOP in C?

    Jack Klein wrote:

    > E. Robert Tisdale wrote:
    >
    >>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.

    >
    > Far be it from me to argue with Dr. Stroustrup,
    > for whom I have a great deal of respect, but that is his opinion.
    > There is no ISO or other widely accepted official standard
    > about what constitutes "object oriented" and what does not.


    No. But you could take a more pragmatic approach.
    Bjarne Stroustrup simply cites three features which distinguish between
    computer programming languages that their respective designers, users
    and protagonists claim to be "object oriented" or not.
    Certainly, Bjarne Stroustrup tried to pick three features
    that he felt were essential to being "object oriented"
    but they are certainly not unique or complete.

    > These are the features that he felt C lacked to serve his purposes,
    > and these are the features he added to C to serve his purposes.
    > In the process he created a much larger language
    > that can cope will with problem domains where C is not suitable.


    Nonsense! C is suitable for *any* purpose.
    This thread demonstrates that.
    C++ simply introduces features (mostly stolen from other languages)
    that make it easier for C programmers to write reliable programs
    that are easier to read, understand and maintain.

    > But all of that does not mean that anything lacking these features
    > is by universal definition "object oriented".
    >
    > I am glad you said above that C does not "directly support"
    > because, as we all know,
    > C++ compilers originally used C as an intermediate language.


    So do some Fortran compilers.

    > And at least one, Comeau, which is arguably the most
    > standard conforming in existence today, still does.


    Most assembler don't provide direct support for structured programming
    yet most compilers for structured programing languages emit assembler.
    And, yes, I realize that
    this remark is no more relevant than yours above.

    > I hope that this remark was intended for the OP and not me.


    Correct.

    > I have written object oriented programs in C for a long time
    > and I continue to do so.


    And my guess is that you are a *very* good C programmer.

    > The real point is that good object oriented programming in C
    > generally does not end up looking like C++.
    > C++ is available for just about all but
    > the smallest embedded platforms these days.
    > If someone wants to write object oriented code that looks like C++
    > they should probably use C++.
    >
    > I have yet to see a case where attempting to write C++ in C
    > has resulted in anything other than poor C and poor C++.


    I think that I know what you mean.
    C programmers sometimes attempt to mimic the C++ *syntax*
    in an attempt to make their code "look like C++".
    Worse, both C and C++ programmers sometimes attempt to mimic
    Java syntax *and* semantics. It's always a disaster.
     
    E. Robert Tisdale, Jan 20, 2004
    #13
  14. pvii

    Richard Bos Guest

    Re: How to realize the OOP in C?

    "E. Robert Tisdale" <> wrote:

    > 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


    Ah, yes. And what does _he_ know? He's written C++, yeah. A language
    with the reputation of being not an object-oriented language, but an
    imperative language with some object-oriented features bolted to the
    side.

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


    Indeed. Something which I've been saying for years, but not many C++
    adherents seem to understand.

    Richard
     
    Richard Bos, Jan 20, 2004
    #14
  15. pvii

    Calum Guest

    Re: How to realize the OOP in C?

    E. Robert Tisdale wrote:
    <snip>
    > There is *nothing* new in object oriented programming.
    > Good programmers have always written "object oriented" programs
    > and C FILE objects are just one example.


    Okay, so C++ generalizes FILEs into streams. Prejudices aside, would it
    be possible to take a piece of C code that was written to use a FILE,
    and plug in something similar to a stringstream or strstream. So the
    FILE now reads/writes a buffer in memory. Is /that/ possible in C?

    Or what about deciding that your documents needs to be in Unicode, and
    that you now want to write Unicode streams. Could you just plug in a
    Unicode-based stream into a C FILE without modification?

    Or would both cases involve quite a lot of recoding, with separate
    code-bases to maintain? What exactly is polymorphic about FILE, that
    makes it an "object" in the conventional sense?

    Your example demonstrates the differences rather than the similarities
    between procedural and OOPLs.
     
    Calum, Jan 20, 2004
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Lei Guangfu
    Replies:
    1
    Views:
    324
    Natty Gur
    Oct 19, 2003
  2. Ryan Ternier
    Replies:
    1
    Views:
    576
    John Saunders
    Jul 25, 2004
  3. Íõ•
    Replies:
    0
    Views:
    550
    Íõ•
    Aug 23, 2004
  4. Shugong Wang
    Replies:
    2
    Views:
    9,683
    Raymond Martineau
    Nov 28, 2004
  5. Davide  M3xican  Coppola

    how to realize a friend interface?

    Davide M3xican Coppola, Apr 21, 2005, in forum: C++
    Replies:
    3
    Views:
    439
    Davide M3xican Coppola
    Apr 26, 2005
Loading...

Share This Page