C++ equivalent to spaghetti code

[Campy Happer]

Hello all,

I would like to bring to your attention a concept
and a term for it that I think is long overdue.

But first: In the bad old days of programming,
before subroutines were even available,
people used to write "spaghetti code", which
was an unreadable, unmaintainable mess of
"goto" statements.

With the increased availability of more
languages such as Pascal and C, and the
focus in programming courses on the importance
of modularity and abstract data types,
one might have thought that the days of
commonplace incomprehensible code were over,
or at least that the worst case scenario
in average code was improved.

In the case of C++, this is not so.
C++, with its multiple inheritance,
templates, and vastly bloated class libraries
such as STL and Boost, which permit and
seem even to require illegible coding practices
in which 5-deep derived classes are not
unlikely, has led to the C++ equivalent
of spaghetti code.

But how to describe it? Commonly people
simply call it "bad coding practices" but this
is too general. It's like calling a traffic accident
"bad driving practices". What then is the
term for an "accident" in C++? To describe this
build-up of tangled incomprehensible bloat,
I shall propose a new term:
C++ plaque.

It is similar to the plaque build-up in
Alzheimer's insofar as it impairs memory,
makes the programmer confused about
what is located where and what day it is.
In addition, when C++ plaque accumulates,
it decreases the programmer's ability
to function in his/her daily work life, ergo
anything (s)he produces will be much more
likely to crash, e.g. KDE.

Fight code pollution by not polluting.

C++ plaque: The cure is within you.

Thank you for your attention.

[Keith Thompson]

Campy Happer <ca*********@yahoo.comwrites:

Hello all,

I would like to bring to your attention a concept
and a term for it that I think is long overdue.

[snip]

I would like to bring to your attention the fact that C and C++ are
two different languages. This may be appropriate in comp.lang.c++;
it's not appropriate in comp.lang.c or gnu.misc.discuss. Please
restrict any followups to comp.lang.c++. (I doubt that this will do
any good, but it's worth a try.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Juha Nieminen]

Campy Happer wrote:

In the case of C++, this is not so.
C++, with its multiple inheritance,
templates, and vastly bloated class libraries
such as STL and Boost, which permit and
seem even to require illegible coding practices
in which 5-deep derived classes are not
unlikely, has led to the C++ equivalent
of spaghetti code.

Go troll somewhere else, Linus Torvalds.

[Lionel B]

On Tue, 15 Jul 2008 08:03:29 -0700, Campy Happer wrote:

<some nonsense>

Can we phuleeeze not feed the troll.

<plonk>

--
Lionel B

[Roberto Waltman]

Campy Happer <ca*********@yahoo.comwrote:
.... In the bad old days of programming,

>before subroutines were even available,
people used to write "spaghetti code", which
was an unreadable, unmaintainable mess of
"goto" statements.
...
C++, with its multiple inheritance,
templates, and vastly bloated class libraries
such as STL and Boost, which permit and
seem even to require illegible coding practices
in which 5-deep derived classes are not
unlikely, has led to the C++ equivalent
of spaghetti code.

But how to describe it?

In the one and only true way. The object-oriented version of
"Spaghetti code" is, of course, "Lasagna code". (Too many layers.)

I have used that expression for years, but so far failed to obtain ISO
certification for it, or have it included in Webster's dictionary...

It goes without saying that any good chef can cook both Spaghetti and
Lasagna codes in either C or C++. (If using the later I would
recommend inheriting from the Pasta abstract base class.)
--
Roberto Waltman

[ Please reply to the group,
return address is invalid ]

[Gernot Frisch]

Can we phuleeeze not feed the troll.

Imagine a troll post and no responses for a week. I think he's gonna
explode.

[s0suk3]

On Jul 15, 10:24 am, Juha Nieminen <[e-mail]:

Campy Happer wrote:

In the case of C++, this is not so.
C++, with its multiple inheritance,
templates, and vastly bloated class libraries
such as STL and Boost, which permit and
seem even to require illegible coding practices
in which 5-deep derived classes are not
unlikely, has led to the C++ equivalent
of spaghetti code.

Go troll somewhere else, Linus Torvalds.

Does Linus Torvalds not like C++?

[fnegroni]

On Jul 17, 7:22*am, [e-mail] wrote:

On Jul 15, 10:24 am, Juha Nieminen <[e-mail]:

Campy Happer wrote:

In the case of C++, this is not so.
C++, with its multiple inheritance,
templates, and vastly bloated class libraries
such as STL and Boost, which permit and
seem even to require illegible coding practices
in which 5-deep derived classes are not
unlikely, has led to the C++ equivalent
of spaghetti code.

* Go troll somewhere else, Linus Torvalds.

Does Linus Torvalds not like C++?

No, he does not :-)

