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]

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

 

[Juha Nieminen]

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>

 

[Kenny McCormack]

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.

Two comments:
1) I always associated plaque with dental problems, not
Alzheimer's. Is the Alzheimer's reference about the same as
the dental one?
2) Another term I've used for the problems induced by the OOP
paradigm is "ravioli code". This refers to the fact that
you've got all these "things" lying around, active all the
time, loosely connected, but all clamoring for attention at
the same time. And, in order to track down what is
happening, you often have to look in lots of different
places.

I'm getting hungry. Need some Chef Boyardee...

 

[Roberto Waltman]

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

 

[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]

Go troll somewhere else, Linus Torvalds.

Does Linus Torvalds not like C++?

 

[fnegroni]

Does Linus Torvalds not like C++?

No, he does not

 

[John Bode]

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.

 

[Wolfgang Draxinger]

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

 

[James Kanze]

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

 

[Michael DOUBEZ]

Wolfgang Draxinger a écrit :

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

I don't know about every bit but some of them I, assuredly do want to.
Building an Os does not resume to putting bits to ones and zero, even in
Linux.

Symbian seems a fine os and eCos also; and their core is written in C++.

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++),

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

how
name mangling is performed (dito),

Is it that much a problem ?

calling conventions if
objects are passed by reference (dito).

Do you mean the semantics are harder to identify ?

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.

You mean people that write templates have no control other the code
generated ? Generative programing does not mean you have no control, to
the contrary.

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

When was it, before the standard (CFront) ?

The existence of tools like "moc" of Qt,

How a GUI library come into this ? I don't know if moc is still that
much a necessity; IIRC it mainly set some data for signal management and
that can nowadays be addressed in pure c++. It also adds some properties
(such as class names) that cannot.

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,

This is CORBA and if you have ever worked with linux RPC tools, it is
the same issue (I would say worse).

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.

C++ is harder to parse that is true but I don't see how that relate to
code generated. The purpose of gccxml is more to provide an easy parsing
facility than run into trouble.

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

It is a language with more expression features and thus more traps. How
does this relate to OS ?

 

[James Kanze]

Wolfgang Draxinger a écrit :

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.

[...]

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.

 

[Juha Nieminen]

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/ResponseToTorvalds.html

 

[Juha Nieminen]

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 18, 11:24 pm, Tim Smith <[email protected]>
wrote:

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.

 

[Flash Gordon]

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

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.

 

[peter koch]

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

 

[lawrence.jones]

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.