Conference turris::languages

    Yes
    
    /Bevin

	C++ is a C language superset designed to provide some object-oriented
    features (much like Objective C). C++ was written by Bjarne Stroustrup
    of Bell Labs, and is available via license from them. It produces
    C language output, and should be portable to just about anything, although
    its provided in VAX (UNIX) and 3B2 versions on the distribution tape.

	There is a commercially available text, "The C++ Language", by
    Stroustrup, from Prentice-Hall (I think). It's pretty much K&R with
    chapters on the extra features.

        Objective C is built on top of the standard UNIX C compiler,
        and shares all its many weaknesses while adding more.  C++
        is supposedly an entirely new compiler, much improved (as
        well as adding the object capabilities).
        
        (but be warned that this isn't first-hand info, since I've
        never personally seen either)
        
        	/dave

    My recollection is that Objective C is a pure preprocessor, producing
    a C program as output.  Thus, in principle, you could take the output
    of Objective C and feed it into the VMS C compiler, although there
    might be some rough edges.  (This ignores the problem of how do
    you either get Objective C to run on VMS, or to get its output to
    VMS; however, I wouldn't be suprised if the Objective C people already
    have a VMS version.)

The original C++ implementation was a textual preprocessor.  See
Stroustrup's article in SIGPLAN Notices a few years ago.
				/AHM

In particular, see these articles and papers by Bjarne Stroustrup:

Classes: An Abstract Data Type Facility for the C Language
SIGPLAN Notices, Vol 17, #1, pp42-15?, Jan-82

Adding Classes to C: An Exercise in Language Evolution
Software Practice and Experience, Vol 13, pp139-161 (1983)

Bell Labs Computing Science Technical Reports:

#84 - Classes: An Abstract Data Type Facility for the C Language
#90 - A Set of C++ Classes for Co-routine Style Programming
#108 - The C++ Programming Language - Reference Manual
#109 - Data Abstraction in C
#??? - Operator Overloading in C
#??? - Complex Arithmetic in C (written by Leonie V. Rose and Bjarne Stroustrup)
				/AHM

				C++ Available
				=============

    AT&T has  announced  that the C++ programming language is now available
    to  both educational and non-educational institutions. The distribution
    fee for education institutions is $250. Distribution is handled by

	AT&T Software Sales and Marketing
	PO Box 25000
	Greensboro
	North Carolina 27420
	(800) 828-UNIX or (919) 279-3666
	
    or by your local sales organization for the UNIX* system.
    
    C++ is  a  superset  of  the  C  programming  language that retains the
    efficiency  and  notional  convenience  of C while providing (improved)
    facilities for:

	- type checking
	- data abstraction
	- operator overloading
	- object-oriented programming
	
    including:
    
	- function argument type checking and type conversion
	- scoped & typed constants (alternative to #define)
	- inline functions (alternative to #define)
	- Simula-like single-inheritance class concept
	- data hiding
	- operator overloading
	- (optional) guaranteed user-defined initialization and clean-up
	- user-defined type conversion
	- dynamic typing (virtual functions).
	
    The language is defined and introduced in:
    
	Bjarne Stroustrup: The C++ Programming Language.
	Addison-Wesley, ISBN 0-201-12078-X.
	
    The released  implementation  consists  of  a C++ to C translator, a CC
    command, and the standard C++ libraries and header files. The libraries
    provide support for:
    
	- stream input/output
	- complex arithmetic
	- event-driven simulations
	- generic user-defined data types
	
    It runs  on  AT&T  3B  machines and VAX*s running UNIX System V or BSD.
    Since  the  translator  can  be  used  as a cross compiler it is easily
    ported  to  other hardware. C++ in use on M68Ks, Ahmdals, Pyramids, and
    others.  C++ is link compatible with C and most C tools can be used for
    C++ programs.
    
    Bjarne Stroustrup
    AT&T Bell Laboratories
    Murray Hill, NJ, USA

    * UNIX is a Trademark of AT&T Bell Laboratories.
    * VAX is a trademark of Digital Equipment Corporation.

I wonder how easy it would be to get it to run on VMS . . .
				/AHM

    Having seen and played with rekease e, it wouldn't be too difficult
    to get it to work on VMS -- the main requirements are the ability
    to support long identifiers (significant in all characters) and
    the 'void' storage class.  The VMS I've got here (2.1, I think)
    limits identifiers to 31 characters -- however, it wouldn't be to
    difficult to post-process the C++ pre-processor to shorten long
    identifiers, or even make C++ use shorter identifiers.
                                                
    When I tried to port the C++ front-end to the Sun workstation, it
    broke the C compiler, don't say I didn't warn you.  (The 'C' produced
    by C++ looks like lisp it has that many ()'s!)

    Does this mean that we have a copy of C++ available on the net?
    (You'll notice that I didn't say "working copy"...)
    
    
    - dave

    Alas, no.  My copy was one I lifted from a university and is currently
    residing on a GCR tape 50 miles away.  A tar tape at that and I
    can't read it on anything yet...  I do know that legal C++ is available
    from Unix Europe Ltd (in Europe) and is about $1500 for source and,
    I think, updates when they appear.
    
    By the way, to avoid confusion my previous note (.10) suggested
    I was using VMS 2.1, that should've read 'VAX C 2.1' (actually on
    VMS 4.3).
    
    - jch

I'm reading Stroustrup's book "The C++ Programming Language".  I am
REALLY impressed by the features in the language.  I think it was extended
beyond what was described in the SIGPLAN Notices article, although those
Bell Labs references I posted earlier might discuss things like implicit
conversion operators, the "reference" data type operator, and the
implications of user-defined overloading of the = operator for new types.

C++ seems to have all the power that Ada was denied by the Distinguished
Reviewers not accepting Paul Hilfinger's thesis proposal to add overloading
of := (see TLE::ADA 298.2).  It passes my personal litmus test of giving
users the ability to add real (= Basic) string handling to the language
without resorting to crocks like:

	STRING_ASSIGN(A, B+":"+C);
		-or-
	STRING_ASSIGN(X, F(STRING_COPY(B+":"+C)));

Except for the fact that the way the features of constructors, destructors,
conversions and so on are added to the language are by extensions to C's
cretinous type syntax that are every bit as disgusting as the original
language, it is a worthy evolution of C.
				/AHM

    I tried the string handling stuff as well, but I has too basic gripes:
    I couldn't get "hello" + "world" to work (you must have at least
    one class type on an overloaded operator, in spite of the fact that
    "hello" + "world" wouldn't otherwise maker much sense).  I also
    noticed that the string handling would be extremely slow as I had
    to free up the LHS of an assignment every time.
    
    C++ does address some of the failings of C, but it doesn't really
    go far enough:  Certainly I agree with AHM that is better than the
    original; but there are problems (the 'cretinous type syntax').
    It is a pity that Stroustrup made a conscious descision NOT to include
    a garbage collector 'for efficiency reasons' (he claims);  things
    like string handling would go so much better if there *was* a proper
    garbage collector.
    
    The compiler does clear up out-of-scope results on the stack (I
    seem to remember) so that you don't get temporary results clogging
    up your memory usage,  but it doesn't half slow down procedure returns.
    
    C++ has the potential to be great; it needs the syntax cleaning
    up in a few places and there are a few things that make it potentially
    slow (very) and unwieldy, but it does hace some good ideas ...
    
    							jch

Re .14:

If you make a definition of plus this way:

class string {
// ...
public:
    friend string operator+(char *, char *);
//...
};

then "hello" + "world" should invoke a routine you wrote, which can
allocate space for the result and put the characters there, without
attempting to free up the source strings.  Another method, which would
probably be considered more tasteful, would be to define an implicit
conversion from char * to string:

class string {
// ...
public:
    string(char *);
//...
};


Freeing up the LHS of an assignment every time need not be any slower
for C than it is in an implementation of Basic.  It could be implemented
by merely prepending the string to an unsorted free list, which is only
untangled and returned to true free store when there is no heap left.
This would take only three memory references at the time of the assignment.
Or, since C's definition of free() (and C++'s delete) do not let the
user tell the RTL the size of the chunk of memory being freed, this
means that the memory manager is probably using either boundary tags
or a buddy system.  It only takes a fixed amount of time to free a chunk
when using boundary tags, and at least some buddy systems should take
time sublinear with respect to the number of chunks in use at the moment.

It also seems that for user defined types which manipulate pointers,
it ought to be possible to add initializers which keep the addresses
of all the pointer variables on a linked list, which would allow the
user to write their own garbage collector.  It is impossible to write
a garbage collector for C (or any superset of it), without changing the
representation of pointers from a single machine address.  This is
because the existance of undiscriminated unions in C make it impossible
for the compiler to build templates which allow a GC to find the pointers
in the program.  And just changing the representation of all pointers would
make it impossible to interface C routines to externally defined code and
data structures which deal with pointers, so you have to either extend
or restrict the language in some way.
				/AHM/THX

    It says in the book that (section 8.5.11, page 282/3) that an operator
    must have either be a member function or take at least one class
    argument.  See also sec 7.16, it says.  There is a good reason for
    this; the operator '+' is already defined for two char*'s (silly
    though it is); if you try to overload it, then there is no way of
    telling which operator you want in, say, 
    
    	cout << "hello" + "world";
    
    The explict cast is really what C requires, but looks horrible;
    you need, now,
    
    	count << (string) "hello" + "world";
    
    so long as you have 'operator+ (string, char*)' defined.
    
