Re: C/C++ does not exist!

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

jls@summit.novell.com (Schilling J.) writes:

 > What I'm interested in is the share of 
 > this (to me bogus) "C/C++" language that C++ has.  For instance, when you 
 > quote Borland C++ sales figures in D&E, that's for a combination product 
 > that many people may (or may not!) use only as a C compiler.  It's hard
 > to measure.  Similarly, the Novell UnixWare SDK now includes both C and C++ 
 > as standard items, so we have no direct way of measuring who's using what.

When I talk to people, most who claims to have used C++ on real projects
define classes and define virtual functions. People who use the various
graphics systems and foundation libraries of course use non-C parts of C++
extensively, but indirectly.

I have heard someone whose opinions I respect and who have
access to Borland support records claim that ``about 60% of C++ use
directly involves class definition and/or inheritance'' (i.e. not just
the use of library classes). My own observations from C++ projects within
AT&T and elsewhere indicates a much higher percentage of ``adventurous''
C++ use, but I don't make the mistake of assuming that my sample is
typical.

There is certainly a LOT of C++ as C use out there, but that is partly
because any significant fraction of a large number is itself a large
number. Another reason, is that many are working their way up the
learning curve so that early code will be very C-like. My experience,
however, is that people do get to use C++ features and techniques
well beyond the C level - as opposed to getting permanently stuck
at the C-level as is often (and sometimes wistfully) conjectured.

 > I'm not bringing this up in the context of the "C++ backlash", if such
 > a thing exists, but rather in the context of real resource allocation
 > issues:  for instance, what level of resources should Novell allocate
 > to the UnixWare C++ compiler and libraries, relative to other non-C++-
 > specific development environment features?  All I'm saying is that the
 > lumping together of C and C++ that happens in products and in peoples'
 > discussions of C++ makes assessing the C++ language share a more 
 > difficult task than for other languages.

Agreed, and sorry for mistaking you for a flamer.

My experience is that if you support C++ specific programming styles,
they will be used, and often used well. If you support C styles only,
you will minimize C++ specific techiques (and your productivity and
maintainability :-). The fact that C++ often gives significant
benefits even with poor tool support shouldn't deter people from
producing better tool.

	- Bjarne