how to use pure c to write OO programs

[zhuyin.nju]

can some one tell that how to use pure c to write OO programs?

thanks in advanced!

 

[Zara]

can some one tell that how to use pure c to write OO programs?

thanks in advanced!

I don´t think "pure" is the right adjective.

Use structs, pointers to structs, pointer to functions, enums.

Do not use unions.

Practise a lot.

Good Luck!

 

[EventHelix.com]

The following article gives an example of object oriented programming
in C:

http://www.eventhelix.com/RealtimeMantra/basics/object_oriented_programming_in_c.htm

 

[Skarmander]

can some one tell that how to use pure c to write OO programs?

1. Face a wall.
2. Take quite a few steps back.
3. Holding your head down, run towards the wall.
4. Repeat until you feel you have inflicted enough harm on yourself.

I realize this is not really helpful. Neither is pure C when it comes to
O-O programming, however.

In my opinion, you'd be much better off using a C++ frontend,
restricting yourself to basic O-O concepts while ignoring the C++ bells
and whistles that are not essential to your design. I don't know about
any frontends still out there, though ("if I want C++, I know where to
get it"). Anyone know if cfront or a clone still lives, and is of any use?

You could even go crazy and use, you know, an actual C++ compiler. Many
produce quite acceptable code (in terms of size/speed/overhead) for
simple C++ that doesn't pull in all the STL goodies. In fact, the
initial design criteria for C++, for better or worse, included the
notion that compilers shouldn't be too burdened processing it
effectively (not much was left of this notion by the time the language
was finalized, but that's another issue).

Of course this won't help you if you don't have a C++ compiler for the
platform or if object file compatibility with C code is necessary, but
it's still worth considering.

S.

 

[Marc Boyer]

1. Face a wall.
2. Take quite a few steps back.
3. Holding your head down, run towards the wall.
4. Repeat until you feel you have inflicted enough harm on yourself.

I realize this is not really helpful. Neither is pure C when it comes to
O-O programming, however.

In my opinion, you'd be much better off using a C++ frontend,
restricting yourself to basic O-O concepts while ignoring the C++ bells
and whistles that are not essential to your design. I don't know about
any frontends still out there, though ("if I want C++, I know where to
get it"). Anyone know if cfront or a clone still lives, and is of any use?

The comeau compiler generates C from C++:
http://www.comeaucomputing.com/
What Is Comeau C/C++ 4.3.3?

Comeau C/C++ is a command line driven C and C++ compiler that generates
platform specific and C compiler specific C as its object code (the
generated C code won't work on another platform, as it is CPU, OS and C
compiler specific, and furthermore, it is not standalone)

Marc Boyer

 

[Singamsetty]

The following article gives an example of object oriented programming
in C:

http://www.eventhelix.com/RealtimeMantra/basics/object_oriented_programming_in_c.htm

The main characteristics of an object oriented programming are
encapsulation, inheritance and polymorphism. We can achieve
encapsulation - information hiding, data abstraction - in C (by
implementing ADTs or modules) but not the other two. C is more of a
object-based programming language (not OO language). I guess, there is
a good discussion in Stroustrup C++ book on object-based (C-like) and
OO (C++ like) paradigms.

- Singamsetty

 

[Guillaume]

I was wondering how long it would take before someone says to use C++.
As it turned out, almost 4 hours.
Of course, you could have gone one step further and suggest ADA.
Oh well... lol ;-)

 

[Skarmander]

I was wondering how long it would take before someone says to use C++.
As it turned out, almost 4 hours.

Remember, folks: propagation of Usenet posts can take anywhere from
minutes to days. You never know who reads what and when. So I guess I'm
just lucky! What did I win?

Of course, you could have gone one step further and suggest ADA.

No. I did make an effort not to stray too far from the OP's intent,
having noticed that others had already answered the question directly.
Would the question really have been answered in full without at least
the suggestion of C++, taking the possible reasons why it could have
rejected it into account?

Ada qualifies as "too far". I could have recommended Java, then; at
least that's more syntax-friendly to C programmers. If someone wants to
do O-O in C, though, there's probably a good reason why Java would be
out of the question. A C++ frontend may just have been missed as an option.

S.

 

[Keith Thompson]

1. Face a wall.
2. Take quite a few steps back.
3. Holding your head down, run towards the wall.
4. Repeat until you feel you have inflicted enough harm on yourself.

I realize this is not really helpful. Neither is pure C when it comes to
O-O programming, however.

In my opinion, you'd be much better off using a C++ frontend,
restricting yourself to basic O-O concepts while ignoring the C++ bells
and whistles that are not essential to your design. I don't know about
any frontends still out there, though ("if I want C++, I know where to
get it"). Anyone know if cfront or a clone still lives, and is of any use?

I don't see the point of using a C++ frontend (presumably something
that translates C++ to C) as opposed to a C compiler.

The C generated by a translator is unlikely to be maintainable or even
legible. In ordinary usage, you're never even going to look at it;
you'll just feed it to a C compiler. Assuming a C++ compiler is
available for your platform, there's no real benefit in generating
unmaintanable C as an intermediate step.

There are ways to do OO in C, but they tend to be clumsy compared to
using a language with OO facilities built-in.

To the OP: Why do you specifically want to use pure C?

 

[Keith Thompson]

I was wondering how long it would take before someone says to use C++.
As it turned out, almost 4 hours.
Of course, you could have gone one step further and suggest ADA.
Oh well... lol ;-)

And why is that amusing? C++ may well turn out to be the best
solution for the OP's problem. (Ada might not be such a bad idea
either.)

 

