OT: C vs. C++ (Was: Re: Re: A question on GUIs)

sorry, but these arguments sound masochistic to me. And the mentioned
gtk+ is a perfectly good example to not code an OO toolkit in C. awfully
long function names, no namespaces, casts all over the place. i think
the only valid reason, gtk is done in C, is that at the time it was
started, C++ wasn’t that mature and portable. where is the point in
coding OO, using a language that does not support it, when on the other
hand, there is an OO counterpart of that language?

One can write C code in an OO maner. One does not have to use a
language that enforces OO (or supports, depending on your point of
view) to get many of the benefits of OO. C does everything need to do.
I do not see any advantage in dealing with the extra complexity of C++
if I do not need to.

Roger Sessions’ Class Construction in C and C++: Object-Oriented
Programming Fundamentals

(http://www.amazon.com/gp/product/0136301045/qid=1135427283/sr=1-7/ref=sr_1_7/104-8303903-5795162?s=books&v=glance&n=283155)
was influential to my prrogramming style. Roger teaches about OO using
plain C in the start of the book, and then discusses the limitations
of C when doing this, and how C++ overcomes these limitations. In my
case though, I never run into the limitatins that he describes, and I
find the simplicity of using plain C trumps any advantage I would get
using C++, even for OO programming.

p.s.: hopefully not starting a flamewar here.

Not by me. C++ is fine for anyone who wants to use it. I just have
seen no advantage to it for me. Well other than C++ comments. I love
C++ comments ( // ) over C comments ( /* … *./) . :slight_smile:

I have an example of my OO style on the gameprogrammer wiki at:

http://gameprogrammer.com/gpwiki/Audio_lib

Feel free to critique. I am always open to learning new things,
although this discussion more properly belongs on the gameprogrammer
mailing list.

ChrisOn 12/24/05, Clemens Kirchgatterer <clemens at 1541.org> wrote:


E-Mail: Chris Nystrom
Business: http://www.shaklee.net/austin
Blog: http://conversazione.blogspot.com/
AIM: nystromchris

I use // comments on C all the time. It has been supported since the C99
revision. Other hot new stuff includes:

  • inline functions
  • variables can be declared anywhere (as in C++), rather than only after
    another declaration or the start of a compound statement
  • several new data types, including long long int (to reduce the pain of the
    looming 32-bit to 64-bit transition), an explicit boolean data type, and a
    complex type representing complex numbers
  • variable-length arrays
  • support for one-line comments beginning with //, like in BCPL or C++, and
    which many C compilers have previously supported as an extension
  • several new library functions, such as snprintf()
  • several new header files, such as stdint.h
    (source: http://en.wikipedia.org/wiki/C_language#C99)

I’m not sure how long gcc has been supporting these, but I think it has been
for a few good years now.

Happy xmas,
RicardoEm S?bado, 24 de Dezembro de 2005 12:51, o Chris Nystrom escreveu:

Not by me. C++ is fine for anyone who wants to use it. I just have
seen no advantage to it for me. Well other than C++ comments. I love
C++ comments ( // ) over C comments ( /* … *./) . :slight_smile:


“I was gratified to be able to answer promptly, and I did. I said I
didn’t know.”
– Mark Twain

I’m not sure how long gcc has been supporting these, but I think it has been
for a few good years now.

Offhand, I can say this was since at least as early as '98 (yes, before
the C99 spec even included these things, they were in GCC).On Sat, Dec 24, 2005 at 02:07:05PM +0000, Ricardo Cruz wrote:


Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20051224/77b9893d/attachment.pgp

Chris Nystrom wrote:

I have an example of my OO style on the gameprogrammer wiki at:

http://gameprogrammer.com/gpwiki/Audio_lib

Feel free to critique. I am always open to learning new things,

this audio lib by no means is anywhere near OO, IMHO. i would have
expected you to use a struct to simulate your sound class and function
pointers within this struct to have something like methods operating on
the structs data members. and if you would have done it this way, you
would instantly see the advantage of the C++ syntax as it hides all this
uglyness. instead you just defined PRIVATE as static and use plain C
procedures on an global, preallocated list of sound buffers.

you might argue, that using a struct for your sound objects would have
been more complicated and overkill. you are right - but this shows, that
it just is a rather poor example for OO code in C. look at the glib
object and type models for real OO with C:

http://le-hacker.org/papers/gobject/

i for myself regulary use both C and C++ even in the same project.
its easy: when the problem leads itself to an OO solution i use C++ and
when it’s more of a procedural problem i use C. and if sombody does
not like the one or the other for any reason, ok - may it be.
i just can not see the point in writing explicitly cryptic OO code in a
non OO (supporting) language.

although this discussion more properly belongs on the gameprogrammer
mailing list.

true.

best regards …
clemens

http://www.planetpdf.com/codecuts/pdfs/ooc.pdf

though older… has a very good and extensive example of OO C.

Clemens Kirchgatterer wrote:> Chris Nystrom wrote:

I have an example of my OO style on the gameprogrammer wiki at:

http://gameprogrammer.com/gpwiki/Audio_lib

Feel free to critique. I am always open to learning new things,

this audio lib by no means is anywhere near OO, IMHO. i would have
expected you to use a struct to simulate your sound class and function
pointers within this struct to have something like methods operating on
the structs data members. and if you would have done it this way, you
would instantly see the advantage of the C++ syntax as it hides all this
uglyness. instead you just defined PRIVATE as static and use plain C
procedures on an global, preallocated list of sound buffers.

you might argue, that using a struct for your sound objects would have
been more complicated and overkill. you are right - but this shows, that
it just is a rather poor example for OO code in C. look at the glib
object and type models for real OO with C:

http://le-hacker.org/papers/gobject/

i for myself regulary use both C and C++ even in the same project.
its easy: when the problem leads itself to an OO solution i use C++ and
when it’s more of a procedural problem i use C. and if sombody does
not like the one or the other for any reason, ok - may it be.
i just can not see the point in writing explicitly cryptic OO code in a
non OO (supporting) language.

although this discussion more properly belongs on the gameprogrammer
mailing list.

true.

best regards …
clemens


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

this audio lib by no means is anywhere near OO, IMHO.

I do not claim to be an expert, but I believe you are making OO more
complicated than it is.
Going by http://en.wikipedia.org/wiki/Object-oriented_programming:

“In the most general terms, OOP is the practice of writing program
text decomposed in modules that encapsulate the representation of one
data type per module…”

Basically data + methods = objects (or more accurately classes).

In C you can do this by putting your data in its own source file
(module) and making it static (private), thus encapsulating that data,
and then access the data with public functions (methods). In this way
you have complete control over access to the data. Using this
programming style you can easily create self contained modules that
can easily be taken out and used it in other projects.

i would have
expected you to use a struct to simulate your sound class

I would have used a structure if I believed the data needed a
structure, but structures are not the central to the definition. In
this case it I was encapsulating fairly simple data.

and function
pointers within this struct to have something like methods operating on
the structs data members.

You do not need to use function pointers to create the methods to
access the data. Great if you need them, but not a requirement in my
opinion.

and if you would have done it this way, you
would instantly see the advantage of the C++ syntax as it hides all this
uglyness. instead you just defined PRIVATE as static and use plain C
procedures on an global, preallocated list of sound buffers.

No, this is important. The data is not global. The data is local
(static or private) and can only be accessed via the methods (public
functions). This is the whole point. You create an interface to the
data.

you might argue, that using a struct for your sound objects would have
been more complicated and overkill. you are right - but this shows, that
it just is a rather poor example for OO code in C.

I disagree. See above. I think you might have missed the OO. I believe
you can use OO for simple objects as well complicated ones.

although this discussion more properly belongs on the gameprogrammer
mailing list.

true.

Ok, I copied the gameprogrammer list. Hopefully this discussion moves there.

ChrisOn 12/26/05, Clemens Kirchgatterer <clemens at 1541.org> wrote:


E-Mail: Chris Nystrom
Business: http://www.shaklee.net/austin
Blog: http://conversazione.blogspot.com/
AIM: nystromchris

Chris Nystrom wrote:

this audio lib by no means is anywhere near OO, IMHO.

I do not claim to be an expert, but I believe you are making OO more
complicated than it is.

then our disagreement just comes from two fundamently different
definitions of OOP.

“In the most general terms, OOP is the practice of writing program
text decomposed in modules that encapsulate the representation of one
data type per module…”

Basically data + methods = objects (or more accurately classes).

In C you can do this by putting your data in its own source file
(module) and making it static (private), thus encapsulating that data,
and then access the data with public functions (methods). In this way
you have complete control over access to the data. Using this
programming style you can easily create self contained modules that
can easily be taken out and used it in other projects.

i call this “good C coding practice”. and if you define OOP this way
even K&R is a book about OO programming.

IMHO, your view lacks two major features of OO: Inheritance and
Polymorphism. try to implement those in C, it’s a PITA.

but i can see your point, i can not agree though.

although this discussion more properly belongs on the
gameprogrammer mailing list.

true.

Ok, I copied the gameprogrammer list. Hopefully this discussion moves
there.

not with me, i’m subscribed to too many lists already and i think we
both made our points clear. respond via PM, if you like.

best regards …
clemens> On 12/26/05, Clemens Kirchgatterer <@Clemens_Kirchgattere> wrote: