🚀 go-pugleaf

	Oh well,  this should can my arguments...  :-)

Bjarne Stroustrup <9758-26353> 0112760 (bs@research.att.com) wrote:

: douvilld@Cognos.COM (Derek Douville) writes:

:  > Is anyone with some common sense actually following this thread?  You people

	Obviously...

: I am always loath to argue with anyone manning a help desk (see Derek's
: signature at the bottom), after all such people are at the receiving end
: of a wide variety of trouble. However, several of the opinions stated
: don't agree with my experience, and I know that some of the certainty
: expressed cannot be realistic. After all, many, many people have learned
: C++ successfully both with and without previous C experience.

	Well,  your experience with these two languages out does mine to
date.  I wouldn't debate the fact that many people have learned C++
without prior knowledge of C;  this is entirely feasible,  and has
its advantages in a C++ only environment.

:  > First of all,  you cannot fully understand or appreciate the C++ language
:  > (or any language) unless you know something about its roots.  This is
:  > why linguists studying english will require Latin, French, and Spanish
:  > to name a few.

[snip] 

: That said, I agree. You cannot fully understand anything without
: understanding its roots. Knowledge of how C++ came about will make
: someone a significantly better programmer. That is one of the reasons

	Yes,  this is the main perspective of my argument,  that knowing
the roots of where something came from will offer an insight into 
many areas.

: I wrote D&E:

: 	The Design and Evolution of C++
: 	Addison-Wesley ISBN 1-201-54330-3

: It makes that kind of information more accessible.

	Actually,  I was digging in there for a quote to use as 
reference tonight before I came upon your message...  :-)

:  > Secondly,  the original C++ "compilers" weren't compilers
:  > at all.  Stroustrup had written the Cfront pre-compiler,  which basically
:  > parsed the C++ and simplified it into C code.
: I must disagree. Cfront is/was a compiler front-end doing what all compiler
: front-ends do: complete syntactic and semantic analysis plus complete error
: checking and error reporting. That done, they output something that drives
: a code generator. The fact that most versions of Cfront generated  as their
: code-generator input doesn't make them less real as a compiler. In fact,
: for years Cfront-based C++ compilers outperformed several ``native'' C++
: compilers in compile-time and/or speed of the executable produced.

	Ah,  I stand corrected.  I misinterpretted your description on page
66 as more of a pre-processor to the compiler,  rather than a compiler
in itself.

[snip]	
:  > One cannot fully apreciate the advanced organizational features of C++
:  > until they've programmed in C.  But this isn't just about apreciation
:  > and history,  its about understanding the complexity of what is going
:  > on behind the scenes.

: I beg to differ. Many people appreciate the organizational features of C++
: without having programmed in C. It is possible to appreciate organizational
: features based on principles and experience with any mainstream
: programming language. It is possible to appreciate what is going on
: ``behind the scenes'' based on knowledge of how computers work and based
: on experience with, say Pascal. Some knowledge of C can be useful, but
: that knowledge need not be in excess of knowledge of the C subset of C++.

	Would you not agree that because C or Pascal are a level closer to 
assembly,  and that because C requires more effort on the part of the
programmer compared to the higher-level syntax of C++,  that the
programmer's understanding of how the machine and operating system
functions is that much better?  I enjoyed writing the tedious functions,
and making my own memory handling routines.  I feel that it taught me
a lot of how objects and data got around in the invisibleness of the
computer.  Though I am now finding myself thinking on the plane of
"objects and classes",  I would tend to also think that many of C++'s
simplified way of doing things would obscure the "behind the scenes"
of it all.

	For the beginner --  and this probably concedes to your closing
remarks -- this obscuring of the complexities is great.  However,
as I maintain,  knowing the roots has its advantages.  When one
understands a little bit of what is happening on the lower levels of
a computer or operating system,  one begins to be concerned with
memory management,  code reusability and speed;  all these things
matter when coding larger applications.  I found that the "tediousness"
of C (or Pascal's clumsy style) offered me insight and apreciation
for the organizaion of C++ as well as what really goes on at run-time.

	Perhaps I'm still a procedural thinker.   ;-)

:  > Using operators like C++'s  'new' to allocate
:  > memory obscures the fact that a void pointer is being returned to
:  > pre-initialized memory.  The string class library can be broken down
:  > into all the good old C functions,  plus added code to increase function-
:  > ality.  Overloading operators is great,  but what do you think happens
:  > to the C++ code when this is done?  The assembly looks the same.

:  > With the understanding of C,  I have no doubt that one's C++ programs
:  > will be more powerful,  and all of the features will be used more
:  > wisely.

: I suspect you are right in one way, that is, that unless you understand
: the basics - say the C subset of C++ - you can misuse and misunderstand
: the more advanced features grossly. However, a mindset focussed on the
: bits, bytes, and pointers can lead to a misguided avoidance of more
: advanced features where they are most appropriate. I have seen many people
: write switch statements followed by function calls out of fear of the
: supposed ovehead of derived classes and virtual functions.  The fact of
: the matter is that

: 		p->f();  // invoke some virtual function

: is typically both organizationally superior and faster than:

: 		switch (p->type_field) {
: 		case A:
: 			A_f(p);
: 			break;
: 		case B:
: 			B_f(p);
: 			break;
: 		// ...
: 		}

:  > Also,  fo straight-forward programs that are NOT complex,
:  > C++ has no place replacing C.  

: I disagree. Most programs are written faster, safer, cleaner, and as
: efficiently in run-time and space in the C subset of C++ than in a style
: that takes advantage of non-C++ features of C. This is not as strong
: a statement as it might appear: Remember that every example in K&R2
: (my favirite C book) is a C++ program. In addition, most programs - even
: 200 line ones - benefit from the use of at least some non-C C++ features
: (e.g. virtual functions, function overloading, operator new) or libraries
: (e.g. a string or an STL map).

	I have never argued run-time speeds and such,  only the 
simplicity of the code.  I suppose I may be confusing procedural
vs. object-oriented techniques with the implimentation of the C++ syntax
vs. C syntax.  In which case,  that is entirely another debate. 

:  > If we want to talk speed,  C++ is slower than hell with so much over-
:  > head,  all because of the iostream.h header,  which for a small pro-
:  > gram pulls in thousands of lines of code.

: I have measured C++ and C extensively. C++ code is not inherently slower
: or larger than C code. It can appear to be when comparing a C++ and a C
: compiler with different code generation strategies or different optimization
: settings, but there is no inherent differences. I have also seen examples
: where the code generated by a C++ compiler outperformed the code generated
: by a C compiler. You can no more conclude that C is ``slower than hell''
: from such examples than you can conclude the opposite from equally flawed
: measurements with the opposite result.

: Blaming iostreams is also a mistake (though some iostream implementors
: appears to have failed to provide the basic optimizations necessary to
: avoid the impression).

	I had meant to clarify that point before my (following) example:
Run-time code at execution speeds will be the same.  However,  C++
compilation will be slower than the comparable C program.  For large
applications,  on the other hand,  this is not an issue.

:  > eg.  -----------
:  >  #include <stdio.h>
:  > 
:  >  void main()
:  >  {
:  >      printf("\nHello World\n");
:  >  }
:  >   ----------
:  > 
:  > will execute just as quickly as
:  > 
:  >  #include <iostream.h>
:  > 
:  >  void main()
:  >  {
:  >      cout << "\nHello World\n";
:  >  }
:  > 
:  >  --------
:  > but the compile time for the C++ program will be twice as long (this
:  > is a guess).  Which makes more sense?

: I just compiled those two programs four times each. The iostreams version
: compiled on average 40% slower. Had I use pre-compiled headers there would
: have been no difference.

[snip]
: Also, I was using a poor implementation of iostreams so that the size of
: the resulting program was larger. That is not necessary, the implementation
	Excuses,  excuses.  :-)