[Skarmander]

I don't see the point of using a C++ frontend (presumably something
that translates C++ to C) as opposed to a C compiler.

Because a C compiler won't let you compile C++. You meant "as opposed to
a C++ compiler", perhaps? Or just "write in C"?

The C generated by a translator is unlikely to be maintainable or even
legible. In ordinary usage, you're never even going to look at it;
you'll just feed it to a C compiler.
Yes.

Assuming a C++ compiler is available for your platform, there's no
real benefit in generating unmaintanable C as an intermediate step.

That is:
- assuming there *is* a C++ compiler of sufficient quality available
(and "quality" may also imply "low overhead", which is certainly an
issue for many C++ compilers);

- assuming you do not need low-level compatibility with C (name
mangling, linkage etc.; some of this will play a role with a frontend
too, but is likely far easier to cope with).

There are ways to do OO in C, but they tend to be clumsy compared to
using a language with OO facilities built-in.

Precisely. Which is why my first advice is: don't do it. The second is:
if you *must* get C for some reason (you need to interface directly with
existing C code, your compiler supports only C) and you *must* use an
O-O design (for reasons I can't make up, but there undoubtedly will be
some) why *not* a frontend?

S.

 

[E. Robert Tisdale]

The main characteristics of an object oriented programming are
encapsulation,
inheritance and
[run-time] polymorphism.
We can achieve encapsulation - information hiding, data abstraction - in C
(by implementing ADTs or modules) but not the other two.

Not quite.
The C computer programming language supports encapsulation
but not data hiding.
Opaque data types are only an inferior attempt at data hiding.
C supports data abstraction in a number of ways
including typedefs and structs.
C structs are used to introduce User Defined Types (UDTs)
which can implement Abstract Data Types (ADTs).
C does *not* support inheritance
so programmers are obliged to cast [pointers] to the base type.
C programmers have always implemented run-time polymorphism
using jump tables (virtual function tables).
The standard FILE type is an example of run-time polymorphism.

Search Google Groups

http://groups.google.com/

for

comp.lang.c Object-Oriented Programming (run-time polymorphism) with C99

Please find attached a copy of the "Shape class" example from
Bjarne Stroustrup, "The C++ Programming Language: Third Edition",
Chapter 2: A Tour of C++, Section 6: Object-Oriented Programming,
Subsection 2: Class Hierarchies, pages 38-40 implemented in C99.

C is more of a object-based programming language (not OO language).
I guess, there is a good discussion in Stroustrup's C++ book
on object-based (C-like) and OO (C++ like) paradigms.

A citation please.

 

[Keith Thompson]

Keith Thompson wrote: [...]

I don't see the point of using a C++ frontend (presumably something
that translates C++ to C) as opposed to a C compiler.

Because a C compiler won't let you compile C++. You meant "as opposed
to a C++ compiler", perhaps? Or just "write in C"?

Whoops, I meant "as opposed to a C++ compiler".

BTW, a C++ frontend (translating C++ to C) in combination with a C
compiler *is* a C++ compiler. The fact that it uses C as an
intermediate language isn't likely to be particularly useful in any
likely scenario I can think of. You can examine the generated C code
to see what symbols it uses, but you can just as easily examine an
object file, which is likely to be about as legible.

This may be another of those "How do I drive screws without using a
screwdriver?" questions. Advising the questioner on how to hit the
screws really hard with a hammer probably isn't helpful until we find
out *why* he doesn't want to use a screwdriver.

 

[Skarmander]

Keith Thompson wrote:
[...]

I don't see the point of using a C++ frontend (presumably something
that translates C++ to C) as opposed to a C compiler.

Because a C compiler won't let you compile C++. You meant "as opposed
to a C++ compiler", perhaps? Or just "write in C"?

Whoops, I meant "as opposed to a C++ compiler".

BTW, a C++ frontend (translating C++ to C) in combination with a C
compiler *is* a C++ compiler.
Yes.

