C++ equivalent to spaghetti code

[David Kastrup]

James Kanze said:



So MS Windows is not commercial software? Interesting.

Last time I looked, UNIX was not particularly uncommercial either.

 

[James Kanze]

* James Kanze:

I'm not sure that statement is valid.

It would be very surprising, to say the least, if no or just a
very few commercial applications were written in C.

There are certainly a few. Way back when, however, the X/Open
group proposed standardizing a form of Cobol (under Unix!)
because C was felt to be unusable for business applications.

At least certain types of business applications require some
sort of decimal type. If the language doesn't have it built in
(as Cobol and PL-1 did), and it doesn't have operator
overloading, expressions quickly become unreadable. For those
applications, at least, if the language doesn't have a built-in
decimal type, and it doesn't have operator overloading, then
it's really unusable for those applications (although you'll
doubtlessly find some masocists doing it).

 

[James Kanze]

James Kanze said:

So MS Windows is not commercial software? Interesting.

Yes. Commercial can be used in several senses (and I'm not sure
of the usual English usage here). There's a lot of software
written in C that is commercial in the sense that it is sold
(i.e. commercial as opposed to free software). What I was
talking about, however, was the application domain. You can't
really do accounting in C, for example, because it has neither a
built in decimal type (like Cobol), nor operator overloading on
user defined types (like C++). More generally, C is pretty bad
for text handling as well.

Of course, a lot of early Unix systems only had C, and between C
and assembler, you used C, even if it wasn't the ideal language
for the job. (Although the old X/Open group did try to
standardize a Cobol dialect for Unix.)

 

[Willem]

James Kanze wrote:
) Yes. Commercial can be used in several senses (and I'm not sure
) of the usual English usage here). There's a lot of software
) written in C that is commercial in the sense that it is sold
) (i.e. commercial as opposed to free software). What I was
) talking about, however, was the application domain. You can't
) really do accounting in C, for example, because it has neither a
) built in decimal type (like Cobol), nor operator overloading on
) user defined types (like C++). More generally, C is pretty bad
) for text handling as well.

In other words: There cannot be any commercial applicaiton written in C,
because in your view it is not well suited to one or two application
types you can think of.

Your argument is fundamentally flawed in two entirely separate, both
equally valid ways.

- That it is not the most well suited does not imply that it is impossible
that commercial software is written in it.
- There are many more commercial application types than the few you
mentioned.


It may be that you're trolling though. It is a very nice blanket statement
you made, one that will rile many people, and with a lot of wiggle room.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Wolfgang Draxinger]

Gtk+ is indeed written in C, but it's object-oriented

And?!

Coding something in C doesn't mean you must abandon using OOP
methods. It just means, that things are going to be a bit more
verbose (i.e. you've to maintain everything yourself).

Wolfgang Draxinger

 

[peter koch]

There are certainly a few.  Way back when, however, the X/Open
group proposed standardizing a form of Cobol (under Unix!)
because C was felt to be unusable for business applications.

At least certain types of business applications require some
sort of decimal type.  If the language doesn't have it built in
(as Cobol and PL-1 did), and it doesn't have operator
overloading, expressions quickly become unreadable.  For those
applications, at least, if the language doesn't have a built-in
decimal type, and it doesn't have operator overloading, then
it's really unusable for those applications (although you'll
doubtlessly find some masocists doing it).

That was the case for "my" financial application. It had decimal-based
arithmetic, and writing expressions in C was
add(multiply(a,b),divide(c,d)) instead of a*b+ c/d. But as a lot of
the high-level code was written in our own, interpreted language
anyway it did not matter so much.

/Peter

 

[David Kastrup]

And?!