[John Bode]

On Jul 15, 11:16 am, [e-mail] (Kenny McCormack)
wrote:

In article <[e-mail]>,
Campy Happer <[e-mail]:
...

I shall propose a new term:

C++ plaque.

[snip]

1) I always associated plaque with dental problems, not
Alzheimer's. Is the Alzheimer's reference about the same as
the dental one?

Sort of. It refers to the buildup of amyloid plaques (sheets of
protein, IIUC) in the brain tissue of Alzheimer's sufferers. I think
this is closer to the meaning the OP is going for.

[Malcolm McLean]

"John Bode" <jf********@gmail.comwrote in message

>
Sort of. It refers to the buildup of amyloid plaques (sheets of
protein, IIUC) in the brain tissue of Alzheimer's sufferers. I think
this is closer to the meaning the OP is going for.

If you are interested in computer models of amyloid, see my website. It's
the major focus of my work.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Wolfgang Draxinger]

fnegroni wrote:

>Does Linus Torvalds not like C++?

No, he does not :-)

Well, I know only the comments Linus Torvalds made about the
implications of using C++ to develop a kernel. And I totally
agree with him in his statements. Programming a kernel you want
to control every bit of the program (yes I know, that this
sentence can be interpreted in many ways, and each way totaly
matches what I mean).

A languages like C++, that hides (some) vital aspects of the
underlying mechanisms can break things at such a low level
application. I'm thinking mainly about the way, polymorphism is
implemented (there's no standard about that in current C++), how
name mangling is performed (dito), calling conventions if
objects are passed by reference (dito). Another problem is, that
the use of some C++ features (I'm looking at templates here)
will start a chain reaction in which code is created generically
w/o having any influence on the exact outcome. This is not the
same like using macros to create a similair effect; doing it
with a macro one must exactly know what's going on.

IMHO C++ was once a fine language, but it took some problematic
turns. The existence of tools like "moc" of Qt, a own, not fully
standardized interface description language (IDL) to be
translated in a set of abstract interface classes and from those
derived implementation classes, not to forget gccxml to give the
guy who want's some too to process C++ without getting into a
lof of trouble are symptoms for this. I dunno, but I got a row
of programming language books in my shelf and "The C++
programming language" by Stroustroup is easly the thickest. It
even beats "Modern Compiler Design" and goes equal with Volume 2
and 3 of "The Art of Computer Programming".

Wolfgang Draxinger
--
E-Mail address works, Jabber: he******@jabber.org, ICQ: 134682867

[James Kanze]

On Jul 18, 1:31 am, Wolfgang Draxinger <[e-mail]>
wrote:

fnegroni wrote:

Does Linus Torvalds not like C++?

No, he does not :-)

Well, I know only the comments Linus Torvalds made about the
implications of using C++ to develop a kernel. And I totally
agree with him in his statements. Programming a kernel you want
to control every bit of the program (yes I know, that this
sentence can be interpreted in many ways, and each way totaly
matches what I mean).

C++ only hides what you want it to hide. The old Chorus OS was
written entirely in C++, and presumably, significant parts of it
have migrated into the current versions of Solaris, which would
mean that significant parts of Solaris are written in C++.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 18, 9:27 am, Michael DOUBEZ <[e-mail]:

Wolfgang Draxinger a écrit :

fnegroni wrote:

Polymorphism is only one aspect and one you can easily avoid
especially for something as simple as a driver.

Actually, drivers are, by their very nature, polymorphic, and if
you don't use an abstract base class and derive from it, you
have to implement by hand what the compiler does.

[...]

IMHO C++ was once a fine language, but it took some problematic
turns.

When was it, before the standard (CFront) ?

Back in the good ole days (which, of course, weren't so good
when we were actually living them).

For the rest, of course, there are places in an OS kernel where
you would want to restrict the use of certain C++ features---an
exception which tries to propagate back through your context
switch routine isn't likely to work very well. But off hand,
exceptions are about the only C++ feature I see which would
cause problems (and then only in specific contexts---which
represent less than 10% of the OS). And C++ gives you a lot
more safety than C, even when used as a "better C". I can see a
lot of OS's sticking with C because that's what they were
originally written in, and they're not undergoing active enough
evolution to warrent porting to C++, but other than that, it
would be foolish and irresponsible not to take advantages of the
extra safety C++ provides.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Juha Nieminen]