[snip]

:  > Further more,  if C++ is used
:  > properly,  it is implimented in an object oriented way.

: Whatever that may mean (definitions differ). I see what I consider good
: (that is reasonably easily written, reasonably maintainable, and resonably
: efficient) C++ code written in a variety of styles.

	Right you are. My statement was based on my favorite C
reference, QUE's "USING C", by Lee Atkinson and Mark Atkinson, 1991.
Right now,  that's out in the car,  so I'll quote from QUE's 1993
Special Edition (Revised), page 573:

	In the real world data-processing shop,  structured programming has
	proven inadequate for coping with ever larger and more complex pro-
	grams...

	Consider also,  whether you actually need object-orientation before
	taking on another project.  For the reasons just discussed, you
	don't need OOPS (including C++) unless the project will be large 
	and complex...  If there is no real complexity,  all you ac-
	complish by using these tools,  is,  ironically,  a needlessly
	complex program!	

Whether or not this last statement is true,  this is how I have come 
to associate C as a procedural language (which it is),  and C++
as an Object Oriented language (with the ability to be used as a 
procedural).  Once again,  this may be me confusing methodology with
language specifics.
	
[snip]
:  > So,  why do I argue that C should be learned as a foundation?  Be-
:  > cause it's fundamental.  It teaches one how the computer thinks.
:  > Take one of those fancy string functions you get in C++ and do it
:  > in C yourself.  You'll be amazed at the skills you require.  In
:  > addition,  when you go into the work place,  chances are you'll
:  > require knowledge of C to debug something or create a patch (bug
:  > fix).  Or you'll be translating some older code into C++.  There's
:  > many reasons to learn C.  It's the key player in C++ as a language.

: The key C features are also key C++ features. In that sense you need
: to learn them to learn C++. Every complete C++ book will explain the
: basics of structures, pointers, functions, etc. The question is in
: what context they are presented and with which emphasis. I claim that
: many C features are better taught within the conceptual framework of C++,
: and that much C teaching place an unhealthy emphasis on minor technical
: details and clever tricks. (so does some C++ teaching, but that is simply
: the same mistake repeated and not an excuse).

	However,  a major concept (like a linked list, for example) 
is essential, and should be taught as a concept uncluttered by the 
other features of the language -- tedious,  essential, or whatever.

: I suspect that many discussions about learning C and C++ are confounded
: by people faiing to distinguish between:

: 	Learning C and learning the C subset of C++.
: 	Learning C++ and learning object-oriented design.

	Yes,  a mistake I had obviously made in several points.

: I think that to be effective with C++, you need to learn part of the C
: subset of C++ and some object-oriented design. 

: We can of course have another and more detailed and possibly more
: constructive discussion of what ``part of'' and ``some'' in the previous
: sentense should mean. We should remember, though, that different people
: learn in different ways and that different people have different needs
: - occationally, radically different. Also, people have succeeded and
: will continue to succeed with C++ using very different approaches.

:  > And spend more than one day.  You can't learn how to pick your nose
:  > properly in one day.

: You definitely need to spend more than a day - more than a month more
: likely - to learn the C subset of C++.

:  >  Take a good book (like QUE's _USING_C/C++_,
:  > Special Edition) and learn C.  Read it for two weeks and simply 
:  > absorb what you can.  Then grab the Waite Group's book and read it
:  > cover to cover.  Program in both.  You'll be so glad you did.

: Learn C++, program in a variety of styles, focus on concepts and general
: techniques, don't go into the more obscure details ofd C or C++ until you
: have to. You'll be glad you did.

	That's it.  I'm calling up Brian and Denis for some backup here...

		:-)

	A good debate.