Debugging C vs debugging C++

[jacob navia]

I was browsing the web pages of les haltton, a software engineering
professor ( http://www.leshaltton.org ) and I found this data in

htp://www.leshatton.org/Documents/dross_2006.pdf

< begin quote >
Summary of known measurements
• C++ OO systems have comparable defect densities to conventional C or
Pascal systems.
• Each defect in a C++ OO system takes about twice as long to fix as in
a conventional system.

This is true for both simple defects AND difficult ones. The whole
distribution is right shifted.
• Components using inheritance have been observed to have 6 times the
defect density.

How much of this is attributable to C++ is unknown.

< end quote >

It is obvious that beside the much touted hype, OO systems have
not brought any real improvement to C. The problem is in my
opinion, the staggering complexity of those systems, what
makes debugging thema nightmare unless you wrote them.

jacob

[Spiros Bousbouras]

jacob navia wrote:

I was browsing the web pages of les haltton, a software engineering
professor ( http://www.leshaltton.org ) and I found this data in

It's hatton not hallton. Do you think you could check your
links before posting them or at least afterwards ?

htp://www.leshatton.org/Documents/dross_2006.pdf

< begin quote >
Summary of known measurements
· C++ OO systems have comparable defect densities to conventional C or
Pascal systems.
· Each defect in a C++ OO system takes about twice as long to fix as in
a conventional system.

This is true for both simple defects AND difficult ones. The whole
distribution is right shifted.
· Components using inheritance have been observed to have 6 times the
defect density.

How much of this is attributable to C++ is unknown.

< end quote >

It is obvious that beside the much touted hype, OO systems have
not brought any real improvement to C. The problem is in my
opinion, the staggering complexity of those systems, what
makes debugging thema nightmare unless you wrote them.

This looks like comp.programming to me.

[Spiros Bousbouras]

Spiros Bousbouras wrote:

jacob navia wrote:

I was browsing the web pages of les haltton, a software engineering
professor ( http://www.leshaltton.org ) and I found this data in

It's hatton not hallton. Do you think you could check your
links before posting them or at least afterwards ?

Not haltton either ;-)

[jacob navia]

Sorry the links are:
http://www.leshatton.org/
http://www.leshatton.org/Documents/dross_2006.pdf

[Ancient_Hacker]

jacob navia wrote:

It is obvious that beside the much touted hype, OO systems have
not brought any real improvement to C. The problem is in my
opinion, the staggering complexity of those systems, what
makes debugging them a nightmare unless you wrote them.

jacob

IMHO the whole OO thing is mostly smoke and mirrors. Looked at from a
height, how likely is it the first, (well, about the fourth,) major
refactoring of the coding process is likely to be the final, universal,
and unsullied panacea? Especially when it was grafted onto a
less-than-perfect second try at a system language?

The whole business of abstraction sounds really cool at first glance.
The coolness wears off a bit when you have to work with real code,
which after three or four different minds have layered abstractiuon
upon abstraction, often is so abstract as to be uninterpretable by any
human mind.

I'm thinking in particular of one program, where an experienced
programmer was asked to add just ONE small option. After peering thru
thousands of lines of C++ code, he found it was easier to write a
completely separate function to do the option, just five lines of code,
rather than to try to insert TWO lines of code in the complex abstract
hierarchy.

IMHO giving a huge box of TinkerToys to toddlers does not result in
amazingly robust edifices.

[jacob navia]

Ancient_Hacker wrote:

I'm thinking in particular of one program, where an experienced
programmer was asked to add just ONE small option. After peering thru
thousands of lines of C++ code, he found it was easier to write a
completely separate function to do the option, just five lines of code,
rather than to try to insert TWO lines of code in the complex abstract
hierarchy.

This is exactly the problem any C++ maintainer is facing.
You have to understand the whole hierarchy, layered in several
dozens of files to be able to just modify a small part of it.

Hierarchy can be a good abstraction *sometimes* but the
problem appears when you try to force it to EVERY
situation.

[robertwessel2]

jacob navia wrote:

I was browsing the web pages of les haltton, a software engineering
professor ( http://www.leshaltton.org ) and I found this data in

htp://www.leshatton.org/Documents/dross_2006.pdf

< begin quote >
Summary of known measurements
· C++ OO systems have comparable defect densities to conventional C or
Pascal systems.
· Each defect in a C++ OO system takes about twice as long to fix as in
a conventional system.

This is true for both simple defects AND difficult ones. The whole
distribution is right shifted.
· Components using inheritance have been observed to have 6 times the
defect density.

How much of this is attributable to C++ is unknown.

< end quote >

It is obvious that beside the much touted hype, OO systems have
not brought any real improvement to C. The problem is in my
opinion, the staggering complexity of those systems, what
makes debugging thema nightmare unless you wrote them.

The defect density thing does not surprise me at all. I've seen
similar studies going back decades, looking at many different languages
and programming styles. The defect density in terms of bugs/kloc is
fairly constant from assembler, to Cobol, to Lisp, to C to C++, to
Haskel, to Forth to...

It's also been observed that programmer productivity in klocs/month is
also fairly constant between langauges.

That defects are more difficult to fix in a more complex hierarchy or
structure is also no surprise.

To a large extent, the language that lets you write the smallest
program "wins." To the extent that OO allows larger, more complex,
applications to be built with a given amount of work, it's a win.

OO certainly has is share of excessive hype, but there's a large class
of application for which it is quite well suited. C++, in particular,
is easy to abuse (and even hard to not abuse by accident), even more so
than C. Many of the bugs you see in C++ code you'd *never* see in
Smalltalk (or even C# or Java). Stroustrup himself said that while C
makes it easy to shoot yourself in the foot, C++ lets you blow your
whole leg off.

[websnarf]

jacob navia wrote:

I was browsing the web pages of les haltton, a software engineering
professor ( http://www.leshaltton.org ) and I found this data in

htp://www.leshatton.org/Documents/dross_2006.pdf

< begin quote >
Summary of known measurements
· C++ OO systems have comparable defect densities to conventional C or
Pascal systems.
· Each defect in a C++ OO system takes about twice as long to fix as in
a conventional system.

This is true for both simple defects AND difficult ones. The whole
distribution is right shifted.
· Components using inheritance have been observed to have 6 times the
defect density.

How much of this is attributable to C++ is unknown.

< end quote >

It is obvious that beside the much touted hype, OO systems have
not brought any real improvement to C. The problem is in my
opinion, the staggering complexity of those systems, what
makes debugging thema nightmare unless you wrote them.

I'm the last person in the world to defend C++ over C, however, these
statements are missing some very important considerations.

1) You can accomplish *more* in C++ per line of code. Its not
drastically more, but its definately more. Constructors and
destructors are often called by default, you have exception handling
which means you don't have to write very convoluted clean up code for
successfully backing out of errors, and you have templates which means
algorithms can truly be reused over different types. So in essence
this analysis fails the typical "lines of code" fallacy.

2) The *severity* of defects for the two languages is also very
different. Many of the containers in STL remove the need to use
pointers and "by hand" memory management. So a lot of things like "use
after free", pointing to non-sense, uninitialized pointers, and
ordinary buffer overflows, will tend to be less frequent in C++. The
real problem is that C++ introduces a totally new programming paradigm
which in of itself has built-in potential for errors that raw C doesn't
have. Thus this analysis treats all kinds of errors as if they are the
same as well.

3) C++ is not the only embodiment of OO. Other languages such as Java,
Ruby, Python and Lua have their own notion of OO programming. Its
obvious that in these languages, errors are less severe, the rate of
error production is code is far less, and the productivity per line of
code is also much higher. So I don't think that "OO" is, in
particular, either a culprit or an antagonist to reducing the number of
errors in a program.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Ian Collins]

jacob navia wrote:

I was browsing the web pages of les haltton, a software engineering
professor ( http://www.leshaltton.org ) and I found this data in

htp://www.leshatton.org/Documents/dross_2006.pdf

< begin quote >
Summary of known measurements
• C++ OO systems have comparable defect densities to conventional C or
Pascal systems.
• Each defect in a C++ OO system takes about twice as long to fix as in
a conventional system.

This is true for both simple defects AND difficult ones. The whole
distribution is right shifted.
• Components using inheritance have been observed to have 6 times the
defect density.

How much of this is attributable to C++ is unknown.

< end quote >

It is obvious that beside the much touted hype, OO systems have
not brought any real improvement to C. The problem is in my
opinion, the staggering complexity of those systems, what
makes debugging thema nightmare unless you wrote them.

Unless they have a decent set of unit tests.

<ducks and runs for cover>

--
Ian Collins.

[Ancient_Hacker]

Ian Collins wrote:

Unless they have a decent set of unit tests.

<ducks and runs for cover>

--
Ian Collins.

better duck!

(1) It's rare to see any extensive tests.

(2) If the tests are written by the original coders, they have too
much of a vested interest in not poking at their code too hard. Plus
they know subconciously what not to try.

(3) And of course even a full set of tests, even hundreds, cannot ever
guarantee the absence of errors-- they can only at best point out
errors.

Remember the first space shuttle launch attempt-- even with an
exemplary testing methodology they got egg on their faces really badly.

[CBFalconer]

Ancient_Hacker wrote:

>

.... snip ...

>
(2) If the tests are written by the original coders, they have
too much of a vested interest in not poking at their code too
hard. Plus they know subconciously what not to try.

That is a sad commentary on the coders you have encountered. In my
experience they know where the boundary conditions are, and write
tests to explore those.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Ian Collins]

Ancient_Hacker wrote:

Ian Collins wrote:

>>Unless they have a decent set of unit tests.

<ducks and runs for cover>

better duck!

(1) It's rare to see any extensive tests.

(2) If the tests are written by the original coders, they have too
much of a vested interest in not poking at their code too hard. Plus
they know subconciously what not to try.

<pops head up>
That's why you write the tests first!

--
Ian Collins.