Wolfgang Draxinger wrote:

fnegroni wrote:

>>Does Linus Torvalds not like C++?

No, he does not :-)

Well, I know only the comments Linus Torvalds made about the
implications of using C++ to develop a kernel. And I totally
agree with him in his statements.

His statements are not limited to the Linux kernel, and they are
completely irrational at times. For example, he states that C++ leads to
bad programming practices because of all the "high level stuff" (such as
abstraction, data hiding, etc), while C leads to good programming
practices precisely because it's so low-level. He also states that
programming in the C++ way leads to inefficient code, while programming
in C leads automatically to efficient code. Anyone who even considers
using things like std::string don't understand anything about efficiency
and low-level issues.

I have actually written an open letter to him about a really shameful
flamewar he participated in, regarding this subject.
http://warp.povusers.org/OpenLetters...oTorvalds.html

[Tim Smith]

In article <4c************@darkstargames.dnsalias.net>,
Wolfgang Draxinger <wd********@darkstargames.dewrote:

Well, I know only the comments Linus Torvalds made about the
implications of using C++ to develop a kernel. And I totally
agree with him in his statements. Programming a kernel you want
to control every bit of the program (yes I know, that this
sentence can be interpreted in many ways, and each way totaly
matches what I mean).

A languages like C++, that hides (some) vital aspects of the
underlying mechanisms can break things at such a low level
application. I'm thinking mainly about the way, polymorphism is
implemented (there's no standard about that in current C++), how
name mangling is performed (dito), calling conventions if
objects are passed by reference (dito). Another problem is, that
the use of some C++ features (I'm looking at templates here)
will start a chain reaction in which code is created generically
w/o having any influence on the exact outcome. This is not the
same like using macros to create a similair effect; doing it
with a macro one must exactly know what's going on.

I have yet to encounter a C++ compiler that will refuse to compile a
program if it does not use polymorphism, passing objects by reference,
and templates. There is nothing forcing someone who writes a kernel in
C++ to do those (possibly) questionable things.

--
--Tim Smith

[terminator]

On Jul 18, 11:24*pm, Tim Smith <[e-mail]>
wrote:

In article <[e-mail]>,
*Wolfgang Draxinger <[e-mail]:

Well, I know only the comments Linus Torvalds made about the
implications of using C++ to develop a kernel. And I totally
agree with him in his statements. Programming a kernel you want
to control every bit of the program (yes I know, that this
sentence can be interpreted in many ways, and each way totaly
matches what I mean).

A languages like C++, that hides (some) vital aspects of the
underlying mechanisms can break things at such a low level
application. I'm thinking mainly about the way, polymorphism is
implemented (there's no standard about that in current C++), how
name mangling is performed (dito), calling conventions if
objects are passed by reference (dito). Another problem is, that
the use of some C++ features (I'm looking at templates here)
will start a chain reaction in which code is created generically
w/o having any influence on the exact outcome. This is not the
same like using macros to create a similair effect; doing it
with a macro one must exactly know what's going on.

I have yet to encounter a C++ compiler that will refuse to compile a
program if it does not use polymorphism, passing objects by reference,
and templates. *There is nothing forcing someone who writes a kernel in
C++ to do those (possibly) questionable things.

--

you can call it C++ code but without them you are just codding in C
and the trouble is that many high level featuers do not always suit to
kernel programming ,on the other hand C++ is not high level enough for
some tasks such as web programming,multithreading ...
In short words today`s C++ cannot be considered as general purpose as
C used to be in good old days.
Q:Is there any alternative?(I mean a true ** modern general purpose
flexible** language with **suitable for mixed-level programming**)?

regards,
FM.

[Juha Nieminen]

terminator wrote:

Q:Is there any alternative?(I mean a true ** modern general purpose
flexible** language with **suitable for mixed-level programming**)?

If I'm not mistaken Ada was intended to be one, but it never got
widely popular.

[James Kanze]

On Jul 19, 11:25 am, terminator <[e-mail]:

On Jul 18, 11:24 pm, Tim Smith <[e-mail]>
wrote:

In article <[e-mail]>,
Wolfgang Draxinger <[e-mail]:

Well, I know only the comments Linus Torvalds made about the
implications of using C++ to develop a kernel. And I totally
agree with him in his statements. Programming a kernel you want
to control every bit of the program (yes I know, that this
sentence can be interpreted in many ways, and each way totaly
matches what I mean).

A languages like C++, that hides (some) vital aspects of the
underlying mechanisms can break things at such a low level
application. I'm thinking mainly about the way, polymorphism is
implemented (there's no standard about that in current C++), how
name mangling is performed (dito), calling conventions if
objects are passed by reference (dito). Another problem is, that
the use of some C++ features (I'm looking at templates here)
will start a chain reaction in which code is created generically
w/o having any influence on the exact outcome. This is not the
same like using macros to create a similair effect; doing it
with a macro one must exactly know what's going on.

I have yet to encounter a C++ compiler that will refuse to compile a
program if it does not use polymorphism, passing objects by reference,
and templates. There is nothing forcing someone who writes a kernel in
C++ to do those (possibly) questionable things.

Anyone who codes a kernel without using polymorphism just has to
reimplement it by hand. Ditto passing objects by reference.
And I fail to see any problem with templates, although given
that most of the data structures in a kernel are very
customized, they'll probably be used less than in the
intermediate layers.

you can call it C++ code but without them you are just codding in C
and the trouble is that many high level featuers do not always suit to
kernel programming,

Some (like exceptions) don't, but most do.

on the other hand C++ is not high level enough for
some tasks such as web programming,multithreading ...

Funny, I use it for that, with no problem. (Well, I'm not sure
what you consider web programming, but Firefox is written mainly
in C++. But maybe you don't consider that web programming.)

In short words today`s C++ cannot be considered as general
purpose as C used to be in good old days.

C was never really a good general purpose language. It was
never used (nor even usable) in commercial software, for
example.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Flash Gordon]

James Kanze wrote, On 20/07/08 09:23:

On Jul 19, 11:25 am, terminator <[e-mail]:

<snip>

>In short words today`s C++ cannot be considered as general
purpose as C used to be in good old days.

C was never really a good general purpose language. It was
never used (nor even usable) in commercial software, for
example.

The company I currently work for was initially built on selling SW
written in C to large UK corporations. We still do a lot of business
with that old SW which is still mostly written in C.
--
Flash Gordon

[Richard Heathfield]

James Kanze said:

<snip>

C was never really a good general purpose language. It was
never used (nor even usable) in commercial software, for
example.

So MS Windows is not commercial software? Interesting.

(Early versions of MS Windows were written almost entirely in C.)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[peter koch]

On 20 Jul., 10:23, James Kanze <[e-mail]:

On Jul 19, 11:25 am, terminator <[e-mail]:

C was never really a good general purpose language. *It was
never used (nor even usable) in commercial software, for
example.

This is not correct. My guess would be that there is loads of C-based
software around. Speaking for myself, I have been developing
commercial software in C from the days before C++ became popular. The
software was a financial package which is still today very
successfull.
I was one of the programmers evaluating C++ as a replacement and even
though I liked it very much, I had to reject it: we programmed for a
segmented architecture (yes - it was so long ago!), and the current C+
+ compilers we found did not have sufficiently good support for that.
Had the compiler given us suficient support for the architecture, I
would certainly have recommended C++.
Also many of the database-products out there (e.g. Oracle) are written
mostly or entirely in C.

/Peter

[Richard Heathfield]

[followups set to clc]

peter koch said:

<snip>

My guess would be that there is loads of C-based
software around. Speaking for myself, I have been developing
commercial software in C from the days before C++ became popular. The
software was a financial package which is still today very
successfull.
I was one of the programmers evaluating C++ as a replacement and even
though I liked it very much, I had to reject it: we programmed for a
segmented architecture (yes - it was so long ago!), and the current C+
+ compilers we found did not have sufficiently good support for that.
Had the compiler given us suficient support for the architecture, I
would certainly have recommended C++.
Also many of the database-products out there (e.g. Oracle) are written
mostly or entirely in C.

Re-post (as far as I'm aware, I first posted this back in 2006):

An Oracle programmer (a very good one, I hasten to add) once told me of a
chap who came to his place of work in the early 1990s, attempting to
persuade them to convert from C to C++. The poor chap spent an hour or so
presenting an object-oriented database methodology to the Oracle guys. He'd
obviously worked very hard on it. As he was winding up his presentation and
heading rapidly towards "are there any questions?", he suddenly noticed
that just about everybody in the room was regarding him with utter
astonishment. He panicked, and said "What's the matter? Have I got
something wrong?" Came the reply, "No, no, maybe one or two bits could be
improved here or there... it's broadly okay though... but - we did all this
*years* ago! And you want us to write it *again*?"

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[David Kastrup]

Richard Heathfield <rj*@see.sig.invalidwrites:

James Kanze said:

<snip>

>C was never really a good general purpose language. It was
never used (nor even usable) in commercial software, for
example.

So MS Windows is not commercial software? Interesting.

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

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[lawrence.jones]

Alf P. Steinbach <al***@start.nowrote:

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

All of my company's major commercial applications are written
predominantly in C, including one that's completely object oriented
but predates C++ by about a decade.
--
Larry Jones

These child psychology books we bought were such a waste of money.
-- Calvin's Mom

[Lorenzo Villari]

"James Kanze" <ja*********@gmail.comha scritto nel messaggio
news:01**********************************@b1g2000h sg.googlegroups.com...

Funny, I use it for that, with no problem. (Well, I'm not sure
what you consider web programming, but Firefox is written mainly
in C++. But maybe you don't consider that web programming.)

I'm maybe wrong, but I was under the impression that for Firefox they use
gtk+, which is written in C...

[James Kanze]

On Jul 20, 10:50 am, "Alf P. Steinbach" <[e-mail]:

* James Kanze:

C was never really a good general purpose language. It was
never used (nor even usable) in commercial software, for
example.

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 (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Sherman Pendley]

"Lorenzo Villari" <vl****@alice.itwrites:

I'm maybe wrong, but I was under the impression that for Firefox they use
gtk+, which is written in C...

Gtk+ is indeed written in C, but it's object-oriented and has bindings
for a number of languages, including C++.

sherm--

--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net

[James Kanze]

On Jul 20, 1:51 pm, Richard Heathfield <[e-mail]:

James Kanze said:

<snip>

C was never really a good general purpose language. It was
never used (nor even usable) in commercial software, for
example.

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

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[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

[Richard Heathfield]

[followups set to clc]

James Kanze said:

<snip>

You can't really do accounting in C, for example,

Really? How strange. I've done loads of accounting in C. (But then I've
always been good at doing the impossible.)

because it has neither a
built in decimal type (like Cobol), nor operator overloading on
user defined types (like C++).

You don't need either of those to do accounting.

More generally, C is pretty bad for text handling as well.

It's easily good enough, given that just about the first thing most people
do in C is start work on their text-handling libraries.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[peter koch]

On 20 Jul., 21:59, James Kanze <[e-mail]:

On Jul 20, 10:50 am, "Alf P. Steinbach" <[e-mail]:

* James Kanze:

C was never really a good general purpose language. *It was
never used (nor even usable) in commercial software, for
example.

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

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

[Wolfgang Draxinger]

Sherman Pendley wrote:

"Lorenzo Villari" <vl****@alice.itwrites:

>I'm maybe wrong, but I was under the impression that for
Firefox they use gtk+, which is written in C...

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
--
E-Mail address works, Jabber: he******@jabber.org, ICQ: 134682867

[David Kastrup]

Wolfgang Draxinger <wd********@darkstargames.dewrites:

Sherman Pendley wrote:

>"Lorenzo Villari" <vl****@alice.itwrites:

>>I'm maybe wrong, but I was under the impression that for
Firefox they use gtk+, which is written in C...

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

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.

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[fnegroni]

On Jul 20, 10:15*pm, Wolfgang Draxinger <[e-mail]>
wrote:

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.

[lawrence.jones]

Willem <wi****@stack.nlwrote:

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

Hello, local Navy recruitment office? Yes, this is an emergency... -- Calvin

[Willem]

la************@siemens.com 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

[Richard Heathfield]

la************@siemens.com said:

Willem <wi****@stack.nlwrote:

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

Whether you have interpreted him correctly is not for me to say, but what I
am in a position to say is that I've written plenty of "BDP" applications
in C, and I found it a very suitable language for the purpose. That is not
to say that there are no other such languages, of course, but it's one of
the better ones. I've used quite a few languages for "BDP", and I'd rank C
in the top two of those few. Whether I'd place it first or second is a
tough call. (C++ ranks a close third in my estimation.)

But I still suspect
that there are at least a few BDP applications written in C nonetheless.

Loads. Absolutely loads.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Wolfgang Draxinger]

David Kastrup wrote:

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
--
E-Mail address works, Jabber: he******@jabber.org, ICQ: 134682867

[Richard Harter]

On Mon, 21 Jul 2008 20:34:02 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>la************@siemens.com said:

>Willem <wi****@stack.nlwrote:

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

Whether you have interpreted him correctly is not for me to say, but what I
am in a position to say is that I've written plenty of "BDP" applications
in C, and I found it a very suitable language for the purpose. That is not
to say that there are no other such languages, of course, but it's one of
the better ones. I've used quite a few languages for "BDP", and I'd rank C
in the top two of those few. Whether I'd place it first or second is a
tough call. (C++ ranks a close third in my estimation.)

But, Richard, you place C first or second in all applications.
:-)

>

>But I still suspect
that there are at least a few BDP applications written in C nonetheless.

Loads. Absolutely loads.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Richard Harter, cr*@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.

[s0suk3]

On Jul 21, 3:53 am, fnegroni <[e-mail]:

On Jul 20, 10:15 pm, Wolfgang Draxinger <[e-mail]>
wrote:

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.

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

[Pete Becker]

On 2008-07-23 03:42:29 -0400, James Kanze <ja*********@gmail.comsaid:

On Jul 22, 7:21 pm, Ben Pfaff <[e-mail]:

>James Kanze <[e-mail]:

>>C doesn't have any support for decimal arithmetic, nor any means
of adding it comfortably.

>http://www.open-std.org/jtc1/sc22/open/n4060.pdf

Yes, I'd heard about this. But I wasn't too sure of its status,
and it isn't implemented by the compilers I regularly use.

C and C++ both have TR's for decimal floating-point in the works. They
were paused, waiting for IEEE-754R, a revision to IEEE-754 that
includes decimal floating-point, to be completed. That happened a month
or so ago, and now both TR's are moving forward.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)