Re: C++ Envy

[cwarack@picard.usafa.af.mil (Chris Warack <sys mgr>)]

In article <3g4rkd$g07@cronkite.seas.gwu.edu> dobrien@seas.gwu.edu (David O'Brien) writes:
>In article <3fui32$q6g@gnat.cs.nyu.edu> you wrote:
>: David O'Brien says
>
>Ok, I have been mis-understood.  Let me set this up.
>
>A team of us are working on a project.  We have a CM tool.  Assume the
>usual C/C++ tools like make.  Ok, since the Makefile is so important to
>producing our program, it is under CM just like all the rest of our
>source code and headers.  Like any project that is concerned with CM,
>there are "official" builds built by a tech lead, QA, CM, who ever.  The
>Makefile and source code used for these builds come from the CM tool.
>(Correct me if this isn't setup correctly...)
>
>Now, Jim-Bob has written a class and private/protected some member
>function or attribute I want to access directly.  So I decide to use the
>wrapper header suggested, to get around the type protection.
>
>How am I going to compile the beast now?  I have to edit the Makefile so
>that my wrapper header can be added as a dependency to *my* module.  (Or,
>I use scandeps/etc. to automaticly look at the includes and do this
>for me.)
>
>After all this, I am happy with my module.  Time to check it back into
>CM.  This must include my wrapper header, or else the program won't be
>compilable by anyone else (especially the "official" person).  BINGO,
>what do you have???  Traceability!  You know who the fool was, and when
>the change occurred.  The next CM report will tell all.

But, traceability doesn't do anything for you three years later when the
problem would occur -- maintenance changes the rep in the basic abstraction
and your code blows up.  As you point out, where >>your<< code is concerned
the CM system only provides traceability and version control.

>Someone earlier said that you could remove the protections from Ada by
>just editing the source file.  You said that CM protected this from
>happening.  How is that different for C ???

If you aren't supposed to be working on that module, you cannot check it
out.  When its >>Not<< your code, the CM system should require "clearance"
for you to check it out.  In Ada the only way to break the abstraction
is through changing the abstraction's code (or using unchecked conversion*).
In C, that is not true.

*Checking for use of unchecked conversion is extremely easy to automate.
Any module with a dependency on unchecked conversion (a with context clause)
are an inclusive set of the modules using it.  These can be routinely checked
to determine legitimate uses of unchecked conversion (like network comm.) with
illegitimate uses (like the thread discusses).

>:   "From the way you wrote, I'd say you have some hostility toward C++
>:   programmers"
>
>: No, just hostility to programmers who feel they can break the rules whenever
>: they get pissed off :-)
>
>btw, I didn't say *I* wanted to mess around.  I said that rather than
>play all these _games_ to get around the protection, I'd just head
>straight to the source and do it in a [slightly] more legitimized way.
>My being "pissed off" applies to how ridiculous this thread has become
>with "oh, this is _terrible_".

Well, if it never happened, it would be ridiculous... :-/

The bottom line:  In an Ada system with the checks outlined above, if a
programmer wants to change the behavior of an abstraction, they >>have<<
to get the idea through the CM system.  In many other languages, this is
not the case.  If the CM system says no (or the programmer never asks),
they can hack a work-around that would not be noticed until a maintenance
problem occurred.

Caveat:  If the project uses code inspections, then these hacks might be
noticed.  Inspections are a lot more expensive than automation, however.
I'd bet in most critical systems, you'd probably be doing inspections.

Finally, I don't believe cases like this are driven from mischief
either.  If people don't think something (like CM and speed limits) is
important, they tend to ignore it.  It seems that programmers (as a whole)
are more prone to this than other disciplines.

-- 
Christopher A. Warack, Capt, USAF
Computer Science Department, US Air Force Academy

cwarack@kirk.usafa.af.mil                (719) 472-2401