Coding something in C doesn't mean you must abandon using OOP
methods. It just means, that things are going to be a bit more
verbose (i.e. you've to maintain everything yourself).

Well, message passing, the fundamental defining characteristic of OOP (I
mean, this is what made Smalltalk revolutionary with regard to
programming techniques and gave it its name) requires you to switch
sustained execution contexts, basically switching to a different stack,
eveery object having its own control flow. Synchronous multithreading
or whatever you want to call it. That's what OO is actually about. The
in-memory and synchronous in-process equivalent to separate applications
with separate control flow talking to one another via pipes.

Of course, C++ does not have it either. When it laid claim to the
buzzphrase OO, its reference implementation Cfront could not map this
aspect to C, and so one implemented and declared a humongous wagonload
of other features to befuddle detractors and turn them away in disgust
before they noticed the missing essential detail.

The Cfront language design inheritage indeed means that for the most
part, you can't do anything in C++ that is not fundamentally accessible
in C.

 

[fnegroni]

Coding something in C doesn't mean you must abandon using OOP
methods. It just means, that things are going to be a bit more
verbose (i.e. you've to maintain everything yourself).

Sorry, but I fail to see how OOP applies to C.

I heard someone give me an example once, which was not OOP.

So I am curious to know what sort of OOP we are talking about here.

If I want to do OOP, I can use C++, Java, Eiffel, Python... certainly
not C.

Doing OOP in C is IMHO silly.

C is best at what it was designed to do, and that was not OOP.

I think a study of Yourdon and Structured Programming might be an
interesting read for those advocating OOP in C.

 

[Chris Thomasson]

Sorry, but I fail to see how OOP applies to C.

I heard someone give me an example once, which was not OOP.

So I am curious to know what sort of OOP we are talking about here.

[...]

Think along the lines of something very simple:

http://groups.google.com/group/comp.lang.c/browse_frm/thread/1b106926ba5db19f

 

[lawrence.jones]

In other words: There cannot be any commercial applicaiton written in C,
because in your view it is not well suited to one or two application
types you can think of.

I don't think that's what James meant. I think when he said "commercial
application", he really meant "business data processing application". C
really *isn't* well suited to most BDP applications, so his statement is
much more reasonable when interpreted that way. But I still suspect
that there are at least a few BDP applications written in C nonetheless.

 

[Willem]

(e-mail address removed) wrote:
) I don't think that's what James meant. I think when he said "commercial
) application", he really meant "business data processing application". C
) really *isn't* well suited to most BDP applications, so his statement is
) much more reasonable when interpreted that way. But I still suspect
) that there are at least a few BDP applications written in C nonetheless.

Just for the record:
I'm a software engineer for a company that does mortgages, and
we have plenty of C software in use that does data processing.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Wolfgang Draxinger]

Well, message passing, the fundamental defining characteristic
of OOP (I mean, this is what made Smalltalk revolutionary with
regard to programming techniques and gave it its name) requires
you to switch sustained execution contexts, basically switching
to a different stack, eveery object having its own control
flow. Synchronous multithreading or whatever you want to call
it. That's what OO is actually about. The in-memory and
synchronous in-process equivalent to separate applications with
separate control flow talking to one another via pipes.

The language I'm currently developing uses C as an intermediate.
And in this language message passing is one of the core
machanisms. And yes, of course message passing is possible, you
just may not implement it in form of simple function calling.

The runtime of my language implements a message dispatcher, that
delivers messages to each object on the reciever list. An object
can decide if it accepts the message and processes it, or if it
passes it on, or accepts and re-yields the message. For example
it is possible to send a message in a way, that it will be
passed up in the hierachy of object instances.

Wolfgang Draxinger

 

[David Kastrup]

The language I'm currently developing uses C as an intermediate.
And in this language message passing is one of the core
machanisms. And yes, of course message passing is possible, you
just may not implement it in form of simple function calling.

The runtime of my language implements a message dispatcher, that
delivers messages to each object on the reciever list. An object
can decide if it accepts the message and processes it, or if it
passes it on, or accepts and re-yields the message. For example
it is possible to send a message in a way, that it will be
passed up in the hierachy of object instances.

If not both the send and yield/accept points can be in the middle of the
usual control flow, this is not message passing. The call mechanism of
C and C++ has only "send" (corresponding by function call) in a location
inside of the normal control flow. "yield/accept" is separated in the
control flow of an object, and the part before the first "accept" of an
object needs to be put into a "constructor" and the part after the last
"yield" into a "destructor", and the "caller" is responsible for causing
the invocation of the "destructor" (leading to all sort of silly scoping
rules) and so on.

It has taken paradigm shifts for computers to get hardware support for a
call stack (anybody remember the return jump instruction from the old
CDC computers? No stack at all!), then small hardware return stacks
(some microcontrollers), not so small external return stacks (256 bytes
on 6502), full-size external return stacks (8080 and similar, ok, I got
my timeline messed up), efficient indexed data storage on stacks (8086
or 68000 or 6809 or...).

Maybe it is time to create hardware support for garbage collection and
multiple compactable call stacks. Call heaps, so to say. Garbage
collection is pretty much central to many object oriented systems and is
central in pretty much any 4th generation language.

I think the time is overripe for processors with hardware-assisted
garbage-collected call heaps and storage (a dedicated rather small part
of the processor can do sweep and collect work whenever the memory
bandwidth allows for it transparently) would support object oriented
control flow, continuations and other concepts essential for getting rid
of the rigid function entry/exit control flow where each object has to
_die_ in order to yield control and be recreated from scratch and
statically stored data whenever it should "resume" (what a stupid word
for starting at the beginning again) working.

Languages like C and C++ _block_ such advances since they require that
programmers have to do all such stuff _manually_ and so processor
support would have to be switched _off_ to accommodate C++.

 

[s0suk3]

Sorry, but I fail to see how OOP applies to C.

I heard someone give me an example once, which was not OOP.

So I am curious to know what sort of OOP we are talking about here.

If I want to do OOP, I can use C++, Java, Eiffel, Python... certainly
not C.

Doing OOP in C is IMHO silly.

Silly, ridiculous, painful... but frequently just necessary.