🚀 go-pugleaf

douvilld@Cognos.COM (Derek Douville) writes:

 > Is anyone with some common sense actually following this thread?  You people
 > have it all bass-ackwards.  First of all,  none of you obviously have read
 > up on the roots of C++ and how it came to be.  If you think BCPL->C->C++
 > is the answer,  then think again.

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.

 > 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.

You can get a perfectly good working knowledge of English without learning
Latin, French, or Spanish. In some ways you will even be better off not
knowing those languages. I agree that I would expect an expert in English
language and literature (or a serious linguist) to have a broad and thorough
understanding of related languages and cultures, but that is not a
requirement I would place on more users of English.

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
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.

 > 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.

 > Anything you can write in
 > C++ can be written in ANSI C (save implimentation dependant standards).

Indeed. Everything you can write in C++ you can write in C (if you have
sufficient time and patience) and everything you can write in C you can
write in assembler (if you have even more time and patience). So what?

 > 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++.

 > 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).

 > 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).

 > 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.

However, there is a reality to this impression of compile-time overhead
for C++. On average, C++ programs rely more on information in header files
than C programs, and many C++ programmers have yet to learn that the
(often C-derived) habit of simply #including everything is a bad strategy.
You need to express the logical structure of a program through the
information made available to parts of a program through #includes.

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
of iostreams shipped with Cfront yields a smaller executable than the
stdio version. With minimal effort the size of the iostream and the
stdio versions of hello world could be made identical (and small) in
every implementation.

 > 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.

 > If you are
 > writing a quick 200 line procedural program,  it might as well be
 > done in C.

I find that for a 200 line program the decrease in the number of compiles
and the decrease in debugging that is the result of using C++ outweighs
any increases in individual compile times. Sometimes, I also have C++
libraries that are a significant help. In my experience, most 200 line
programs (except test cases) rely critically on some library.

 > For those of you who think learning C++ will teach you C,  you're dead
 > wrong.  Not in a million years.  You actually can learn all of the C++
 > libraries and principals without a knowledge of C programming,  but
 > it's not the other way around.  The Waite Group's _Object_Oriented_
 > Programming_In_Turbo_C++_ by Robert Lafore states,
 > 
 > 	You do not need to know the C language to use this book.  Many
 > 	books on C++ assume that you already know C,  but this one does
 > 	not.  It teaches C++ from the ground up.  If you do know C,  it
 > 	won't hurt,  but you may be surprised at how little overlap there
 > 	is between C and C++.
 > 
 > [Page xxi, Published 1991]
 > 
 > However, QUE's _USING_C_ by Lee Atkinson & Mark Atkinson contradicts
 > this by stating,
 > 
 > 	If you have no prior experience with C programming,  we urge you
 > 	to stop reading right now,  go back to the beginning of this book,
 > 	work your way through it,  write lots of practice code,  and 
 > 	master that material thoroughly.  If you do not,  you will be 
 > 	quickly and utterly lost.
 > 
 > [Page 685, 1st Edition, Published 1990.  Revised in '93]
 > 
 > I have read both of these cover to cover.  In my opinion,  one does
 > not need to know C to learn C++;  the Robert Lafore wrote an ex-
 > cellent tutorial.  Lee Atkinson & Mark Atkinson took a different
 > approach in that C++ was a tool to build on C.  I disagree, also.
 > 
 > 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).

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.

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.

	- Bjarne

 > Derek Douville
 > Technology Support Services
 > Cognos Help Desk, Ottawa