The fact that it uses C as an intermediate language isn't likely to
be particularly useful in any likely scenario I can think of. You
can examine the generated C code to see what symbols it uses, but you
can just as easily examine an object file, which is likely to be
about as legible.

Not quite. The frontend will certainly generate code you can link with
other object files. The same is not true of your C++ compiler and C
object files, even if you use the "same" compiler for both. Especially
if we can disregard issues of overloading, multiple inheritance and all
that malarkey.

Of course, this means pointing out that expecting linkage from and to C
to "magically" work out means you're counting on your implementation's
amenities to save the day, which may or may not be acceptable. If the
intent is portable C++ code even *without* the frontend (that is, you
want the compiler to be *fully* transparent) it's not good enough.

This may be another of those "How do I drive screws without using a
screwdriver?" questions. Advising the questioner on how to hit the
screws really hard with a hammer probably isn't helpful until we find
out *why* he doesn't want to use a screwdriver.

And possibly it is, making an educated guess about why he wouldn't want
to use it. Of course, I could guess wrong. Such is life. Caveat lector,
you get what you pay for, etc.

S.

 

[bwegge]

You should read this paper on OO in ansi C -
www.planetpdf.com/codecuts/pdfs/ooc.pdf. I don't like the use of the
preprocessor in this paper, but thats just me. Also Scott Meyers book
"Effective C++: 50 ways .." gives good insight into how C++ works, and
can be recommended if you want to make OO in C. I found it very
helpful, when trying to do OO in C.

Basically, you will find it very difficult (if not impossible) to do
stuff like (operator) overloading and automatic calls to
constructors/destructors. Inheritance and virtual methods (essence of
OO) is fairly straight forward to do, but the biggest problem is not
doing OO in C. It is getting those who read your code a year from now
to understand what you are doing. OO in C looks very complicated and is
in my experience a good way to make your code more error prone. In
other words, dont go there unless you absolutely have to.

Regards
Bwegge

 

[Michael Wojcik]

The main characteristics of an object oriented programming are
encapsulation, inheritance and polymorphism. We can achieve
encapsulation - information hiding, data abstraction - in C (by
implementing ADTs or modules) but not the other two.

Utter rot. C doesn't provide syntactic sugar for polymorphism, but
there's nothing preventing you from implementing it manually. The
same can be said of inheritance, unless you use an overly-restrictive
definition of the term.

And, of course, it's always possible to implement one Turing-complete
language in another.

This has been discussed ad nauseum here.

 

[Christopher Benson-Manica]

You should read this paper on OO in ansi C -
www.planetpdf.com/codecuts/pdfs/ooc.pdf. I don't like the use of the
(snip context-free text)

It is proper Usenet etiquette to include the relevant portions of the text
you are replying to. To do this using Google groups, please follow the
instructions below, penned by Keith Thompson:

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.

 

[E. Robert Tisdale]

You should read this paper on OO in ansi C -
www.planetpdf.com/codecuts/pdfs/ooc.pdf.

I don't think that this approach to object oriented programming
is a very good idea.

 

[Greg Comeau]

1. Face a wall.
2. Take quite a few steps back.
3. Holding your head down, run towards the wall.
4. Repeat until you feel you have inflicted enough harm on yourself.

I realize this is not really helpful. Neither is pure C when it comes to
O-O programming, however.

In my opinion, you'd be much better off using a C++ frontend,
restricting yourself to basic O-O concepts while ignoring the C++ bells
and whistles that are not essential to your design. I don't know about
any frontends still out there, though ("if I want C++, I know where to
get it"). Anyone know if cfront or a clone still lives, and is of any use?

Comeau C++, currently not based on cfront, generates C as an
internal phase of translation, is going strong. However, not
knowing the underlying reason for the OPs query, it's unclear
if that's what the OP is seeking.

You could even go crazy and use, you know, an actual C++ compiler.

Comeau C++ is an actual C++ compiler.

Many
produce quite acceptable code (in terms of size/speed/overhead) for
simple C++ that doesn't pull in all the STL goodies. In fact, the
initial design criteria for C++, for better or worse, included the
notion that compilers shouldn't be too burdened processing it
effectively (not much was left of this notion by the time the language
was finalized, but that's another issue).

That two main hits on C++ are iostreams and exception handling.

Of course this won't help you if you don't have a C++ compiler for the
platform or if object file compatibility with C code is necessary, but
it's still worth considering.

We get can compilers going rapidly, but as above, not sure these
things touch on the OPs query.

 

[Greg Comeau]

I was wondering how long it would take before someone says to use C++.
As it turned out, almost 4 hours.
Of course, you could have gone one step further and suggest ADA.
Oh well... lol ;-)

Are you suggesting that it shouldn't be suggested?
Since C does not directly support many of the conceptual
mappings as directly, mentioning C++ is a reasonable
thing to do.