>Freeing up the LHS of an assignment every time need not be any slower
>for C than it is in an implementation of Basic.
    
    who says Basic is fast?  Anyway, keeping unsorted free lists is
    half of the garbage collection problem anyway.  No, the real
    problem is knowing what you can and cannot throw away.  For example,
    the code associated with 'operator+ (string, char*)' will need to
    allocate space for the result; fine.  Now you assign this result
    to some other string so you allocate some space and copy it (which
    you definitely *should* do) and free the intermediate result ...
    but you don't know that it is an intermediate result ... As I say,
    I think this is mostly solved by letting temporary results go out
    of scope.
    
    
    Garbage collection in C (or C++) is, as you rightly point out,
    tricky.  You can do it so long as you warn people that nasty
    tricks with unions and casting will confuse the heap manager.
    I think that C++ should be a bit more rigorous about unions though,
    not to mention casts.
    
    Glossing over the difficulties caused by horrible pointer munging,
    GC in any language really only requires information to be kept about
    pointers using the heap and the cooperation of the compiler in
    informing the heap manager about what is being done with those
    pointers.  (You need the pointer's address, the space it is
    supposed to be pointing to and the size of that space for each pointer;
    and the compiler should inform you whenever that pointer is copied
    and when, if, the pointer goes out of scope.)  I still believe (with
    good reason) that heap management + GC is better and faster than
    allocate/free and not *that* difficult (so long as you can enlist
    support from the compiler).
    
    							jch

I haven't gotten to the reference manual appendix yet, so I didn't know
about the rule that says at least one operand of an overloaded operator
must be a class (it would probably allow a struct or union as well).
That is a bad rule, because there are some operand type combinations
that operators don't exist for at present.  char * +(char *, char *)
is one of them.  Vax-11 C correctly complains about "Invalid pointer
arithmetic" when fed "Hello" + "world" since in C, addition is defined
between integers and addresses, and integers and integers, but not
addresses and addresses.

