bs@alice.att.com (Bjarne Stroustrup)
Re: C++ Language Extensions
9 Jun 93 19:36:46 GMT
AT&T Bell Laboratories, Murray Hill NJ
Newsgroups: comp.lang.c++,comp.std.c++
References: <25697@alice.att.com>
Why Consider Laguuage Extensions?
Bjarne Stroustrup
AT&T Bell Laboratories
Murray Hill, New Jersey 07974
_A_B_S_T_R_A_C_T
This paper presents a personal view of the prob-
lem of stability vs extensions when using and
standardizing C++. To provide background, I first
describe the general aims of C++ standardization
and round off the discussion with a description of
the current state of affairs as it relates to
extension proposals.
_1 _S_t_a_n_d_a_r_d_i_z_a_t_i_o_n _o_f _C++
Formal standardization of C++ started in December of 1989
when the ANSI C++ committee, X3J16, was formed. The initia-
tive came from IBM, DEC, and HP and was supported by AT&T.
In June 1991 the effort became officially international with
the creation of the ISO SC22-WG21. Thus a single US
national and international C++ standard will emerge.
_W_h_y _s_t_a_n_d_a_r_d_i_z_e _C++?
There are many independently developed C++ implementations.
Therefore, we need a complete and mutually agreed upon defi-
nition of the language. Otherwise, each user will be locked
into a single ``C++'' implementation which will be incompat-
ible with other ``C++'' implementations. Also, the emerging
C++ libraries industry would face serious problems trying to
supply users on divergent implementations.
In the early years, I acted as a clearing house for infor-
mation and as the keeper of the manual. In the longer term
that was not acceptable to me or to the C++ community. It
became unacceptable to me because it involved too much work
for an individual, and unacceptable to the community because
you simply can't have major segments of the programming com-
munity directly dependent on a single individual
however well meaning and trustworthy. For similar reasons,
control by a single company is unacceptable. Being the
keeper of the definition of a widely used programming lan-
guage is the job of a standards body operating under well-
defined and legally accepted rules.
It appears that many organizations recognize this in the
form of rules that require software to be written in
June 9, 1993
- 2 -
languages that are standardized or ``under standardiza-
tion.'' Thus the very start of a standards process makes a
language acceptable. This surprised me when I first heard
of such rules, but I have come to conclude that ``under
standardization'' is indeed a reasonable criteria. The very
creation of an officially responsible body provides a degree
of protection against accidents or attacks of deviousness
that might befall an individual or a company.
A standards body can act as a forum for debate and for
dissemination of ideas. That, in my opinion, is the most
important role of the standards committee. Many members
have consciously tried to ensure that the C++ committee was
effective in this role. For example, a standards committee
is not obliged to publicize its activities beyond a few
rather ineffective official channels. However, many indi-
vidual members of the C++ committees have made serious
efforts to make the concerns and considerations of the com-
mittee public and bring the views of the user community back
to the committee.
_W_h_y _o_p_p_o_s_e _s_t_a_n_d_a_r_d_i_z_a_t_i_o_n _o_f _C++?
Given these good reasons, why would anyone think standard-
ization of C++ a bad idea or consider the process is fraught
with danger?
The language is still evolving and a large standards com-
mittee is not an ideal forum for language design. The dan-
ger is ``design by committee;'' that is, the danger of los-
ing a coherent view of what the language is and ought to
evolve into in favor of political deals over individual fea-
tures and resolutions.
A committee can easily fall into the trap of approving a
feature just because someone insists it is essential. It is
much easier to say `yes' than to say `no.' Also, it is
always easier to argue for a feature than to argue that the
advantage of the feature which will be very plausible in
all interesting cases is outweighed by nebulous concerns of
coherence, simplicity, stability, difficulties of transi-
tion, etc. Also, the way language committees work does not
seem to lend itself well to arguments based on experimenta-
tion and experience-based reasoning. I'm not quite sure why
this is, but maybe the committee format and resolution by
voting favor arguments that are more easily digested by
tired voters and members oversaturated with information. It
also appears that logical arguments (and sometimes even
illogical arguments) are more persuasive than other people's
experience and experiments.
Thus, ``standardization'' can become a force for instabil-
ity. The results of such instability can be a change for
the better, but there is always the danger that it might
become random change or change for the worse. To avoid
this, standardization has to be done at the right stage of a
language's evolution after its path of evolution has been
clearly outlined and before divergent dialects supported by
powerful commercial interests has emerged. I hope this is
June 9, 1993
- 3 -
the case for C++ and that the committee will continue to
show the necessary restraint.
These concerns are valid, and doubly relevant to concerns
about extensions. However, the arguments in favor of stan-
dardizations were accepted by most so standardization began
and we are beginning to see results. Continuous vigilance
is needed to ensure that ``design by committee'' doesn't put
its stamp on C++.
_A_i_m_s _o_f _C++ _s_t_a_n_d_a_r_d_i_z_a_t_i_o_n
The charter of the standards committee is ``to standardize
existing practice.'' This involves producing a document
that describes C++ and is more
precise
comprehensive
comprehensible
than the current manual (the ARM). That sounds easy, but
anyone who has looked seriously at standards will know that
the effort is much harder than it sounds and fraught with
both technical and political pitfalls.
In addition, the work has to be done in a timely manner to
serve the needs of the user community. The original aim was
to produce a draft for public review somewhere near the end
of 1993. The current schedule calls for a draft for public
review September 1994. I don't see any technical reason why
we shouldn't meet that.
_W_h_a_t _d_o_e_s ``_c_o_m_p_r_e_h_e_n_s_i_v_e'' _i_m_p_l_y?
No two people seem to agree, but I suggest the following
guidelines:
[1]Complete description of the language as currently used.
[2]Standard libraries.
[3]Enough features for real users.
[4]Good enough for ``tomorrow.''
Even point [1] can be controversial! Accepting it precludes
``improving'' the language by making significant incompati-
ble changes and there are always people of suggesting ``fix
it now before it is too late most C++ code is yet to be
written!'' Often, pointing out that tens of millions of
lines of C++ production code already exist convinces people
that significant incompatible changes are infeasible but
not always. Some take this as an added proof that a change
say banning the C array construct is urgently needed. Not
everyone realizes that an unrealistic standard will simply
be ignored because the standards bodies have no power to
enforce their rules. There are no shortage of examples of
standards that had been ignored some deservedly so.
The C++ committee's decision to look at library classes
such as Bitset, Array, and String that are in common use,
but not in a standard form was popular but by no means unan-
imous. Some consider the provision of standard libraries
desirable but unachievable because the design of a good
library can be as hard as the design of a good programming
language. I consider this observation valid, but not a
June 9, 1993
- 4 -
sufficient argument to refrain from trying. There is a dis-
proportionate advantage in standardizing a few frequently-
used relatively low-level classes. Grandiose schemes, on
the other hand, are completely beyond the abilities of the
committee.
_2 _E_x_t_e_n_s_i_o_n_s
Unless a language is unusually complete and the work of an
unusually farsighted designer there will be a need to amend
its definition during the standardization period. Our prob-
lems and our understanding will have evolved since the first
definition of the language and by the end of the standard-
ization an unchanged language may be the solution to
yesterday's problems only. By standardizing a language you
freeze the set of features available to many users.
Some programmers are willing to make their own extensions,
and some are willing to use extensions supplied by others.
Many, however, are by choice or by various rules restricted
to use the features specified in a standard. Thus it
becomes critical that the language specification doesn't
contain glaring omissions that prevent a user from doing
something essential. This is a non-trivial task that
becomes even harder as the areas of application increase
with time. One way of understanding the continuing demand
for extensions is to see it as part a wish to repair known
deficiencies and part a response to new application areas.
_M_a_n_d_a_t_e_d _e_x_t_e_n_s_i_o_n_s
Two extensions were ``mandated;'' that is, specified in the
proposal for standardization as additions to be made:
Templates.
Exception handling.
The presence of mandated extensions implied that an absolute
policy of ``no extensions'' was not an option. In my opin-
ion opening the door for the discussion of extensions was an
important and correct action. Dealing with extensions in
the context of a standards group is not easy though, or
without dangers.
_P_r_o_b_l_e_m_s _w_i_t_h _G_o_o_d _E_x_t_e_n_s_i_o_n_s
Even good extensions cause problems. Assume for a moment
that we have an extension that everybody likes so that no
time is wasted discussing its validity. It will still
divert implementor efforts from tasks that some people will
consider more important. For example, an implementor may
have a choice of implementing the new feature or implement-
ing an optimization in the code generator. Often, the fea-
ture will win out because it is more visible to users.
An extension can be perfect when viewed in isolation, yet
flawed from a wider perspective. Most work on an extension
focuses on its integration into the language and its inter-
actions with other language features. The difficulty of
this kind of work and the time needed to do it well is
invariable underestimated.
June 9, 1993
- 5 -
Any new features makes existing implementations outdated.
They don't handle the new feature. This implies that users
will have to upgrade, live without the feature for a while,
or manage two versions of a system (one for the latest
implementations and one for the old one). This latter is
especially the case for library and tool builders. For
example, adding a new feature based on a novel syntactic
construct will require updating tools such as syntax based
editors.
Teaching material will have to be updated to reflect the
new feature and maybe simultaneously reflect how the lan-
guage used to be for the benefit of users that haven't yet
upgraded.
These are the negative effects of a ``perfect'' extension.
If a proposed extension is controversial it will soak up
effort from the committee members and from the community at
large. If the extension has incompatible aspects these may
have to be addressed when upgrading from an older implemen-
tation to a new one sometimes even when the new feature
isn't used. The classical example is the introduction of a
new keyword. For example, this innocent looking function
void using(T* namespace) { /* ... */ }
will break when the features of the namespace proposal are
introduced because using and namespace are new keywords. In
my experience, though, the introduction of new keywords cre-
ates few problems and those are easily fixed. When, as an
experiment, we introduced using and namespace into a local
implementation without any announcement nobody actually
noticed their presence.
In addition to the very real problems of getting a new
feature accepted and into use, the mere discussion of exten-
sions can have negative effects by creating an impression of
instability in the minds of some users. Many users and
would-be users do not understand that changes are carefully
screened to minimize effects on existing code. Idealistic
proponents of new features often find the constraints of
stability and compatibility with both C and existing C++
hard to accept and rarely do much to allay such fears.
Also, enthusiastic proponents of ``improvements'' often
overstate the weaknesses of the language to make their
extensions look more attractive.
_P_r_o_b_l_e_m_s _w_i_t_h ``_N_o _E_x_t_e_n_s_i_o_n_s?''
What happens if you adopt a policy of ``no extensions?''
On the positive side, you don't waste any time discussing
extensions in the standards committee and you don't add
ill-defined or unneeded extensions. This in theory gives
more time to work on other issues. However, this added
effort in other areas only manifests itself provided every-
one actually agrees that extensions are not needed. Realis-
tically, people who consider extensions important will
devote their efforts to designing and implementing solutions
to their problems whatever a committee decides. The only
June 9, 1993
- 6 -
difference is that the work is no longer done in the public
forum of the standards committee. The energy formerly
devoted to extensions is diverted into the production of
products and dialects. It doesn't go away, because the
problems that generate the ideas for extensions don't just
go away.
On the other hand, people will manage even without exten-
sions. Proponents of language features tend to forget that
it is quite feasible to build good software without fancy
language support. No individual language feature is
_n_e_c_e_s_s_a_r_y for good software design, not even the ones we
would hate to be without. Good software can be and often is
written in C or in a small subset of C++. The benefits of
language features are in the convenience of expressing
ideas, the time needed to get a program right, the clarity
of the resulting code, and the maintainability of the
resulting code. It is not an absolute ``either or.'' More
_g_o_o_d code has been written in languages denounced as ``bad''
than in languages proclaimed ``wonderful;'' much more.
However, if we lack the ability to express something fun-
damental, the workarounds used will look more and more ugly
as our understanding the concepts improve. As time goes by,
code that looked reasonable becomes less acceptable in light
of newer insight. Consequently, a relatively unsupported
concept will become the object of a campaign for a language
extension and also the source of techniques, tools, and
#pragmas as programmers and suppliers adapt to the new
insight.
Such tools and techniques are appropriate in some areas
because no language can directly support every design level
concept, but they can become a burden and a source of de
facto dialects. For example, code depending on special
scaffolding to provide run-time type information or to avoid
clashes between global names will typically not work
together with code using a different scaffolding for those
purposes. Worse, if non-trivial tools are relied upon, such
as a powerful macro processor or a #pragma that affects the
semantics of a program, then we have language dialects that
are most insidious because they are often not recognized as
dialects.
Other effects of a ``no extensions'' policy would be less
tangible, but probably not less real. The excitement many
people feel by being able to apply new techniques effec-
tively and being part of an effort to genuinely improve the
lot of programmers would evaporate. Basically, if we
unwilling were to consider new facilities people will look
elsewhere for improvements beyond the current state of C++.
Also, despite paying lip service to minimalism and stabil-
ity many people _l_i_k_e new features. Language design is
intrinsically interesting, the debates about new features
are stimulating, and they provide a good excuse for new
articles and releases. Some features might even help pro-
grammers, but to many that seems a secondary motivation. If
ignored, these factors can disrupt progress. I prefer them
June 9, 1993
- 7 -
to have a constructive outlet.
_L_i_b_r_a_r_i_e_s
More often than people realize, designing a library is a
better than adding a language feature. Classes can repre-
sent almost all the concepts we need. Where needed, special
semantics or exceptional performance can be implemented by
coding functions in languages other than C++. An example of
this is libraries providing high-performance vector opera-
tions through (inlined) operator functions that expand into
code tuned to vector processing hardware.
Since no language can support every desirable feature and
because even accepted extensions take time to implement and
deploy, people ought always look to libraries as a first
choice. This is more often than not the most constructive
outlet for enthusiasm for new facilities. Only if the
library route is genuinely infeasible should the language
extension route be followed.
_C_o_n_v_e_r_g_e_n_c_e
Naturally, a standards committee _m_u_s_t stop working on
extensions sometime. In the case of the C++ committee, the
extensions work will undoubtedly die down towards the end of
1993 in preparation for the draft due in September 1994.
However, the extensions issue will reappear in the form of
public comments on that draft and those comments must be
answered under the rules of the standards committees. Some
problems will not go away just because we would like to
ignore them.
My personal aim has been to minimize extensions through
thorough evaluation and design. My contention is that this
policy and not a policy of ``no extensions'' will maximize
the stability and the utility of C++.
_C_u_r_r_e_n_t _S_t_a_t_e
Here are some lists intended to give an impression of the
current state of affairs in the area of suggested extensions
to C++.
Accepted:
Exception handling (``mandated'')
Templates (``mandated'')
European character set representation of C++
Relaxing rule for return types for overriding functions
Run-time Type identification
Overloading based on enumerations
User-defined allocation and deallocation operators for
arrays
Forward declaration of nested classes
Rejected or withdrawn:
Concurrency mechanisms
Renaming of inherited names
Keyword arguments
Several proposals for slight modifications of the data
hiding rules
June 9, 1993
- 8 -
Restricted pointers (``son of noalias'')
Exponentiation operator
Automatically generated composite operators
...
Pending:
Name spaces
Mutable (formerly ~const)
User-defined operator.()
In-class initialization of class members
Binary literals
Extended (international) character sets
A new syntax for type conversion
Several template extensions
``Suggested:''
Garbage collection
NCEG proposals
Nested functions
Boolean type
Discriminated unions
User-defined operators
Evolvable classes / indirect classes
Anonymous structs
Enumerations with predefined ++, <<, etc. operators
Overloading based or return type
...
The extension proposals marked ``suggested'' has been infor-
mally presented or even been widely discussed, but no formal
proposal have been brought to the committee.
June 9, 1993