eli@vcvax1.UUCP (eli) (07/07/86)
[ line x; if (!x.eat()) { cout << "No line eater here!\n" ; } ]
The response to my survey was relatively small. I think that there are
two reasons for this. The reasons seem to be:
o Although the language is over 6 years old,
C++ has been commercially available for only about 6 months.
Before that, it was only available to sites within Bell Labs
and to several universities. Thus, many people are still
evaluating the language themselves.
o Another reason that some people are reluctant to enter the
survey is because they feel that C++ gives them a competetive
edge. Natuarally, they are reluctant to announce such a thing
on the net. Bjarne informs me that more than one organization
feels this way.
The final results of the survey follow. I have added comments in some
places. The comments are delimited by '[' and ']' and I have
initialed them. Thus, you know when you are reading a comment from a
survey respondant and when you are hearing me mouth off :-). I hope
that this survey will help all of you who were thinking about C++ to
know some more about the language.
I would like to thank all of the people who responded to the survey.
Your help is most appreciated.
@BEGIN(survey)
=============================================================================
>Date: Sat, 21 Jun 86 17:15:07 EDT
>From: <cybvax0!harvard!caip!ll-xn!seismo!elsie!cecil!keith>
>Subject: Re: C++ Experiences.... (question)
>
>> than C. Have you found any drawbacks in C++? Do
>
>Yes: lack of a symbolic debugger, slow compilation and linking, difficulty
>in learning the language.
>
>> you regret going to C++? Do you swear by it?
>
>Swear by it.
>
>> Can you do things in C++ that C would not allow? Have
>
>Definitely; e.g. guaranteed initialization/de-initialization,
>user-defined implicit type conversion, operator/function overloading,
>references, and consts.
>
>> development/maintenance times/costs dropped substantially?
>
>Can't tell.
>
>> Does it take more time or less time to bring new
>> developers up to speed? Have your maintenance times/costs
>
>More.
>
>> dropped substantially? Do you have any problems with
>> portability (many systems whose compiler don't have flexnames)?
>
>No.
>
>> Do you find that the lack of support from AT&T is
>> a drawback?
>
>A minor drawback.
>
>> Are there known bugs in the C++ compiler?
>
>Yes, but they are not fatally serious.
[ Bjarne tells me that Mr. Gorlen has made quite a number of
contributions to the QC of C++. The points made by him and others
have been addressed in the latest release (1.1). 98% of the bugs
reported in earlier versions have been fixed in 1.1, which is
now available -- EI ]
>---
> Keith Gorlen
> Building 12A, Room 2017
> Computer Systems Laboratory
> Division of Computer Research and Technology
> National Institutes of Health
> Bethesda, MD 20892
> phone: (301) 496-5363
> uucp: {decvax!}seismo!elsie!cecil!keith
>
=============================================================================
>Date: Fri, 27 Jun 86 19:37:59 edt
>From: cybvax0!harvard!research!grigg!ark
>
>Here's another response to your netnews query.
>
>I'm a colleague of Bjarne's. I recently decided to
>bite the bullet and learn C++ after several years of
>procrastination. I've written about 1,800 lines of
>code in it so far, mostly concerned with pushing files
>around over a network and making sure they got there
>in one piece. Before learning C++, I had engaged Bjarne
>in conversations about language philosophy for some time,
>so I had a pretty good idea of what I was getting into.
>
>o What made you decide to develop in C++?
> I knew enough about C++ to have reasonable confidence
> in its ability to help me do what I wanted to do.
> I'm not adverse to learning a new language in order
> to solve a single good-sized problem -- it took me
> four days to learn C (nine years ago) and a few
> weeks to learn C++ (this spring). C++ is about
> my 20th programming language.
>
>o What features of C++ are most useful?
> Constructors and destructors. These are functions
> that you can nominate to be called automatically
> every time a value of a certain type is allocated or
> deallocated. This means that you can design
> data structures that clean up after themselves.
> That, in turn, means that you don't forget to do
> it yourself. I should point out that it's actually
> hard to separate the various parts of C++ -- the
> whole is definitely more than the sum of the parts.
>
>o What features (or bugs) of C++ are most troublesome?
> The C++ translator tends to generate very large C
> programs, which, in turn, take a long time to compile.
> This is not a design flaw in C++, but rather a
> consequence of Bjarne's decision to try to make C++
> available on a whole bunch of machines at once.
> Since I learned to program on batch systems with overnight
> turnaround, this slowness bothers me less than it might
> bother others. The problem can obviously be solved
> by throwing money at it.
>
>o Does it take more or less time to develop applications?
> Much less, once you've learned the language.
>
>o Do you spend more or less time maintaining the software?
> If you really use the data abstraction facilities
> of C++, programs tend to be obviously correct
> when they aren't obviously incorrect. Once you get
> the thing to compile, it just runs.
>
>o Does it take more or less time to bring new developers up to speed?
> Dunno. C++ is an EXTREMELY powerful tool, and I can
> imagine people getting into deep trouble if they don't
> think about what they're doing.
>
>o Is the lack of support from AT&T a serious drawback?
> Couldn't say. If I find a bug, I send electronic mail
> to Bjarne; he usually fixes it pretty quickly. This
> obviously doesn't work in general. I understand that
> AT&T is presently in the throes of releasing a new version
> of C++ that is much more reliable than the previous one.
[ Bjarne tells me that Mr Koenig has used 1.1beta and refers above to
release 1.1 -- EI ]
>
>o Will you continue to use C++?
> Absolutely.
>
>o Would you recommend the language to other developers?
> Depends on what they're doing. I think the biggest risk
> in using C++ is that every user effectively becomes
> a language designer. I shudder to think of the results
> of putting C++ in the hands of truly lousy programmers.
>
>
>
>
> Andrew Koenig
> Room 2C-554
> AT&T Bell Laboratories
> 600 Mountain Avenue
> Murray Hill NJ 07974
> +1 201 582 5570
>
=============================================================================
>Date: Sat, 28 Jun 86 11:56:20 edt
>From: cybvax0!harvard!ulysses!ggs (Griff Smith)
>Subject: Re: A(nother) request for C++ experiences
>
> o What made you decide to develop in C++?
>
>I was planning a system with complicated enough data structures that I
>didn't want to think about doing all the storage management myself.
>Lisp might have been better, but it was ruled out by spotty
>availability on the systems in our Center.
>
> o What features of C++ are most useful?
>
>Strong typing caught many bugs early. Most functions worked once they
>got past the compiler. The built-in storage management really
>simplifies expression, but I find it difficult to build a good model of
>what I am "really" saying.
>
> o What features (or bugs) of C++ are most troublesome?
>
>Bugs were troublesome. Things like having to say
>
> if (predicate1(constructor1(args ...)))
> {
> if (predicate2(constructor2(args ...)))
> {
> /* do something */
> }
> }
>
>instead of
>
> if ( predicate1(constructor1(args ...))
> && predicate2(constructor2(args ...)) )
> {
> /* do something */
> }
>
>because the compiled code tried to free the object created by
>constructor2 even though it had never been created. The system went
>through an unstable period after a major overhaul of the compiler.
>It seems to be pretty solid now.
>
>Naming conventions for overloaded functions are also troublesome. In
>order to keep compatibility with library functions, the first
>declaration of an overloaded function gets the generic name. It is
>easy to forget this and get conflicting names for the same function.
>
>Compile times are long if you are on anything slower than a VAX 11/785.
[ Bjarne tells me that the actual numbers show that C++ compiles 50% to
100% slower than C. However, remember that strong typing removes errors
in the code that ordinarily require a test/fix/recompile cycle in C. Thus,
bugs are reported about 3 times faster -- EI ]
>
> o Does it take more or less time to develop applications?
>
>Can't say. I bit off a big project that I wouldn't have even attempted
>without C++.
>
> o Do you spend more or less time maintaining the software?
>
>Juggling header files every time you decide to build a new data
>structure is a pain. No worse that regular C, much worse than my
>memory of Lisp.
>
> o Does it take more or less time to bring new developers up to speed?
>
>I think the answer is "more". C++ is even more arcane than C. The
>subtleties are probably only appreciated by "real" computer
>scientists. I am probably trying too hard to understand what the
>compiler is doing; I am bothered that I still don't have a clear model
>of how my code maps back into assembly language.
>
> o Is the lack of support from AT&T a serious drawback?
>
>It has been somewhat less a problem for me. When I have a problem, I
>give it to a friend of Bjarne's; he turns it into a bug report and
>passes it on. I also see Bjarne at lunch sometimes.
>
> o Will you continue to use C++?
>
>Yes, but some reservations. I sometimes have trouble integrating it
>with existing C systems. Self-contained new projects should work
>well.
>
> o Would you recommend the language to other developers?
>
>Many of its features are a major improvement over C. ANSI C may close
>some of the gap. I would encourage people to try it, anyway.
>
> Griff Smith, AT&T Bell Laboratories, ulysses!ggs
>
=============================================================================
>Date: Sun, 29 Jun 86 17:48:47 PDT
>From: Mark Linton <cybvax0!mit-eddie!linton@voltaire.stanford.edu>
>Subject: Re: C++ experiences
>
>We have been using C++ in my research group at Stanford for about 4 months.
>Previously, we were using Modula-2. We are building an experimental
>software development environment, and most of the work with C++ so far
>has been in the implementation of a user interface system called InterViews.
>The system is currently about 25,000 lines of code.
>
>o What made you decide to develop in C++?
> C++ has explicit support for inheritance, which is helpful since our
> system is essentially object-oriented by design. The ability to port C++
> easily was a major advantage; our Modula-2 compiler only runs on VAXes.
>
>o What features of C++ are most useful?
> Classes, inheritance (derived classes), type checking of function calls.
>
>o What features (or bugs) of C++ are most troublesome?
> Lack of multiple inheritance, garbage collection.
>
>o Does it take more or less time to develop applications?
> Less than in either Modula-2 or C, and the resulting code
> is better organized using objects explicitly.
>
>o Do you spend more or less time maintaining the software?
> This question is not relevant to our environment. I don't believe
> maintenance time is really affected by the source language.
[ I must disagree. Source language is as important for the
maintenance stage of applications as it is for the development stage.
The ability to quickly understand the program specification is
essential when one is attempting to find logical errors in the code.
To see the difference, think about maintenance of a large system
written in assembler, as opposed to one written in a higher level
language, such as C or Pascal -- EI ]
>
>o Does it take more or less time to bring new developers up to speed?
> My students caught on to Modula-2 in general faster because of its
> similarity to Pascal, but it takes about the same amount of time
> to pick up the nuances of any language.
>
>o Is the lack of support from AT&T a serious drawback?
> No, I can't remember the last time I used a compiler that was supported.
>
>o Will you continue to use C++?
> Yes, certainly for the short term.
>
>o Would you recommend the language to other developers?
> It is certainly a major improvement over C, and is a better choice
> than Modula-2. I have no experience with Ada to know which is the
> better choice there.
>
> Mark Linton
>
=============================================================================
>From: cybvax0!harvard!caip!ll-xn!caip!clyde!attunix!sfbug!dww
>Date: Mon, 30 Jun 86 16:50:38 edt
>Subject: Re: A(nother) request for C++ experiences
>
>Some thoughts on "Why use C++?"
>
> I started using C++ because the program I was porting was
> written in C++. This initial exposure was sufficient to
> prove to me that C++ has a lot more going for it than just
> the "object-oriented" programming paradigm. I don't belittle
> the difference that OOP makes in readability and maintainability
> of code, but I would like to point out the other advantages that
> C++ has over C:
>
> 1. Function prototypes -- a big win. The "compiler" (actually
> a preprocessor) complains about missing or wrong type of
> arguments. (I know, lint will do that. I happen to prefer
> that the compiler do it.)
>
> 2. Type conversions on function calls. With the function
> prototypes, the "compiler" knows that "sin()" expects a
> double and does the required conversion in "sin(2)" for you.
> This is especially helpful in the "int vs. long" and "int
> vs. pointer" cases, where sizeof(long) or sizeof(char *)
> doesn't happen to equal sizeof(int).
>
> 3. Overloaded functions. This allows you to have similar
> functionality named identically, as in "char *ascii(int)"
> and "char *ascii(double)", two separate functions, but
> conceptually the same.
>
> 4. Default arguments. A notational shorthand, not a computational
> shortcut, this allows cleaner, more readable code for a
> large number of cases, and requires longer argument lists
> only to handle the exceptional cases.
>
> 5. Inline functions. A computational shortcut, this avoids the
> overhead of a function call and return for short, simple
> functions, while retaining the "function-call semantics":
> call by reference, for example.
>
> 6. const data objects. If a pointer-type argument to a function
> is used as a pointer to read-only data, then the "compiler"
> can check that the function does not changed the referenced
> data, if the argument is declared "const char *p", for example.
>
> 7. References are useful for implementing call-by-reference and
> functions which return lvalues.
>
> 8. Built-in new and delete simplify heap storage management
> syntax. "mchar *page = new mchar[80][24];" seems much more readable
> than "mchar *page = (mchar *) malloc(80 * 24 * sizeof(mchar));"
>
> 9. The void* pointer type has long been imitated in C using "char *"
> as a generic pointer. This merely lets you be more explicit that
> some pointer is truly a generic pointer.
>
> 10. Declarations within blocks allow you to declare variables at
> their first use, rather than collecting all variables at the
> top of a function. Some prefer the C way, but I prefer this
> way. I find it a more natural and readable style.
[ Lest you think (as I did) that this poster is referring to
the optional declarations at the start of every block
(something that is allowed in C also), Bjarne shows the difference
with this example:
Bjarne says:
I suspect he is talking about ``declarations as statements in C++''
not just nested blocks. For example:
f(double arg) // C++
{
if (arg == 0) error("arg == 0");
double inv = 1/arg;
// ...
}
vs
f(arg) double arg; /* C */
{
double inv;
if (arg == 0) error("arg == 0");
inv = 1/arg;
/* ... */
}
-- EI ]
>
> 11. Operator overloading is conceptually nice, but I have not yet
> had an occasion to use it in my code. The restriction concerning
> "at least one operand must be a class object" prevents the total
> chaos that would result from redefining the integer or double
> arithmetic operations.
>
=============================================================================
>Date: Mon, 30 Jun 86 13:27:55 PDT
>From: mirror!pyramid!sun!morocco!landauer (Doug Landauer)
>Subject: Re: A(nother) request for C++ experiences
>
>
>First, a little background is in order. Personally, I've been
>interested in C++ since I first saw Stroustrup's first "C with classes"
>paper. I have not had a chance to do much about it, though, until I came
>to Sun. Sun has bought a copy of the AT&T version of the translator, but
>we are not yet doing any major development with it. I would guess that,
>like Sun, most of the installations who have C++ only recently got a copy
>of the translator, and are still evaluating it. This could easily
>explain the paucity of responses you've gotten. Your questions are
>not yet answerable, for the most part, for such a new language.
>
>> o What made you decide to develop in C++?
>
>We haven't decided yet, but my main personal motivations for thinking
>that it will prove worthwhile are that C, in spite of its continuing
>growth, is showing signs of age. As we develop larger and more complex
>applications and systems, some of the features of C (particularly its
>single global name space) become more and more imposing. I see C++ as
>an attempt to solve some of these problems. Secondarily, it appears that
>C++ will make it possible to re-use code more often.
>
>> o What features of C++ are most useful?
>
>Procedure prototypes & parameter type-checking
>Classes with member functions
>operator overloading
>inline functions
>
>> o What features (or bugs) of C++ are most troublesome?
>
>We do not yet have decent debugger support.
>We do not yet have sufficient experience with the language to
>know what will be the most troublesome.
>
>> o Does it take more or less time to develop applications?
>> o Do you spend more or less time maintaining the software?
>
>Don't know yet.
>
>> o Does it take more or less time to bring new developers up to speed?
>
>Right now, more time, of course, because it's easy to find programmers who
>already know C, but harder to find ones that already know C++.
>
>> o Is the lack of support from AT&T a serious drawback?
>
>No.
>
>> o Will you continue to use C++?
>
>Yes.
>
>> o Would you recommend the language to other developers?
>
>The language, yes. This particular implementation, no, not yet,
>unless you happen to be fascinated by programming languages.
>
>
>C++ is definitely a more complex language than C. As such, I think it
>cries out for more sophisticated debugging and program development
>support than are required for C alone.
[ I have to agree (as does Bjarne). When you are programming at a
level of higher abstraction, as one often does in OOP, the demands
made upon the programming environment grow.-- EI ]
>--
> Doug Landauer
> {ihnp4, amdahl, decwrl, seismo, ..}!sun!landauer
> landauer@sun.arpa
>
=============================================================================
>Date: Tue, 1 Jul 86 17:46:54 PDT
>From: cybvax0!harvard!seismo!amdahl!jon (Jonathan Leech)
>Subject: C++ survey
>
>o What made you decide to develop in C++?
> - It is considerably superior to C in almost all respects. Equally
> important, it is available NOW and easily portable across the
> Unix* domain (as I have verified by bootstrapping the compiler
> on 4 flavors of Unix including 4.2 BSD (VAX), Sun 2.0, HP/UX 5.0,
> and Amdahl UTS).
>
>o What features of C++ are most useful?
> - Classes in general. Data hiding is not that important, but member
> functions, virtual functions, constructors and destructors,
> etc. make code smaller and easier to understand.
> - Better error checking compared to the standard Unix C compilers;
> despite the additional overhead of the C++->C->executable, I think
> getting bugs out is faster because it catches errors early,
> including errors that 'lint' never thought of (such as not using
> all the members of an enumeration in a switch statement).
> - Features mostly derived from or contributed the ANSI C draft: const,
> void *, prototypes, etc.
[ Something that Bjane mentions: Note that these features are mostly
being borrowed by ANSI C from C++, not the other way 'round! -- EI ]
>
>o What features (or bugs) of C++ are most troublesome?
> - Getting it running on different flavors of Unix. The installation
> instructions that come with C++ are just plain wrong for most
> Unixes, and figuring out the minor corrections for each Unix
> is a mindless and boring exercise. Much more effort should be
> put into the installation process, including distributing C
> source targeted for the machine you are going to run C++ on
> rather than having to bootstrap it from a VAX or 3b20.
> - Debugging is a pain; even with sdb or dbx, you're debugging with
> the C code generated by C++. Sdb and dbx are to C++ as adb is
> to C - useful, but nowhere near what a debugger should be. The
> problem is inherent in the current implementation of C++ (compiling
> into C code instead of assembler) and the debuggers (not
> understanding C++ classes and overloaded functions, etc.)
>
>o Does it take more or less time to develop applications?
> - Initially more, then less as I moved up the learning curve (this
> took several programs and perhaps the equivalent of 2 weeks
> full time working with C++).
>
>o Do you spend more or less time maintaining the software?
> - Much less.
>
>o Does it take more or less time to bring new developers up to speed?
> - No idea, the only one I've brought up to speed is myself. If they
> already know C and have some vague idea of class hierarchy,
> overloading, etc., it's easy; otherwise they are in deep trouble.
>
>o Is the lack of support from AT&T a serious drawback?
> - I personally have gotten a great deal of useful feedback directly
> from Bjarne, which is a hell of a lot more support than one gets
> with most of Unix. People who are not on Usenet are not fortunate
> in this respect. In other words, no, it's not a drawback for me.
>
>o Will you continue to use C++?
> - As much as possible. I love it.
>
>o Would you recommend the language to other developers?
> - Absolutely, based on personal experience you will end up being
> twice as productive, your code may be much easier to read,
> understand, and maintain, and you will enjoy coding more.
>
> -- Jon Leech (...seismo!amdahl!jon)
> UTS Products / Amdahl Corporation
> __@/
>
>This does not represent the views of Amdahl Corp.
>
=============================================================================
>From: Chris Crampton <cybvax0!harvard!seismo!mcvax!vd.rl.ac.uk!cmc>
>Date: Wed, 2 Jul 86 11:22:31 -0100
>Subject: C++ enquiry
>
>Dear Elias,
>
>Here are a few quick answers to your recent enquiry about C++. I work within
>the MMI section of the Informatics Division here at Rutherford Appleton
>Laboratory in the UK. We were involved with the evolution of C++ from its
>early days as "C with Classes" and have liased with Bjarne Stroustrup for
>a long time about the language. Up to now, the main work I have done has been
>to port the various releases of C++ to the machines we use here at the Lab.
>Unfortunately, I have not been able to do much work using C++ itself yet but
>hope to change this over the next few months.
>
>
>o What made you decide to develop in C++?
>
> We had been interested in object oriented programming for some time
> and had been looking for suitable languages which we as a group and
> organisation could adopt. The fact that C++ is a superset of C and
> the extensions made are a logical path from C also attracted, as did
> the fact that C++ is relatively easily to port to new systems.
>
>o What features of C++ are most useful?
>
> - Stronger type checking, just about sufficient for novice
> programmers (c.f. C)
>
> - Data abstraction, inheritance and virtual functions
>
> - Operator overloading (Not quite as useful as one might imagine...)
>
>o What features (or bugs) of C++ are most troublesome?
>
> - Debugging programs written using C++ can be a nightmare. You are
> basically debugging from the intermediate C code produced from the
> translator with all of its bizarre identifiers etc.
>
>o Does it take more or less time to develop applications?
>
> I cannot really say as we have not, as yet, embarked on anything
> significant, but I do get the feeling that it should be easier
> to produce well designed packages and more code should be re-usable.
>
>o Do you spend more or less time maintaining the software?
>
> Don't know yet...
>
>o Does it take more or less time to bring new developers up to speed?
>
> Compared to C? Compared to Pascal? I feel this very much
> depends on the developers familiarity with C, data abstraction etc.
> It should be straight forward for someone to convert from C.
>
>o Is the lack of support from AT&T a serious drawback?
>
> Not really, at the moment. The net.lang.c++ newsgroup is a good
> forum for discussion and exchange of bug fixes etc. This may be
> different for a commercial organisation using C++ to make money.
>
>o Will you continue to use C++?
>
> I hope to make rather more use of C++ than has been the case so far.
>
>o Would you recommend the language to other developers?
>
> I would definitely recommend C++ as a development language but I
> suppose the fact that it is not yet a fully supported product may
> put commercial developers off. There are still a number of bugs and
> the language is still not frozen (which some may consider a good
> thing). It should be noted that C++ is a widely used development
> language within AT&T.
>
>If you have any further enquiries then please get in touch.
>
> Chris.
>
>=======================================================================
>Chris M Crampton UK JANET: cmc@uk.ac.rl.vd
>Rutherford Appleton Labs, ARPA: @ucl-cs.arpa:cmc@vd.rl.ac.uk
>Didcot, OXON, U.K. UUCP: ..!mcvax!ukc!rlvd!cmc
>+44 235 21900 ext. 6756
=============================================================================
>Date: Mon, 30 Jun 86 15:07:00 EDT
>From: cybvax0!harvard!cmcl2!bullwinkle!batcomputer!gdykes (Gene Dykes)
>
>In article <195@vcvax1.UUCP> you write:
>> o What made you decide to develop in C++?
>It sounded like a real win for big software projects.
>> o What features of C++ are most useful?
>Compile-time type checking, classes.
>> o What features (or bugs) of C++ are most troublesome?
>Not sure yet...
>> o Does it take more or less time to develop applications?
>Much less.
>> o Do you spend more or less time maintaining the software?
>Much less.
>> o Does it take more or less time to bring new developers up to speed?
>Not yet determined.
>> o Is the lack of support from AT&T a serious drawback?
>Net.lang.c++ seems adequate.
>> o Will you continue to use C++?
>Definitely.
>> o Would you recommend the language to other developers?
>Yes.
>--
>Gene Dykes, 120 Rand Hall, Cornell U., Ithaca, NY 14853 (607)255-6713
>{ihnp4,decvax,allegra,vax135}!cornell!batcomputer!gdykes
=============================================================================
>
>Here's a response to your questions. I got them forwarded to me by a C++
>guru; I do not read netnews, many C++ programmers do not; they are having
>too much fun programming...
>
> o What made you decide to develop in C++?
>
>We used "C-with-classes," a predececessor to C++, for some early prototyping
>work to explore object-based design back in 1982 or so. We chose it because
>it was available, because support was close at hand, and because
>it could be targeted to any "C" installation (most of our customers are C
>animals). C++ was a natural followon. We DIDN'T choose Objective-C, or
>SmallTalk, or Flavors, because they were either poorly supported, unportable,
>inefficient, or immature.
>
> o What features of C++ are most useful?
>
>1. Virtual functions, used in conjunction with derived classes. They make it
>possible to evolve software gracefully by creating new subclasses as they
>are needed, re-using existing base class software.
>
>2. The type checking is a decided advantage over C, and solves a good
>percentage of problems that would otherwise get through to system test or
>to the field.
>
>3. It is a "small" language (compared to Ada or Chill or PL/1), portable,
>and well documented.
>
>4. etc.
>
> o What features (or bugs) of C++ are most troublesome?
>
>1. Lack of support of multiple inheritance.
>
>2. It is still "C" (i.e. pointers can still go wild if you're not
>careful, though it is better than in the unconstrained case of C).
>
>The cfront compiler is becoming stable, and currently contains no
>bugs that are really hurting me. I know of 4 bugs at last count, but
>most have to do with producing proper error messages in light of
>programmer fumble fingers.
[ Bjarne tells me that these people are not using 1.1 yet -- EI ]
>
> o Does it take more or less time to develop applications?
> o Do you spend more or less time maintaining the software?
>
>Our experience was: more time *formally* designing, more time programming,
>much less time integrating, and less time maintaining. The "more time
>designing" is misleading, though: having classes allows you to make your
>design more concrete earlier on in the process, so you are more careful,
>and this saves a lot of bugs farther down the road. The more time programming
>was a one-time experience, having our developers learn as they went, and
>I don't suspect this is a true trend or property of the language and suspect
>that programming would go about as fast as C. The most amazing thing was
>integration, which surpassed everyone's expectations here: credit the
>type checking and localization of interest within classes. Maintenance effort
>is reduced because impact of change is easier to analyze, it can be easier
>to contain (within a class), and inheritance gives you a final "out" for
>evolving software.
>
> o Does it take more or less time to bring new developers up to speed?
>
>Depends what you mean by "up to speed." Good C programmers can right perfectly
>valid but otherwise pathetic C++ code. A programmer can look at C++ as C with
>type checking; and if that's all they learn in coming up to speed, they are
>not really taking advantage of the power of the language. Learning abstraction
>and classes is even more helpful, but to really take advantage of the language,
>I feel that a paradigm shift is necessary. It is difficult to reeducate someone
>who has been brainwashed with C, Pascal and top-down-design, to use inheritance
>and the object-based approach.
>
>Another question is: Does it take more or less time [than what?] to bring
>new developers up to speed? You'd have much the same problem with Ada, and
>in fact it would be even worse since Ada has a lot of baggage with it. The
>same is true for CHILL, except the paradigm there has much less value and you
>still have the unnecessary baggage (two-dimensional data statements, indeed!)
>There are many languages which would be difficult to learn for a C programmer,
>and which would have no where near the power that C++ does (Pascal variants,
>for example). Though knowing C can be a handicap as mentioned above, it can
>also be a good leg up. Good programmers who know C can make good C++ programmers;
>good C programmers who are otherwise average programmers can make disastrous
>C++ programmers.
>
> o Is the lack of support from AT&T a serious drawback?
>
>I feel supported, and it is my understanding that support is available, but
>I don't know the details. Being inside of AT&T, my perspective on this
>question is from the wrong side...
>
> o Will you continue to use C++?
>
>Even though our initial use of this language was exploratory, I have adopted
>it for most of my day-to-day work, switching over completely from Pascal and C.
>
> o Would you recommend the language to other developers?
>
>Yes, but again with the caution that you don't want to throw pearls to swine.
>
>--jim coplien ihnp4!cope!cope 312/979-2618 AT&T Bell Laboratories IH 6C511
>
@END(survey)
Well, there it is. I hope that this has been helpful. I would not
mind seeing this discussion continue on the net. Also, people who
want to discuss C++ or OOP with me personally should feel free to send
questions/comments to me via e-mail.
------------------------------------------------------------
Elias Israel
VenturCom, Inc
Cambridge, Mass.
"Harnessing the Power of Unix"
{harvard,mit-eddie}!cybvax0!vcvax1!eli