I wrote one Tops-10 Simula-67 program in college.  It traced a line
of magnetic force from an air-core solenoid by repeatedly computing
the magnetic field at various points.  Each time, the field was computed
by integrating the contribution from infinitesimal pieces of wire in
the solenoid.  I defined a "vector" class, which represented 3D real
values (3D vectors).  Simula-67 only allocates classes on the heap, and the
intermediate results of calculations were allocated, used once
(immediately), and soon after, the only pointer to the temp was lost. 
So, you can imagine how this flagellated the heap.  I don't know how
efficient the GC code was, but from the way the impure area's size kept
tracing a sawtooth wave pattern, the program spent most of its time
doing GC.  In situations where static analysis or reference counts can
help, GC may not be an advantage.  Certainly in this case, the program
would have run a lot faster if it kept track of where the class members
were.
				/AHM

    For things like operator +(char *, char *) I guess C++ ought to
    let you define operators where none existed before.
    
    GC can be a pain: you've gotta be careful about when you do it:
    if you do a GC every, say, 2Mb of store allocated, then a program
    which allocates 2.01Mb store will force a GC, even if it hasn't
    done anything like that before.  You should, I think, make the GC
    happen when then amount of store allocated exceeds the (mean? max?)
    allocation size by some large factor -- 10 say -- or when you can't
    allocate any more space.  I once hung a garbage collecting editor
    which, in fact, did do a GC every 2Mb or so, by reading in a 2.5Mb
    file.  What's more it loaded the machine so heavily that people
    started complaining!
    						jch

I'm a new entrant to the conference, so you may already know
all this, but here goes anyway.

There is some user experience with C++ in the Byte issue on
object-oriented languages (sometime in 1986) where someone discussed
its use to develop a Window Manager.

The recent European Unix User Group conference in Sweden had a
new paper from Bjarne on multiple inheritance schemes.

Your best source for a C++ compiler is:
		Glockenspiel Ltd,
		13 Belvedere Place
		Dublin 1.
		Ireland.

		From US Dial 011-353-1-735140
		From UK Dial 0001-735140
		Elsewhere Dial + 353 - 1 - 735140

They have it running successfully - and fully compatible at a
source code level - on MS-DOS, a variety of Unixes (including Ultrix,
I believe) and VMS, among others !!

They market it as Advantage C++, via Lifeboat in New York, for MS-DOS
and as Designer C++, via Oasys in Cambridge, Mass., for other OS.
For Europe they market themselves direct.  Their Japanese distributors
are Lifeboat Japan.

I think they also run training courses, a local US rep for these courses
is Semaphore Inc, (617)-474-0040.

I also have copies of a few papers on C++ usage, if you want mail
me a request for a copy.

PS. The Stroustrup book is as unreadable as K&R, the language is
    more complex => it's hardly worth using the book as a platform
    for learning the language.  I do know that two other books are
    currently in the publishers pipeline, probably available in 1988.

    
    I take exception with your comment on Bjarne's book.  Having taken
    the time to read it cover to cover I think that it is very worthwhile
    reading both for the novice and expert C user ( depending on who you talk to
    C++ is C).  The book has depth and therefore requires a little effort
    on the part of the reader.  For those who are just getting into
    C - I think this is the book to buy.
    
    Don Courtney
    
    

