Path: utzoo!utgpu!attcan!uunet!ncrlnk!ncrcae!ece-csc!mcnc!thorin!retina!coggins
From: coggins@retina.cs.unc.edu (Dr. James Coggins)
Newsgroups: comp.lang.c++
Subject: Re: Managing C++ Libraries: C++ too complex !!
Message-ID: <5217@thorin.cs.unc.edu>
Date: 10 Nov 88 16:01:45 GMT
References: <179@tityus.UUCP>
Sender: news@thorin.cs.unc.edu
Reply-To: coggins@cs.unc.edu (Dr. James Coggins)
Organization: University Of North Carolina, Chapel Hill
Lines: 111

In article <179@tityus.UUCP> jim@athsys.uucp (Jim Becker) writes:
>	I have been reading these articles with some mirth, after
>having dealt with these problems at my current company for the past
>year. I find it all very funny.

Glad you have a sense of humor. If my job depended on a language I was
forced to use but thought was too complex, I could tend to be rather
irritable. (;-)

The idea behind our articles is that there are people out there who
have NOT been working in C++ for a year and who could use any kind of
practical advice they can get on how to organize a development effort.
I would hope that if you have been working for a year on an 800K line
project you would get little out of our series.  In fact, you should
be able to contribute some options and alternatives that haven't
occurred to me.

[C++ has supposedly]
>been designed to "simplify the code development process" and "hide
>complexity".  Our experience has been the exact opposite, as there is
>so much interdependency in the class definition nesting and the
>overloading and the friend functions.... et al.
>	We have a fairly large commercial application written in C++,
>about 800,000 lines. It is all intertwined. 
>We do all the normal things to minimize rereading include
>files, yet some of our singular source files depend on over three
>hundred (300) include files. Please tell me how this can be
>simplified..  :-) :-) 

Library developers create code with dependencies.  That is part of the
essence of the process.  We won't and can't get away from it.
Dependencies will exist in C or in C++.  C++ depends on header files
more than C, so the problems of header file management are encountered
in smaller projects in C++ than in C.  Our articles presented some
approaches to managing these issues that we have found VERY helpful.
We still need to #include lots of headers, but we manage the headers
and includes better so that they take care of themselves and don't
intrude on our real work. 

Header files are incidental. Techniques such as we described can
minimize the headaches of managing them. 
Dependencies are essential; they can't be eliminated using incidental
methods.  In any language. Sorry. (but see below - better design might
decrease dependencies or their complexity!)

>	I don't know of much of the code that can be extracted from
>it's current place and "re-used", as is so widely touted. It all
>depends on itself, and is incestual in nature.

Here I agree.  I have decided that the conventional wisdom regarding
small-granularity code reuse from object-oriented design is probably
wrong. To reuse a piece of code means that you buy the assumptions
underlying the code at the implementation and realization level.
Classes are not equivalent to abstract data types.

The practical solution is to design multiple class hierarchies to fit
the application; i.e. let the implementation fit the abstraction, not
the other way around.  (this is the '80's version of "design from the
top down")

>	If this language is so great, why do we need all these papers
>from PHD level intellectuals telling us how to use it?? 

(This tirade cuts close to home. You are a bit out of line here.)
(and it's "Ph.D.")

> I'm not saying that
>it's the best use of the language, but it is a typical commercial
>application as far as the development team. Not all superstars, but
>trying to make it.
>I believe that
>there is a great deal that can be done without buying into the entire
>C++ methodology, and I do it in vanilla C. 
>I'll stick with the simplier and make it look better and read easier. I
>don't want to hide the logic of what I am coding from the uninitiated
>further down the software timeline..

These passages and your reference to friend functions indicate that
you are using C++ as a "better C" and not using the object-oriented
design paradigm correctly.  Indeed your 800K line project might be
excessively complex due to flawed design.  If somebody is forcing you
to use encapsulation and inheritance because they are there but
without adopting the object-oriented design paradigm, you have a lot
to complain about but it's not C++ that is the problem.

Maybe you could learn something from some Ph.D.'s that would REALLY
help you.

>Is this a language that is great for the super human programmers, and
>one that becomes "write only" after a master has been at work?? Or is
>it a general extension to make the language more flexible and easier
>for a novice to intermediate programmer to create cleaner and more
>well understood code?? How much will a new programmer have to read to
>understand and modify existing code in C++?? Can an average programmer
>write better code, or more confusing and obscure code?? Everyone isn't
>a star coder out there.

Bad design yields bad code in any language, including C++.  C++ gives
you more than enough rope to hang yourself, but it also provides
abstraction mechanisms that make it easier to write and understand
larger systems of code.  Good management techniques can minimize the
incidental problems of managing headers.  Good design minimizes the
essential problems of complex dependencies.

>-Jim Becker
>(C programmer in a land of C++ programmers)
------------------------------------------------------------------------
James M. Coggins, Ph.D. (and proud of it)
Computer Science                      My season basketball tickets
UNC-Chapel Hill                       came yesterday.
coggins@cs.unc.edu