TITLE: Thoughts on ISO C++

[ Someone was knocking the committee approach to specifying
  the C++ standard. Here's Bjarne's response.

  -adc ]

AUTHOR: bs@research.att.com (Bjarne Stroustrup <9758-26353> 0112760) 1 Nov 95

In a FEW places, yes, but generally, what has been done to C++ during the
years of C++ standards work has been good. I'm very pleased with it.

My opinions can be found in some detail in ``The Design and Implementation
of C++.'' So can descriptions of all major C++ features and design decisions.

I think this longish quote from a recent article that I wrote for the C++
Report is relevant:

	Introduction

	As C++ programmers, we already feel the impact of the
	work of the ANSI/ISO C++ standards committee.
	Yet the ink is hardly dry on the first official draft
	of the standard.
	Already, we can use language features only hinted at in the ARM
	and ``The C++ Programming Language (second edition),''
	compilers are beginning to show improved compatibility,
	implementations of the new standard library are appearing, and the
	recent relative stability of the language definition is allowing
	extra effort to be spent on implementation quality and tools.
	This is only the beginning.

	We can now with some confidence imagine the post-standard C++ world.
	To me, it looks good and exciting. I am confident that it will give
	me something I have been working towards for about sixteen years:
	a language in which I can express my ideas directly; language
	suitable for building large, demanding, efficient, real-world systems;
	a language supported by a great standard library and effective tools.
	I am confident because most of the parts of the puzzle are already
	commercially available and tested in real use.
	The standard will help us to make all of those parts available to
	hundreds of thousands or maybe even millions of programmers.
	Conversely, those programmers provide the community necessary to
	 support further advances in quality, programming and design
	techniques, tools, libraries, and environments.
	What been achieved using C++ so far have exeeded my wildest dreams
	and we must realistically expect that the best is yet to come.

	The Language

	C++ supports a variety of styles.
	In other words: C++ is a multi-paradigm programming language.
	The standards process strengthened that aspect of C++ by providing
	extensions that didn't just support one narrow view of programming,
	but made several styles easier and safer to use in C++.
	Importantly, these advances has not been bought at the expense of
	run-time efficiency.

	At the beginning of the standards process templates were considered
	experimental; now they are an integral part of the language,
	more flexible than originally specified, and an essential foundation
	for standard library. Generic programming based on templates is now
	a major tool for C++ programmers.

	The support for object-oriented programming (programming using class
	hierarchies) was strengthened by the provision for run-time type
	identification, the relaxation of the overriding rules, and
	the ability to forward declare nested classes.

	Large-scale programming -- in any style -- received major new support
	from the exception and namespace mechanisms.
	Like templates, exceptions were considered experimental at the
	beginning of the standards process.
	Namespaces evolved from the efforts of
	many people to find a solution to the problems with name clashes and
	from efforts to find a way to express logical groupings to complement
	or replace the facilities for physical grouping provided by the
	extra-linguistic notion of source and header files.

	Several minor features were added to make general programming safer and
	more convenient by allowing the programmer to state more precisely the
	purpose of some code. The most visible of those are the bool
	type, the explicit type conversion operators, the ability to declare
	variables in conditions, and the ability to restrict user-defined
	conversions to explicit construction.

	A description of the new features and some of the reasoning that led to
	their adoption can be found in D&E. o can discussions of older features
	and of features that were considered but didn't make it into \*C.

	The new features are the most visible changes to the language.
	However, the cumulative effect of minute changes to more obscure
	corners of the language and thousands of clarifications of its
	specification is greater than the effect of any extension.
	These improvements are essentially invisible to the programmer
	writing ordinary production code, but their
	importance to libraries, portability, and compatibility of
	implementations cannot be overestimated.
	The minute changes and clarifications also consumed a large
	majority of the committee's efforts.
	That is, I believe, also the way things ought to be.

	For good and bad, the principle of C++ being ``as close to C
	as possible -- and no closer'' was repeatedly re-affirmed.
	C compatibility has been slightly strengthened, and the remaining
	incompatibilities documented in detail.
	Basically, if you are a practical programmer rather than a conformance
	tester, and if you use function prototypes consistently,
	C appears to be a subset of C++. The fact that every example in K&R2
	is (also) a \*C program is no fluke. 

	Coherence

	ISO C++ is not just a more powerful language than the \*C presented in
	``The \*C Programming Language (second edition);'' it is also more
	coherent and a better approximation of my original view of what
	C++ should be.

	The fundamental concept of a statically typed language relying on
	classes and virtual functions to support object-oriented programming,
	templates to support generic programming, and providing low-level
	facilities to support detailed systems programming is sound.
	I don't think this statement can be proven in any strict sense,
	but I have seen enough great C++ code and enough sucessful
	large-scale projects using C++ for it to satisfy me of its validity.

	You can also write ghastly code in C++, but so what?
	We can do that in any language.
	In the hands of people who have bothered learning
	its fairly simple key concepts, C++ is helpful in guiding
	program organization and in detecting errors.  

	C++ is not a ``kitchen sink language'' as evil tongues are fond
	of claiming. Its features are mutually reinforcing and all have a
	place in supporting C++'s intented range of design and programming
	styles. Everyone agrees that \*C could be improved by removing
	features. However, there is absolutely no agreement which features
	could be removed. In this, C++ resembles C. 

	During standardization, only one feature that I don't like was added.
	We can now initialize a static constant of integral type with a
	constant expression within a class definition.
	For example:

		class X {                             // in .h file
			static const int c = 42;
			char v[c];
			// ...
		};

		int X::c = 42;                        // in .c file

	I consider this half-baked and prefer:

		class X {
			enum { c = 42 };
			char v[c];
			// ...
		};

	I also oppose a generalization of in-class initialization as an
	undesirable complication for both implementors and users.
	However, this is an example where reasonable people can agree
	to disagree. Standardization is a democratic process, and I
	 certainly don't get my way all the time -- nor should any person
	or group.

The paper is called ``A perspective on ISO C++'' and the rest of the paper
- the main bulk - is code examples illustrating my points above.

ISO C++ is a better language than the language I provided as the starting
point for the committee. However, no major feature that was outside the set
I considered suitable for C++ long before standardization was considered
was added. Furthermore, as the chairman of the standard's committee's
working group for extensions, I worked on every proposed extension and
was a major contributor to every major extension.

No language is perfect, of course, and the committee made a few mistakes
but so did when I didn't have a committee to help and distract me. So I
would have if I had had a few more years to polish C++ before the start
of standardization.

It is healthy and proper for a programming language to grow based on
experiment, use, and discussion. This C++ did, and the standards committee
was a major focus for that work. C++ didn't grow randomly, it grew within
my view of what it was supposed to be.

	- Bjarne