marks@agcsun.UUCP (Mark Shepherd) (07/11/90)
I would like to find out if anyone out there has real-life, long-term
experience with a substantial (tens/hundreds K lines of code) project
written in C++. Here are some things I'd like to know:
- how long does it take an C or Pascal programmer to learn and
become productive in object-oriented design and programming
- how long does it take to develop something in C++ compared to C
- how good is the long-term extendability, reliability, maintainability
of object-oriented designs/implementations
- what are the pros/cons of doing a project in C++ rather than C
- what are the pitfalls of doing something in C++
- is C++ particularly well suited (or badly suited) to
- graphic user interfaces (X/Motif)
- real time device control
I am already a big fan of object-oriented analysis, design, and
implementation, and have used C++ and Smalltalk for numerous small
(1-person) projects, but I don't yet have a feel for how well a large
project in C++ works, or whether the theoretical benefits - reusability,
modularity, loose-coupling, data hiding, and so on - actually materialize
in practice.
I'd like to hear (either via E-mail or reply posting) about any
experience you've had, or about any articles or papers you know about
that discuss this.
Thanks
Mark Shepherd
303-279-1300 x288 (voice)
303-279-2209 (fax) agcsun!marks@boulder.colorado.edupkaikini@brahma.rtp.dg.com (Prasan Kaikini) (07/14/90)
In article <812@agcsun.UUCP>, marks@agcsun.UUCP (Mark Shepherd) writes: |> I would like to find out if anyone out there has real-life, long-term |> experience with a substantial (tens/hundreds K lines of code) project |> written in C++. I worked for almost a year in a startup (translates to 2 years in a normal company :-)) on a network management product done completely in C++ (ATT2.0). There were 3 main groups: the UI/X/Motif group had about 4 people, the Object Manager/Database group had about 3 people (including me), and the Comm group had 2 people. When the project was started, each of us had about 3-4 years of experience in C, and we had all read Stroustrup's C++ book. When I left, I think the OM group had written somewhere around 100,000 lines of C++ code. From what i remember, the UI code was as large, if not larger, and the Comm code was probably about 50,000. These numbers are just informed guesses, but it was an enormous amount of code. |> Here are some things I'd like to know: |> |> - how long does it take an C or Pascal programmer to learn and |> become productive in object-oriented design and programming I think the main difficulty was the switch in the thought process from a procedural to an object-oriented paradigm. Once that mental switch was made, it was fairly simple to program in C++. I think it took about 2 months for us pioneers to make that switch. Basically, we learned from each other - we didn't even have access to the net to ask questions! People who joined the project later seemed to be able to make the switch somewhat faster. |> - how long does it take to develop something in C++ compared to C I'll skip this one - too many variables to make a fair comparison. |> - how good is the long-term extendability, reliability, maintainability |> of object-oriented designs/implementations Extendablity: excellent!! Our product depended heavily on the extendabilty afforded by C++. Essentially, we provided a platform for a network management station, and if a network manager wanted the system to manage a new device (one that our system didn't know anything about), all that he/she had to do was plug in a description of the device into the system. Any extra management functions needed by the new device could also as easily be plugged in. (We had a poor man's dynamic linker.) Maintainabilty: very good! Data encapsulation made the code extremely modular, and bug-fixing was simple. However, lots of thought needs to go into designing your basic class hierarchy. We went thru a couple of revisions. I'm not sure if that was due to lack of experience with C++ or with network management! Reliability: don't know. While testing of C software, itself seems to be a hopeless task, nobody seems to have a clue of how to go about testing C++ software! |> - what are the pros/cons of doing a project in C++ rather than C Pros: True data abstraction and encapsulation, inheritance especially multiple, polymorphism, and lots of other small details. Cons: None - other than the learning involved! |> - what are the pitfalls of doing something in C++ Designing the basic class hierarchy - if you haven't done it well, you'll realize soon enough and redesign it. Other minor ones which i need more time to recollect! |> - is C++ particularly well suited (or badly suited) to |> - graphic user interfaces (X/Motif) |> - real time device control Sorry, no experience with either. I'm now back to programming in C, and it feels like going from C to assembler! I can't imagine how I could have ever liked such a language (C)!! Hope that helps. If you need any more details, please email. Prasan
marks@agcsun.UUCP (Mark Shepherd) (07/15/90)
Hi. I recently posted a request for information from people who had real-life long-term experience with a substantial C++ project. I received replies from five people who have actual project experience (5-10 people, tens to hundred of K lines of code). Here's a compilation of what they said (different paragraphs are from different respondents): - how long does it take an C or Pascal programmer to learn and become productive in object-oriented design and programming Not sure. We had been using Lisp and were pretty rusty in C before we moved to C++. I'd guess not too long to get productive, but you'll need someone with experience to review designs. I expect it takes a year or so before it all really sinks in. We plunged in after a couple of months and did ok, but we have had to go back and revise a lot of things. It takes about 2-3 months to learn C++ if someone knows C (or Pascal). However, it takes about six months to a year to LEARN the paradigm shift to OOP. After 2-3 months, there aren't any more "tricks" or syntax to learn, other people's code is "readable", ... Defining objects, concentrating on WHAT vs HOW, avoiding procedural traps (especially with respect to error recovery), takes considerable time; up to a year. - how long does it take to develop something in C++ compared to C Can't say. If you really need the stuff that C++ provides, it would make a BIG difference. If you don't know what to do with inheritance or virtual member functions, it'll probably slow you down. Once beyond the initial learning cycle, no extra time, but see below [comment on designing with an eye towards re-use]. - how good is the long-term extendability, reliability, maintainability of object-oriented designs/implementations Seems ok so far. Like C, it's really up to you. It's as easy to write a nightmare in C++ as it is in C. If there is a decent library, then OOP designs/implementations tend to have excellent long-term extendability, reliability, and maintainability. I have one design that I have reused for several years, now, and some code that is only re-linked as classes are upgraded. The trick is to concentrate on the analysis and design phases with an eye towards REUSE; i.e., a usefull library. - what are the pros/cons of doing a project in C++ rather than C Definitely use C++ over non-ansi C. Also, if you have people who understand object oriented programming, you'll want to use C++. Since C++ interfaces to C fairly well, you don't give up much to use C++. Compiler and debugger quality and stability has been the major con so far. If you don't have people who understand OO, I wouldn't bother with it. If you're used to using something powerful, like Sabre-C, wait till they come out with Sabre-C++. If you're used to inadequate debuggers that lie to you or simply don't tell you much, you'll feel right at home. If coding in C+ (i.e., traditional programming, not OOP, but using the C++ compiler), the project is usually worse off because of the difficulty in training/readability, ... (programmers tend to get enamored of the cute syntax available and throw it all in :-) - what are the pitfalls of doing something in C++ Executable size explosion. This may go away. Include file saturation--10 line .cc files sometimes require 10K lines of .h. Deluding yourselves that you are doing OOP. Not enough GOOD environments around; e.g., decent SOURCE debuggers, browsers, on-line entity dictionaries, ... [editor's note: Saber-C++ is due to be released late this year. Cross your fingers...] - is C++ particularly well suited (or badly suited) to - graphic user interfaces (X/Motif) Yes, provided you are willing to invest the time and effort to convert the header files to C++ (actually, jointly compatible with C using the #ifdef __cplusplus or separate directory ...) Sure. Look at the rave reviews InterViews gets (IV is a publicly available X library/toolkit). I don't know of a package for Motif though. Everyone hopes that somebody will build it on top of IV. [editor's note: Solbourne has recently introduced a C++ object library that works for either Motif or OpenLook. I can't (yet) comment on how good it is.] - real time device control I have been controlling telephone switches and line interface units with no problems. After all, it is really C that you are using underneath, and C has been used for these purposes quite successfully for years. - other comments ? We have a group doing a project in C++. It seems the C++ crowd cannot seem to get anything completed within schedule. (P.S. Please do not post my response, it would not go over well with my management.) [editor's note: how about if I paraphrase and then leave out your name.] My immediate experience in a project with about 5 programmers is that there is a tendency of people starting out with C++ to try to use the language in ways that are not really object-oriented; ie, they'll just convert all their structures to objects. Another problem is going too gung-ho and making a somewhat obscure object mechanism central to the project, thus slowing it down. The moral is, if most of the group are novices, be very selective about where and how the language extensions are used. On the other hand, there is another project within my company which started out with more OO people and had more time to do education and spec-writing (OOD). This one seems to have gone rather well, last I heard. It was more like 10 people, 100K lines. [The theoretical benefits of C++] are definitely achieved in practice, PROVIDED you have a review of any new classes; i.e., reward reuse!!! Concentrate on the library, and communicate the library. This latter point is where an on-line entity dictionary (even simple hypercard can suffice) really shines. Imagine you need a "car" object. It would be nice to know that there was already an "automobile" object in the library, just waiting to be reused... - any published literature on this subject ? There was a workshop at last year's OOPSLA conference on the use of OOP in commercial environments. While not totally directed at the use of C++, many attendees had experience in using this language. There is a report (~30 pages) which reports what the attendees had to say about thier use of OOP. [editor's note: if you're interested, send me a surface mail address. and I'll ship you a copy, as soon as I get it.] There's an article in the USENIX 1988 C++ Conference C. Berman and R. Gur, "NAPS -- A C++ Project Case Study", pp. 137-152. Another interesting article is in March 1989 Uniforum: E. Flanagan, "Experiences in Using C++ in Large Projects". An article on the impact of C++ and OOP on the maintenance of a system by Dennis Mancl of AT&T Bell Laboratories will appear this November in the IEEE Conference on Software Maintenance. Thanks to all who responded. I hope this compilation is useful to everyone out there. Mark Shepherd agcsun!marks
klimas@astro.pc.ab.com (07/18/90)
In article <812@agcsun.UUCP>, marks@agcsun.UUCP (Mark Shepherd) writes: > I would like to find out if anyone out there has real-life, long-term > experience with a substantial (tens/hundreds K lines of code) project > written in C++. Here are some things I'd like to know: > > - how long does it take an C or Pascal programmer to learn and > become productive in object-oriented design and programming > - how long does it take to develop something in C++ compared to C > - how good is the long-term extendability, reliability, maintainability > of object-oriented designs/implementations > - what are the pros/cons of doing a project in C++ rather than C > - what are the pitfalls of doing something in C++ > - is C++ particularly well suited (or badly suited) to > - graphic user interfaces (X/Motif) > - real time device control > > I am already a big fan of object-oriented analysis, design, and > implementation, and have used C++ and Smalltalk for numerous small > (1-person) projects, but I don't yet have a feel for how well a large > project in C++ works, or whether the theoretical benefits - reusability, > modularity, loose-coupling, data hiding, and so on - actually materialize > in practice. I think that there is a rather unanimous opinion that C++ is a better C in many ways, most noteably through better modularity of code. However there are a number of myths and unrealistic expectations that are being foisted upon C++ for code reuse, productivity, and quality. I believe that there are a number of excellent companies involved in the OOP field that have documented these issues at various OOPSLA sessions. I would suggest getting a hold of someone from one of these companies or look through previous copies of the Journal of Object Oriented Programming for some insights.
jaz@icd.ab.com (Jack A. Zucker) (07/18/90)
Talk to someone at Mentor Graphics. They have written 1.5 million lines of C++ code. -jaz
rlk@telesoft.com (Bob Kitzberger @sation) (07/20/90)
In article <641@dg.dg.com>, pkaikini@brahma.rtp.dg.com (Prasan Kaikini) writes: > In article <812@agcsun.UUCP>, marks@agcsun.UUCP (Mark Shepherd) writes: > |> I would like to find out if anyone out there has real-life, long-term > |> experience with a substantial (tens/hundreds K lines of code) project > |> written in C++. First a comment on testing: > Reliability: don't know. While testing of C software, itself seems to be a > hopeless task, nobody seems to have a clue of how to go about testing C++ > software! Then a claim that there are no cons: > |> - what are the pros/cons of doing a project in C++ rather than C > > Cons: None - other than the learning involved! Surely the ability to test and debug a product are critical facets of software engineering. Staying off of the C++ bandwagon, .Bob. -- Bob Kitzberger Internet : rlk@telesoft.com TeleSoft uucp : ...!ucsd.ucsd.edu!telesoft!rlk 5959 Cornerstone Court West San Diego, CA 92121-9891 "There's too much caffeine in your bloodstream..." (619) 457-2700 x163 -- The Smiths ------------------------------------------------------------------------------
oz@yunexus.yorku.ca (Ozan Yigit) (07/24/90)
In article <222.26a42b7d@astro.pc.ab.com> klimas@astro.pc.ab.com writes: > I think that there is a rather unanimous opinion that C++ is a better > C in many ways, most noteably through better modularity of code. That "unanimous opinion" is not unanimous anywhere outside the C++ newsgroup.
klimas@astro.pc.ab.com (07/31/90)
In article <13038@yunexus.YorkU.CA>, oz@yunexus.yorku.ca (Ozan Yigit) writes: > In article <222.26a42b7d@astro.pc.ab.com> klimas@astro.pc.ab.com writes: > >> I think that there is a rather unanimous opinion that C++ is a better >> C in many ways, most noteably through better modularity of code. > > That "unanimous opinion" is not unanimous anywhere outside the C++ newsgroup. There are a number of problems that result from the misapplication of any language and all of the OOP languages have successes and failures based upon their target applications. The fact that is trying to be conveyed is that developers of large systems using C++ seem to feel that their code is more modular than straight C and hence its a better C. Whether C++ is a better OOP than one of the other languages I am not going to initiate yet another language war, I believe that a process of evolutionary natural selection will resolve the winner much more conclusively than any articulate debate will.
larrym@pi19.pnfi.forestry.ca (Larry Marshall) (08/01/90)
klimas@astro.pc.ab.com writes: > trying to be conveyed is that developers of large systems using > C++ seem to feel that their code is more modular than straight C and > hence its a better C. Whether C++ is a better OOP than > one of the other languages I am not going to initiate yet another > language war, I believe that a process of evolutionary natural > selection will resolve the winner much more conclusively than any > articulate debate will. I'll begin by pointing out that there is no such thing as "evolutionary natural selection". Evolution is an outcome; natural selection is one of the processes that causes it. Since learning C++ is often a struggle because we must start thinking about "things" rather than emphasizing "processes" we need to keep those things straight here (grin). But evolution is not really the reason I'm writing. Rather I'm here to ask about the design struggle. I'm fairly new to C++ and often find myself struggling with the "old ways" while trying to implement the new. This often occurs when I need to do some rather simple task that, by appearances is unique to the situation at hand. I'm wondering if others have run into this problem and do you solve them by writing straight C to solve these problems or is there a better way. An example of this came up the other day. I needed to read a simple text file. Each line needed to be parsed and actions taken elsewhere in the program depending upon what was found. Of course this problem is trivial but it serves as an example. Should I write a class to do this? Should the class be a text file class, a "line" class, a parse class, ... ??? Since the parse is unique (I was looking for two different words) should I build a virtual class and derive something unique to that parse or pass the two words to a more general parse class? Possibly you can see why I'm doing so much head scratching. All of these solutions would require me to write a lot more code than the simple, unique parse function required in ANSI C. That's ok if I end up with something re-usable but I have a hard time "seeing" that in cases like this. Any edification you could give a an old evolutionary biologist who's strugglng to learn this new paradigm would be appreciated. Larry Marshall Petawawa National Forestry Institute Chalk River, Ontario K0J 1J0
rlk@telesoft.com (Bob Kitzberger @sation) (08/02/90)
In article <294.26b56ac2@astro.pc.ab.com>, klimas@astro.pc.ab.com writes: > > Whether C++ is a better OOP than > one of the other languages I am not going to initiate yet another > language war, I believe that a process of evolutionary natural > selection will resolve the winner much more conclusively than any > articulate debate will. "Evolutionary natural selection" won't prove which is better, merely which survives. The two aren't necessarily the same, as non-technical issues often overshadow technical issues. .Bob. -- Bob Kitzberger Internet : rlk@telesoft.com TeleSoft uucp : ...!ucsd.ucsd.edu!telesoft!rlk 5959 Cornerstone Court West San Diego, CA 92121-9891 "There's too much caffeine in your bloodstream..." (619) 457-2700 x163 -- The Smiths ------------------------------------------------------------------------------
klimas@astro.pc.ab.com (08/06/90)
> I'm fairly new to C++ and often find myself struggling with the "old ways" > while trying to implement the new. This often occurs when I need to do some > rather simple task that, by appearances is unique to the situation at hand. > I'm wondering if others have run into this problem and do you solve them by > writing straight C to solve these problems or is there a better way. > > An example of this came up the other day. I needed to read a simple text > file. > Each line needed to be parsed and actions taken elsewhere in the program > depending upon what was found. Of course this problem is trivial but it > serves as an example. Should I write a class to do this? Should the class > be a text file class, a "line" class, a parse class, ... ??? Since the > parse is unique (I was looking for two different words) should I build a > virtual class and derive something unique to that parse or pass the two > words to a more general parse class? Possibly you can see why I'm doing > so much head scratching. All of these solutions would require me to write > a lot more code than the simple, unique parse function required in ANSI C. > That's ok if I end up with something re-usable but I have a hard time > "seeing" that in cases like this. Any edification you could give a an > old evolutionary biologist who's strugglng to learn this new paradigm would > be appreciated. > > Larry Marshall > Petawawa National Forestry Institute > Chalk River, Ontario K0J 1J0 The above phenomena is not unique. The paucity of good stable C++ class libraries has often been cited as one of the difficulties of learning OOPs with C++ and is a prime example of why some institutions are requiring people who want to develop in C++ to first become familiar with OOP via Smalltalk. The Smalltalk class library provides a good library of examples of how the C++ classes might be organized for a particular function. The best C++ programmers I know learned OOP from Smalltalk initially and then transfered their experiences to C++.
dan@dyndata.UUCP (Dan Everhart) (08/07/90)
In article <294.26b56ac2@astro.pc.ab.com> klimas@astro.pc.ab.com writes:
Whether C++ is a better OOP than
one of the other languages I am not going to initiate yet another
language war, I believe that a process of evolutionary natural
selection will resolve the winner much more conclusively than any
articulate debate will.
Eh? Natural selection != Market dynamics. After all, we still have
FORTRAN, COBOL, and the 8086 :-)
Besides, articulate debate (not language wars!) is part of what usenet
is all about.cline@cheetah.ece.clarkson.edu (Marshall Cline) (08/09/90)
In article <350.26bd5757@astro.pc.ab.com> klimas@astro.pc.ab.com writes: >The >Smalltalk class library provides a good library of examples of how the >C++ classes might be organized for a particular function. The best C++ >programmers I know learned OOP from Smalltalk initially and then >transfered their experiences to C++. Unfortunately I must disagree with both statements. [1] ``Smalltalk class library provides good library of exampoles of how the C++ classes might be organized'' The Smalltalk class library was designed for Smalltalk. It is entirely runtime typed (which is appropriate for Smalltalk), uses inheritance as an implementation mechanism sometimes at the expense of type conformance (again, ok for Smalltalk, lousy for C++), and it is a singly rooted tree (necessary for Smalltalk but introducing unconstrained polymorphism into the container classes which weakens or destroys type safety in C++). Although the NIHCL (C++) is a successful product, using it requires pointer coersions (which I believe to be the OOP moral equivalent of a `goto'), and it suffers from some of the above problems as well. For example, it is impossible for anything to `be-a' Set without containing a hash-table (this is another non-issue in Smalltalk where you can totally change the type and/or function of inherited member objects). [2] ``The best C++ programmers I know learned OOP from Smalltalk initially'' I've heard this marketing hype too (from companies that specialize in Smalltalk training). I've found that Smalltalk programmers have just as hard a time adjusting to C++ as do Pascal programmers. Their struggles are entirely different (Smalltalk programmers have to get used to strong typing, for example), but Smalltalk programmers have certain initial concepts which are entirely wrong for C++. The purpose of inheritance in C++ is different than in Smalltalk (C++ provides both private [mechanism_only] inheritance and public inheritance [mechanism + type_conformance]; Smalltalk has only one form [would muddy type-conformance in C++], plus Smalltalk doesn't even require you to inherit mechanism, in the sense that you can change the superclass). ------ Before I step into my flame retardant suit, let me mention that I'm not down on Smalltalk or its library *AT* *ALL*!! I just believe the supposed easy transition from Smalltalk to C++ is a myth. I've recently had to rescue a fairly large C++ project (over 14 million of lines of code in the previous language) from the mentality that you can squeeze Smalltalk methodology into C++. For them (and for anyone programming-in-the-large, I believe), type safety is essential. Marshall Cline -- ============================================================================== Marshall Cline / Asst.Prof / ECE Dept / Clarkson Univ / Potsdam, NY 13676 cline@sun.soe.clarkson.edu / Bitnet:BH0W@CLUTX / uunet!clutx.clarkson.edu!bh0w Voice: 315-268-3868 / Secretary: 315-268-6511 / FAX: 315-268-7600 Career search in progress; ECE faculty; research oriented; will send vita. PS: If your company is interested in on-site C++/OOD training, drop me a line! ==============================================================================
klimas@astro.pc.ab.com (08/10/90)
In article <CLINE.90Aug8165807@cheetah.ece.clarkson.edu>, cline@cheetah.ece.clarkson.edu (Marshall Cline) writes: > Unfortunately I must disagree with both statements. > > [1] ``Smalltalk class library provides good library of exampoles of > how the C++ classes might be organized'' The statement was intended as a suggestion for someone trying to figure out OOPS without any experience in laying out the art of laying out usefull class hierarchies. The NIHCL is not available to most neophyte C++ programmers and as you point out some people disagree as to its appropriateness. Rather than debate the ST class library issue, how about a good list of class libraries a neophyte C++ er should browse to help him understand how to lay out reusable class hierarchies. > [2] ``The best C++ programmers I know learned OOP from Smalltalk initially'' > > I've heard this marketing hype too (from companies that specialize in > Smalltalk training). I'm impressed that you know the same C++ programmers that I do! <GRIN> Seriously, I believe that there is more than a coincidental relationship in this area. Unfortunately it would do little to debate this without some sort of a statistical study to back it up so I'll back off for the sake of note bandwidth! > I just believe the supposed easy transition from Smalltalk to C++ is a myth. I don't believe that anyone ever implied learning C++ was easy once one understood Smalltalk, the intent was to not have to hit the neophytes with the burden of learning OOP simultaneously with learning the syntax of C++. The folks at Carleton University and some product oriented companies have strong opinions in this area. > I've recently had to rescue a > fairly large C++ project (over 14 million of lines of code in the previous > language) from the mentality that you can squeeze Smalltalk methodology into > C++. For them (and for anyone programming-in-the-large, I believe), type > safety is essential. I saw some confidential statistics on a large software project that indicated that strong typing in a rather large (~ 1 million lines of code) caught only 10% of the errors. I believe that this is an area that others' contributions would be very helpfull in sorting out the relevant issues from the noise.
vaughan@mcc.com (Paul Vaughan) (08/10/90)
klimas@astro.pc.ab.com wrote: I saw some confidential statistics on a large software project that indicated that strong typing in a rather large (~ 1 million lines of code) caught only 10% of the errors. I believe that this is an area that others' contributions would be very helpfull in sorting out the relevant issues from the noise. I'd be highly skeptical of this. Type checking catches a lot of errors in a way that gets them fixed immediately. Programmers tend to forget they even made them. It's like leaving out a semi-colon. Most people don't record that as a programming error. They just fix it. Having come from a LISP background, I find that it seemed a lot easier to modify a program in LISP, but that after having done it, bugs associated with the "fix" would keep popping up forever and stringent testing after every change was required to maintain robustness. Type checking totally eliminates most of the errors that would plague us then. On the other hand, there certainly are several categories of frequent errors that type checking doesn't help with. Memory allocation/deallocation misunderstandings come prominently to mind (ah, LISP . . .). Does anyone have any experience, intuition, or statistics concerning the use of const? Does it really help clear up errors or not? It's certainly a bag of worms to get a program const correct--it just ripples and ripples through your code and then you wind up finding a place in some library or system function where something really should have been const but can't be changed and you have to cast around it in the end. So what's the verdict is const worth it? Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639 Box 200195, Austin, TX 78720 | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan
dhoyt@vw.acs.umn.edu (08/11/90)
In article <10329@cadillac.CAD.MCC.COM>, vaughan@mcc.com (Paul Vaughan) writes... >klimas@astro.pc.ab.com wrote: > > I saw some confidential statistics on a large software project that > indicated that strong typing in a rather large (~ 1 million lines of > code) caught only 10% of the errors. Having worked on a several +million line programs (mostly Fortran mixed with about 10% C and 5% assembler). I'd aggree with the statement. But only because the statement is meaningless. A project never gets anywere near a million lines long without lots of testing and billions (okay, lots) of compiles and even more bugs. Putting an 'IMPLICIT NONE' at the top of all those Fortran modules (assuming you didn't use some such method in the first place, unlikely) would catch about 10% of the outstanding bugs. It's in the right order of magnitude anyway <:). Unfortunately it would only find about 5 of the reported bugs... david paul hoyt | dhoyt@vx.acs.umn.edu | dhoyt@umnacvx.bitnet
marick@m.cs.uiuc.edu (08/13/90)
For what it's worth: I've been analysing bugs from the bug newsgroups (for a completely different reason). Of the 79 I've got, 9 could be caught by strict type checking. 6 could have been caught by lint, 1 might have been caught by lint, and 2 would have required subtyping of ints (and that such subtypes actually be used). (In the case of the one that might have been caught by lint, I didn't save enough code to check whether it actually would be caught. It was a case where a new field was added to a struct but the old [partial] initializor wasn't changed. It wouldn't be caught if the shifted initial values happened to be type-compatible with new fields they matched.) Brian Marick Motorola @ University of Illinois marick@cs.uiuc.edu, uiucdcs!marick
johnb@srchtec.UUCP (John Baldwin) (08/13/90)
In article <397.26c19b74@astro.pc.ab.com> klimas@astro.pc.ab.com writes: > ...[omitted]... The NIHCL is not available to most > neophyte C++ programmers ... Without comment on the rest of the discussion thread, I *can* say that the NIH class library is very easily available from Austin Code Works, for $35. That's cheap enough that I wouldn't think twice about buying it for home use, if my employer didn't already have it :-) Although I might not agree with all the design decisions made in the library, it is VERY robust code, aged in hardwood vats (well...), and provides a C++ neophyte with plenty of real working code to read (which, alas, many of the books on the subject don't. I'm not saying which books... :) :) :) :) -- John T. Baldwin | johnb@srchtec.uucp Search Technology, Inc. | johnb%srchtec.uucp@mathcs.emory.edu standard disclaimer: | ...uunet!samsung!emory!stiatl!srchtec.. opinions and mistakes purely my own. | ...mailrus!gatech!stiatl!srchtec...