🚀 go-pugleaf

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

: 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;
: 		// ...
: 		}

I hope you are kidding.  A true C programmer would use a look-up table
of functions:

f_table[p->type_field](p);

Or maybe simply a function pointer:

p->f(p); /* where f is declared as void (*f)(struct whatever *p) */

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

Even if C++ can be faster, those who learned C first are the only ones
likely to actually write C++ code that is faster than C code because
only they understand why certain C++ constructs are so slow.  It also
doesn't hurt to know assembly.

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

That is certainly true, both in C and C++.

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

Object-oriented design is useful for everyone, even C programmers.  As
for "part of the C subset of C++", there's no reason not to learn all
of it.  C++ contains virtually all of C.  The rest is obscure details,
mostly.

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

Yes, but "variety of styles" may very well include using purely the C
subset of C++.  Some C++ features are actually pretty stupid, like
the 'new' and 'delete' operators that correspond to 'malloc' and
'free' but lack anything corresponding to 'realloc'.

--
+----------------------------------------------+
|    Rainer Deyke (rainer@mdddhd.fc.hp.com)    |
| "The Earth shall inherit the meek" - Carcass |
+----------------------------------------------+