Stroustrup's book certainly sucks in the same way as K&R when it comes to
trying to find clear, authoritative statements on the language's exact
definition.  It's the same old story - "You want to know how {Unix|C|C++|...}
is defined?  Go run it (AT&T's implementation) and find out".
				/AHM

    
Don, I'm sorry you feel upset about my comment.  Unfortunately, you cannot
really learn the language easily from the book.  The language is _totally_
different to C, though you can write C++ that looks exactly like C, but
whats the point of doing that.  You might as well try to adopt Mesa as
a medium for learning about interpretive code. You really need the book,
a machine to try the compiler out on, and some feeling for what the
reasons for adopting an OOP style are.

RE:

>    on the part of the reader.  For those who are just getting into
>    C - I think this is the book to buy.

I'm assuming you mean C++ here.  If you are a novice C++ user, unfortunately
the book is the only one to buy currently.  If I was wrong though - and I
_think_ it did happen once, though maybe I was mistaken - then why are so
many new books in the pipeline ?

If you don't mean C++, then don't (please) try to use this book to learn C,
I can name three other books (at least) that are better for the novice.

Bernard

    
    I have been taken to task by a few other people on my opinion about
    the blue book.  I guess it is not very good for novices and certainly
    is not a good spec to write a compiler with!  I still had a good
    time reading it though and it completely sold me on the language.
    So if anyone likes writing books...
    
    Don
    

Re : 91.19 

>Your best source for a C++ compiler is:
>		Glockenspiel Ltd,
>		13 Belvedere Place
>		Dublin 1.
>		Ireland.
>
>		From US Dial 011-353-1-735140
>		From UK Dial 0001-735140
>		Elsewhere Dial + 353 - 1 - 735140


It has been pointed out to me that I should not make suggestions
like this without saying that they are my own _personal_
opinions and not those of DEC.

Apologies, if anyone thought otherwise, I'm still new to
conferencing and ways of expressing myself correctly in this
environment.

We now have the AT&T C++ compiler, release 1.2, available for internal
use.  The compiler is available in binary form for use on ULTRIX
systems only.  This compiler requires a royalty payment to AT&T for
each copy distributed.  This royalty depends on the size of the target
system; to find out the number of users your machine is licensed for,
run the program /etc/license in superuser mode.

We also expect to have available the G++ or GNU C++ compiler, based on
the GNU C compiler.  The GNU C compiler was written by Richard
Stallman; the modifications to compile C++ were done by Michael Tiemann
of MCC.  This compiler is subject to the Free Software Foundation
license, which requires free distribution of both the source and
binaries.  I will post an update when we have this compiler working under
ULTRIX, but it is likely to be several months.  (Offers of help
welcome.)

Some quick comparisons: the AT&T C++ compiler is the official processor
for the language; it is implemented as a preprocessor to the standard C
compiler (cc).  The G++ compiler is a set of extensions to the GNU C
compiler (gcc) which is itself still in alpha test and has several
known bugs, but produces fairly well optimized code.

If you want a copy of the AT&T C++ compiler, I need the following
information:

. Node name and type (e.g., 8800) of ULTRIX machine(s) you will run the
  compiler on.

. Mailing address for the tape containing the compiler.

. Cost center, CC Manager's name, and account to bill for licensing fee
  (the fee ranges from $50 for 2-user workstations to $500 for a
  65+-user 8800).  You should talk to your finance person.

. Preferred medium (9-track tape or TK50).

When the GNU G++ compiler is working, a copy will be placed in a public
location on the E-net and announced here.

    I have the GNU CC compiler up and running under Ultrix and am just
    starting to get the G++ compiler running.  It would help if I had some
    C++ programs to test on it. 

    I have the distribution for the compilers on the Easynet.  Let me know
    if you want to get at them.  [I would normally post this info but as
    GCC & G++ take up a lot of room I may move them or such at a moments
    notice. It also allows me to gauge the popularity of these compilers.] 

    From: [email protected] (Bjarne Stroustrup)
    Newsgroups: comp.lang.c++
    Date: 13 Sep 93 
    Organization: AT&T Bell Laboratories, Murray Hill NJ
  
    People who expect to become proficient in all of C++ and its related
    techniques in a week or two get overwhelmed. Their expectations are
    unrealistic. Had C++ been a language that could have been completely
    mastered by a C or Pascal programmer in a week it wouldn't have been
    worth learning; C++ would have been roughly equivalent to C or Pascal
    in real use and would have supported only the same old programming
    techniques and delivered the same old benefits - and no more. There is
    no need for another such language.
 
    When approached in a reasonable manner, C++ will deliver SOME benefits
    compared to C after a week or two, more after a month or two, and yet
    more after a year or two. It is a language to grow with.
 
    Because gaining those benefits depends on the programmer and designer
    learning new techniques most cannot simply pick up C++ from a manual or
    a ``dummies guide.'' You need a textbook; preferably one that
    approaches the language in a cautious and non-hyped manner.
 
  > I learned OOP from Flavors, I knew OOP well, and believe me, C++ is not
  > an OOP language  (apologies to Senator Benson).
 
    If the definition of OOP is Flavors then C++ is indeed not OOP;
    however, (almost?) all reasonable people tend to admit languages with
    static type checking into their definition of an OOPL provided they
    provide inheritance and maybe one or two other distinguishing features.
    Not doing that would exclude not only C++, but also Beta, Eiffel,
    Simula, and many other well respected OOPLs from the class of OOPLs.
 
    Had I wanted to support dynamic inheritance, I would have done so. I
    knew enough Smalltalk, Flavors, and (more recently) CLOS to design a
    good imitation had I wanted one. I didn't. If I need a more dynamic
    system I know where to find Smalltalk or CLOS. There is (IMO) no need
    for an immitation; those languages serve their intended purposes well
    enough.
 
    C++ provides facilities to express static structure clearly and for
    that static structure to be exploited by programmers and enforced by
    the implementation. Efficiently. Beyond the paradigms/styles directly
    supported by C++ one must simulate. Merely fighting the type system
    usually fails.
 
    In my experience, one of the most common reasons for a person to fail
    to benefit from C++ is that person having a firm belief that he/she
    knows everything worth knowing about programming so that he/she can
    simply e to use C++ as a slightly inconvenient notation for their ``one
    right kind of programming.'' If you want to benefit from C++ you should
    be prepared to invest some time and energy in learning how C++ is
    supposed to serve you.
 
    Had I known very little about C++ and listened to the rantings on
    comp.lang.c++ lately, I suspect I would have drawn the same conclusion.
    Many people on comp.lang.c++ patiently, clearly, politely, and
    correctly explains what C++ is, what C++ isn't, and shows how one might
    use it. Others, however, use comp.lang.c++ to display their ignorance.
    This, I fear, is inevitable in a large newsgroup discussing a popular
    topic and has very little to do with programming or C++.
 
    If someone decides that they have no wish to be associated with a bunch
    of people so rude and opinionated as some of the people arguing here, I
    can't really blame them. Similarly, if someone decides that a language
    where one has to know details as obscure as some of the ones debated
    here is too subtle to bother with, then again I can't blame them.
 
    Fortunately, it just isn't so. Most C++ programmers are as polite and
    helpful as other people, and you don't have to understand the
    subtleties discussed in the standards meetings to use C++ successfully.
 
    Novices (relative to a particular language) do not learn good
    programming form hearing experts and would-be experts debate subtle
    points; they learn from textbooks, from courses, and from reading code.
    One thing we all have to learn is that relatively to a new significant
    programming language we are all novices. ``The net'' can also answer
    specific questions, but it seems unable to help people choose which
    questions to ask and it is not easy for a novice to know which answers
    to believe.
 
    In particular, we ought to try to place discussions of subtleties on
    comp.std.c++ and to place discussion of practical uses on
    comp.lang.c++. Hopefully, this would allow the novices to learn from
    the more experiences on comp.lang.c++ and the experts to demonstrate
    their erudition on comp.std.c++. Unfortunately, flame wars are often so
    much more interesting than presenting simple explanations to the
    novices who needs them :-( Similarly, arguing subtleties with language
    lawyers seems to have a perverse attraction.
 
    I don't know if this reassures people or not, but I have a hard time
    seeing the point in some of the discussions and in following the twists
    and turns of the subtle arguments. Such arguments are at times
    necessary to resolve issues, but it is not what C++ programming is
    about.
 
  > This makes the third time in as many years I've looked hard at C++, and 
  > my decisions are always the same.
 
    It sounds like you dislike or doesn't need static structure and/or
    static type checking. If so, your decision is probably correct. Fake
    the dynamic inheritance mechanisms in C (or the C subset of C++), or
    even better use a language designed to support your style.
 
    One might also suspect that you haven't looked very hard and maybe in
    the wrong places:
 
   > Actually, my C++ knowlege stinks.  I looked at a few years ago when
   > Borland first offered their C++ compiler, dropped it, tried it again
   > about a week ago and have decided to drop it again. 
 
    I don't think you can learn C++ in a week. At least, I know that most
    good programmers can't learn C++ in a week. That is, actually, one
    thing people keep remarking on as a GOOD thing. You don't exhaust the
    language in a  week or a month but continue to learn new things and
    gain concrete benefits from new techniques and concepts month after
    month.
 
    You don't need to know physics or patent law to drive a car and you
    don't need to understand the discussions on comp.std.c++ or in the
    standards committees to write good C++. In fact a focus on physics or
    law will make you a worse driver - and a focus on obscure language
    details will make you a worse C++ programmer.
 
    Many of the questions are of the form ``why can't I do X exactly as I
    did it in my previous language?'' Maybe the kindest answer would b be
    ``because that's not the way we do it in C++,'' but people here tend to
    be kind and helpful and try to provide C++ equivalents to alien
    paradigms. Some of the discussion reminds me of the imperial/metric
    metrics debates: ``why would anyone what to calculate distance in
    1614.2 meters? (or whatever) it is so much easier to say 7 miles than
    11299.4 meters!'' You try to use each system for what it is good at and
    direct exact translations are NEVER convenient.
 
    So how would I answer Joe or any other person wondering whether it is
    worth while to learn C++?
 
    The real question is ``What do you want from a programming language?''
 
    For many programmers, C++ is simply much more fun than C or Pascal.
    This is important if you have to spend years programming. There are
    language that are even more fun for particular tasks or for particular
    parts of a programmer's work, but none, I think, that is as helpful
    over as broad a range of problems.
 
    For many, this ``fun'' comes from being able to express ideas more
    clearly, from being able to learn new concepts and techniques and apply
    them, from being relieved from some of the more tedious aspects of C
    and Pascal programming, and from a feeling of doing a better job.
 
    For many managers, the key to C++ has nothing to do with programming
    language constructs or programming. To them the decrease in maintenance
    cost (say, a factor two compared to C) is what they like.
 
    The question to ask the net is not ``What good is C++ in general?'' but
    ``what good is C++ relative to my particular needs?'' The former
    question can only be answered by generalities (usually somewhat vague),
    the latter can be answered by concrete arguments and examples, and can
    usually be backed up with references to the extensive literature about
    C++ and its use.
 
    So if you want to learn C++, first figure out why C++ might help you.
    Trying to learn C++ just because ``everybody uses in'' (not everybody
    does use C++ and not should use C++) or because someone promised you
    that ``it performs miracles'' (it doesn't) is silly. Unless you have a
    pretty good idea of what you want and how you are going to achieve it
    you'll most likely fail - in any language. 
 
    Next, be reasonable about your expectations. C++ delivers benefits
    proportionally to your understanding of the techniques you know how to
    use. You can use C++ as simply a better C and gain some benefits, but
    learning abstraction techniques and object-oriented programming is the
    way to greater benefits.
 
    To learn those techniques and their use with C++ you need a textbook,
    not just a manual or a superficial ``how to'' guide.
 
    There has - under various headings - been several related discussions
    about the proper way to learn C++, C++'s relation to C, C++'s relation
    to Smalltalk, the difference (or not) between data abstraction and
    object-oriented programming, etc.
 
    I think the practical concern underlying many of these discussions is:
 
	    Given that I don't have much time to learn new techniques
	    and concepts, how do I start using C++ effectively?
 
    It is clear that to use C++ ``best'' in an arbitrary situation you need
    a deep understanding of many concepts and techniques, but that can only
    be achieved through years of study and experiments. It is little help
    to tell a novice (a novice with C++, typically not a novice with
    programming in general), first to gain a thorough understanding of C,
    Smalltalk, CLOS, Pascal, ML, Eiffel, assembler, capability based
    systems, OODMBSs, program verification techniques, etc., and then apply
    the lessons learned to C++ on his or her next project. All of those
    topics are worthy of study and would - in the long run - help, but
    practical programmers (and students) cannot take years off from
    whatever they are doing for a comprehensive study of programming
    languages and techniques. 
 
    On the other hand, most novices understand that ``a little knowledge is
    a dangerous thing'' and would like some assurance that the little they
    can afford time to learn before/while starting their next project will
    be of help and not a distraction or a hinderance to the success of that
    project. They would also like to be confident that the little new they
    can absorb immediately can be part of a path that can lead to the more
    comprehensive understanding actually desired rather than an isolated
    skill leading nowhere further.
 
    Naturally, more than one approach can fulfill these criteria and
    exactly which to choose depends on the individual's background,
    immediate needs, and the time available. I think many educators,
    trainers, and posters to the net underestimate the imporatance of this:
    after all, it appears so much more cost effective - and easier - to
    ``educate'' people in large batches rather than bothering with
    individuals.
 
    Consider a few common questions:
 
	  o  I don't know C or C++, should I learn C first?
 
	  o  I want to do OOP, should I learn Smalltalk before C++?
 
	  o  Should I start using C++ as an OOPL or as a better C?
 
	  o  How long does it take to learn C++?
 
    I don't claim to have the only answers ``the (only) right answers'' to
    these questions. As I said the ``right'' answer depends on the
    circumstances. Most C++ textbook writers, teachers, and programmers
    have their own answers. For example, I seem to remember that the C++
    FAQ discusses these questions. My answers are based on years of
    programming in C++ and other languages, teaching short C++ design and
    programming courses (mainly to professional programmers), consulting
    about to introduction of and use of C++, discussing C++, and generally
    thinking about programming, design, and C++.
 
      > I don't know C or C++, should I learn C first?
 
    No. Learn C++ first. The C subset of C++ is easier to learn for C/C++
    novices and easier to use than C itself. The reason is that C++
    provides better guarantees than C (stronger type checking). In
    addition, C++ provides many minor features, such as the `new' operator,
    that are notationally more convenient and less error-prone than their C
    alternatives. Thus, if you plan to learn C and C++ (or just C++) you
    shouldn't take the detour through C. To use C well, you need to know
    tricks and techniques that aren't anywhere near as important or common
    in C++ as they are in C. Good C textbooks tends (reasonably enough) to
    emphasize the techniques that you will need for completing major
    projects in C. Good C++ textbooks, on the other hand, emphasizes
    techniques and features that lead to the use of C++ for data
    abstraction and object-oriented programming. Knowing the C++
    constructs, their (lower-level) C alternatives are trivially learned
    (if necessary).
 
    To show my inclinations:
 
	To learn C use:
 
		Kernighan and Ritchie:
		The C programming Language (2nd edition)
		Prentice Hall, 1988.
 
	as the primary textbook. To learn C++ use
 
		Stroustrup:
		The C++ programming Language (2nd edition)
		Addison Wesley, 1991.
 
    Both books have the advantage of combining a tutorial presentation of
    language features and techniques with a complete reference manual. Both
    describes their respective languages rather than particular
    implementations and neither attempts to describe particular libraries
    shipped with particular implementations.
 
    There are many other good textbooks and many other styles of
    presentation, but these are my favorites for comprehension of concepts
    and styles. It is always wise to look carefully at at least two sources
    of information to compensate for bias and possible shortcommings.
 
 
    > I want to do OOP, should I learn Smalltalk before C++?
 
    No. If you plan to use C++, learn C++. Languages such as C++,
    Smalltalk, Simula, CLOS, Eiffel, etc., each has their own view of the
    key notions of abstraction and inheritance and each support them in
    slightly different ways to support different notions of design.
    Learning Smalltalk will certainly teach you valuable lessons, but it
    will not teach you how to write programs in C++. In fact, unless you
    have the time to learn and digest both the Smalltalk and the C++
    concepts and techniques, using Smalltalk as a learning tool can lead to
    poor C++ designs.
 
    Naturally, learning both C++ and Smalltalk so that you can draw from a
    wider field of experience and examples is the ideal, but people who
    haven't taken the time to digest all the new ideas often end up
    ``writing Smalltalk in C++'' that is applying Smalltalk design notions
    that doesn't fit well in C++. This can be as sub-optimal writing C or
    Fortran in C++.
 
    One reason often quoted for learning Smalltalk is that it is ``pure''
    and thus force people to think and program ``object oriented.'' I will
    not go into the discussion about ``purity'' beyond mentioning that I
    think that a general purpose programming language ought to and can
    support more than one programming style (``paradigm'').
 
    The point here is that styles that are appropriate and well supported
    in Smalltalk are not necessarily appropriate for C++. In particular, a
    slavish following of Smalltalk style in C++ leads to inefficient, ugly,
    and hard to maintain C++ programs. The reason is that good C++ requires
    design that takes advantage of C++'s static type system rather than
    fights it. Smalltalk support a dynamic type system (only) and that view
    translated into C++ leads to extensive unsafe and ugly casting.
 
    I consider most casts in C++ programs signs of poor design. Some casts
    are essential, but most aren't. In my experience, old-time C
    programmers using C++ and C++ programmers introduced to OOP through
    Smalltalk are among the heaviest users of casts of the kind that could
    have been avoided by more careful design.
 
    In addition, Smalltalk encourages people to see inheritance as the sole
    or at least primary way of organizing programs and to organize classes
    into single-rooted hierarchies. In C++, classes are types and
    inheritance is by no means the only means of organizing programs. In
    particular, templates is the primary means for representing container
    classes.
 
    I am also deeply suspicious of arguments proclaiming the need to FORCE
    people to write in an object-oriented style. People who don't want to
    learn can, on average, not be taught with reasonable effort and there
    is in my experience no shortage of people who DO want to learn. Unless
    you manage to demonstrate the principle behind data abstraction and
    object-oriented programming all you'll get is inappropriate
    ``barouque'' misuses of the language features that support these
    notions - in C++, Smalltalk, or whatever.
 
    See ``The C++ Programming (2nd Edition)'' and in particular Chapter 12
    for a more thorough discussion of the relation between C++ language
    features and design.
 
 
     >  Should I start using C++ as an OOPL or as a better C?
 
    That depends. Why do you want to start using C++? The answer to that
    question ought to determine the way you approach C++; not some
    one-size-fits-all philosophy. In my experience the safest bet is to
    learn C++ ``bottom up,'' that is first learn the features C++ provides
    for traditional procedural programming, the ``better C'' sub-set, then
    learn to use and appreciate the data abstraction features, and then
    learn to use class hierarchies to organize sets of related classes.
 
    It is - in my opinion - dangerous to rush through the earlier stages
    because there is too high a probability of missing some key point.
 
    For example, an experience C programmer might consider the ``better C''
    subset of C ``well known'' and skip the 100 pages or so of a textbook
    that describes it. However, in doing so he might miss the ability to
    overload functions, the difference between initialization and
    assignment, the use of the `new' operator for allocation, the
    explanation of references, or some other minor feature in such a way
    that it will come back to haunt him at a later stage where sufficient
    new concepts are in play to complicate matters. If the concepts used in
    the better C subset are known the 100 pages will only take a couple of
    hours to learn and some details will be interesting and useful. If not,
    the time spent is essential.
 
    Some people have expressed fear that this ``gradual approach'' leads
    people to write in C style forever. This is of course a possible
    outcome, but nowhere as likely as proponents of ``pure'' languages and
    proponents of the use of ``force'' in teaching programming like to
    believe. The key thing to realize is that using C++ well as a data
    abstraction and/or object-oriented language requires the understanding
    of a few new concepts that have no direct counterpart in languages such
    as C and Pascal.
 
    C++ isn't just a new syntax for expressing the same old ideas - at
    least not for most programmers. This implies a need for education,
    rather than mere training. New concepts have to be learned and mastered
    through practice. Old and well-tried habits of work have to be
    re-evaluated, and rather than dashing of doing things ``the good old
    way'' new ways have to be considered - and often doing things a new way
    will be harder and more time-consuming than the old way - when tried
    for the first time.
 
    The overwhelming experience is that taking the time and making the
    effort to learn the key data abstraction and object-oriented techniques
    is worth while for almost all programmers and yields benefits not just
    in the very long run but also on a three to twelve month timescale.
    There are benefits in using C++ without making this effort, but most
    benefits requires the extra effort to learn new concepts - I would
    wonder why anyone not willing to make that effort would switch to C++.
 
    When approaching C++ for the first time, or for the first time after
    some time, take the time to read a good textbook or a few well chosen
    articles (the C++ Report and the C++ Journal contain many). Maybe also
    have a look at the definition or the source code of some major library
    and consider the techniques and concepts used. This is also a good idea
    for people who has used C++ for some time. Many could do with a review
    of the concepts and techniques. Much has happened to C++ and its
    associated programming and design techniques since C++ first appeared.
    A quick comparison of the 1st and the 2nd edition of ``The C++
    Programming Language'' should convince anyone of that.
 
 
       >  How long does it take to learn C++?
 
    Again, that depends. It depends both on your experience and on what you
    mean by ``learning C++.'' The syntax and basics for writing C++ in the
    better C style plus defining and using a few simple classes takes a
    week or two for a programmer. That's the easy part. The main
    difficulty, and the main fun and gain comes from mastering new design
    and programming techniques. Most experienced programmers I have talked
    with quotes times from a half year to one and a half year for becomming
    really comfortable with C++ and the key data abstraction and object-
    oriented techniques it supports. That assumes that they learn on the
    job and stay productive - usually by programming in a ``less
    adventurous'' style of C++ during that period. 
    
    If one could devote full time to learning C++ one would be comfortable
    faster, but without actual application of the new ideas on real
    projects that degree of comfort could be misleading. Object-oriented
    programming and object-oriented design are essentially practical -
    rather then theoretical - disciplines. Unapplied, or applied only to
    toy examples, these ideas can become dangerous ``religions.''
 
    Note that learning C++ is then primarily leaning programming and design
    techniques, not language details. Having worked through a good textbook
    I would suggest a book on design such as
 
		Grady Booch:
		Object Oriented Design with examples
		Benjamin Cummings 1990.
 
    which has the nice property of having longish examples in five
    different languages (Ada, CLOS, C++, Smalltalk, and Object Pascal) and
    is therefore somewhat immune to the language biogotry that mar some
    design discussions. The parts of the book I like best is the
    presentation the design concepts and the example chapters.
 
    Looking at design contrasts sharply with the approach of looking very
    carefully at the details of the definition of C++ - usually using the
    ARM
 
		Ellist&Stroustrup:
		The Annotated C++ Reference Manual
		Addison-Wesley, 1990
 
    which is a book containing much useful information, but no information
    about how to write C++ programs. A focus on details can be very
    distracting and lead to poor use of the language. You wouldn't try to
    learn a foreign language from a dictionary and grammar, would you?
 
    When learning C++, it is essential to keep the key design notions in
    mind so that one doesn't get lost in the language technical details.
    That done, learning and using C++ can be both fun and productive. A
    little C++ can lead to significant benefits compared to C, further
    efforts to understand data abstraction and object-oriented techniques
    yields further benefits.
 
	- Bjarne Stroustrup

This is a `special' issue on oop....

A commentary suggests that C++ is headed for the same fate as PL/I and Ada
due to its (increasing) complexity.  In .27, the first 10 paragraphs or so
emphasize that C++ is a complex language, takes effort to learn, and takes
time to learn.

My views on the world are that too many people in the computer business must
spend a the vast majority of their time figuring out what the problems are,
how to tackle the problems, how to fund them, etc., so that the actual task
of coding a solution is relatively speaking trivial.

How can the majority of people writing code afford to learn C++?

I think that the answer is that they can't and Microsoft appears to be
addressing that problem by `re-engineering' BASIC as a replacement for
spreadsheet macros, command scripts, and query language by imbedding it in
wordprocessors, databases, spreadsheets, application control and object
managers.

This isn't the thread to discuss BASIC or Microsoft's likelihood of success,
but it does suggest to me that there is a widening gap between the language
that `everyman' uses and the language of the `system implementor' uses.  Or
at least that there is a tendency to widen the gap as seen by PL/I, then Ada,
and now with C++.  Further, since the number of people coding in each group
of languages are so skewed in number, the ability to quickly implement
something is very high for a language like BASIC and virtually impossible
(to do quickly) in the strongly typed or object oriented languages.  With C++
the most common question seems to be `does anyone have header files for foo
that work with C++' and a similar problem exists for Ada although much more
support for Ada exists within the VMS environment.

    Re: .28:
    
>How can the majority of people writing code afford to learn C++?
    
       They can't.  The language is enourmous; ANSI C is pretty big, and it
    looks small and simple compared to C++.
    
       What I find scary is that it's easy to get C++ in the door because
    it's got a lot of attributes which help sell it to management
    (OO-ness, strong typing, "better C", etc.) but then when you get it in
    the door, unless you have a group of people who are well experienced in
    C++, you're going to have quite a time deciding *how* to use the
    language.
    
       Do you use multiple inheritance?  Templates?  Exceptions?  Do you
    always make your inheritance virtual?  Do you always make member
    functions virtual?  What about inlining?  What happens when you have
    enough overloadings of operator+ so that it's impossible to figure out
    just *what* piece(s) of code got executed in the statement:
    
    	a = b + c;
    
       ??
    
       C++ is, unfortunately, catching on more and more and we're going to
    be trying to manage the proliferation of bad C++ just like we have been
    trying to manage the proliferation of bad C for the past decade-plus. 
    I've personally lost hope on my language crusades of several years ago
    and am working in C and C++, and just trying to make sure that at least
    the boat I'm riding on doesn't topple over due to the complexity of the
    language.
    
>... Further, since the number of people coding in each group
>of languages are so skewed in number, the ability to quickly implement
>something is very high for a language like BASIC and virtually impossible
>(to do quickly) in the strongly typed or object oriented languages.  ...
    
       I don't personally believe that the strong typing or
    object-orientation are things that make Ada or C++ intimidating; it's
    the amount of things you have to wade through before you can start to
    be effective.  It's very easy to understand the jist of BASIC in a few
    minutes and become dangerous.  (Contrary to many researchers who feel
    that languages like C++, Dylan, Scheme, etc. are moving towards being
    more naturally how people want to express problem solutions, I think
    that being able to very simply express imperative statements is the key
    to simplicity and accessability.)
    
       OO Visual BASIC for Motif anyone?  Sign me up, either for the
    development team or to use the thing once it's written!
    
       (I find it interesting that our language strategy has focused on
    providing a top-notch retargettable code generator and a few
    world-class language implementations while clearly the single most
    important language/compiler released in the past few years is Visual
    BASIC.)
    
    					-mjg
    
    p.s.
    
       We're using C++ for an internal development effort.  We're using a
    strict subset of the language and have established a number of rules
    regarding the usage of language features.  (No multiple-inheritance, no
    operator overloading, all member functions are virtual, all data
    members are private, accessor functions for data members are the only
    functions which are inline, etc.)  So far, so good.  The language has
    enabled a formulation of a GUI program structure which is much more
    natural than a traditional C based one.
    
       The danger is going to be as more people outside the immediate
    effort (two of us currently) start to read, maintain and extend the
    code.  More language features are going to be applied and over time C++
    will allow what structure has been imposed through guidelines to be
    eroded away.
    
       I question the work that language designers have gone through to
    allow "normal looking" syntax invoke behaviours in non-obvious ways. 
    (For example, except for compiler developers and language lawyers, who
    really remembers all the operator precedences and various conversion
    rules in C and C++?  I don't -- I try to always explicitly convert and
    parenthesize if there is any potentially damaging ambiguity.)  oops,
    I'm starting to ramble, time to go home and sleep...
    
    

            .29

    on inheritance, it seems to me that this feature would introduce
    a bad case of coupling in the software, which i thought one of the things
    people wanted out of OO languages is to reduce this problem.

    no ?

    \nasser
    who_just_starting_to_learn_c++_becuase_I_heared_it_is_what_every_one_wants

    Re: .30:
    
       Nasser, could you try rephrasing your question?  I'm not sure what
    you're commenting upon.  (You say inheritance - are you talking about
    inheritance in general or the use of multiple inheritance or the
    practice of not using MI with C++?)
    
    					-mjg

        .31

    i probably mean the USING multiple inheritance will cause coupling.

    which type of coupling iam not sure, it just seems to just to be
    a bad one.

    would not multiple inheritance cause coupling to arise? not having
    programmed in it, (just read about it), it just seems to lead
    to coupling, which in general something one needs to avoid if
    at all possible.

    again, i dont want to open my mouth too big (is it too late?) because 
    as i said i don't know C++ that well, and only base this from what little
    i read on how inheritance work in C++.

    may be if you or someone else programmed allot more using MI in C++
    can commment on this.

    \nasser
    

    Re: .32:
    
       I personally find that design using MI is good -- mix-ins as they're
    called in CLOS are a good way to have small classes representing some
    kernel of functionality which can later be included into various
    classes, or describing some common property of a collection of classes. 
    
       The problem with MI and C++ is mostly related to grungy
    implementation issues.  IMO.  (From what I can see, using MI to just
    implement mix-ins seems reasonably safe, what gets complex is when
    someone tries to combine two non-trivial base classes.  Issues around
    down-casting, virtual inheritance, etc. get complex very quickly. 
    Granted, if you can memorize the ARM you can probably figure it all
    out, but I'd say that the benefit is rarely worth the effort.)
    
    					-mjg