In article <solomon.744893157@cs.wisc.edu> solomon@gjetost.cs.wisc.edu (Marvin Solomon) writes:

>Thus at any time each extension would have its own status:  Proposed,
>draft, or frozen.  The benefits of a standard for the core language would
>not be delayed by waiting for the various extensions to settle down.
>This approach would also expedite the generation of extensions.
>Because publication of an extension standard would not "obsolete" existing
>compilers (and programs), there would be less pressure to prove the importance
>of an extension before adopting a standard for it.  Once the extension is
>standardized, the marketplace can decide whether it is worthwhile.

 The ISO process does not work like that. There is a Standard,
it stands for a while, then lapses or gets renewed. There is no provision
for continuous upgrades or additions, other than a creation of a new
ISO work item.

 There *is* a mechanism in place for dealing with extensions.
Namely, the extensions get written up, and even if rejected can
form the basis of an implementation.

 For example any vendor wishing to capture the market
by providing nested functions with closures and/or object
closures, can refer to my technical paper as a starting point.

 In this case, since one of the main uses of closures
is as callbacks, which tend to be environment specific, uses
are unlikely to be subject to too many portability constraints.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

maxtal@physics.su.OZ.AU (John Max Skaller) writes:

>In article <solomon.744893157@cs.wisc.edu> solomon@gjetost.cs.wisc.edu (Marvin Solomon) writes:

>>Thus at any time each extension would have its own status:  Proposed,
>>draft, or frozen.  The benefits of a standard for the core language would
>>not be delayed by waiting for the various extensions to settle down.
>>This approach would also expedite the generation of extensions.
>>Because publication of an extension standard would not "obsolete" existing
>>compilers (and programs), there would be less pressure to prove the importance
>>of an extension before adopting a standard for it.  Once the extension is
>>standardized, the marketplace can decide whether it is worthwhile.

> The ISO process does not work like that. There is a Standard,
>it stands for a while, then lapses or gets renewed. There is no provision
>for continuous upgrades or additions, other than a creation of a new
>ISO work item.

I may not have made myself clear, or I may not completely understand the
current C++ standardization effort.  I was under the impression that
the C++ standard will include EH, etc. as an integral part of the standard
(rather like the Ada "no extensions, no subsets" policy).  I was not advocating
evolution of standards, but rather splitting the standard into multiple
"work units":  "Core C++ Language", "Standard C++ Extension for Exception
Handling", etc.  Perhaps the mention of "status" in the first sentence quoted
above was misleading.  I was refering to the process by which a proposal
*becomes* a standard.  An extension would not be a "standard" until it was
"frozen".  Perhaps the old ISO terms DP, DIS, and IS would make this clearer.
I believe the term "addendum" is also relevant here.

The main point of my suggestion is that a "core" C++ standard could be
"frozen" (accepted as an International Standard) while various extensions
were still making their way through the standardization process.  A slightly
more subtle point was that this split would make it easier to standardize
extensions.  The standards-making bodies would probably feel less nervous
about foisting a Standard for EH on the world if it didn't immediately
invalidate (make non-conforming) all the existing implementations.

> There *is* a mechanism in place for dealing with extensions.
>Namely, the extensions get written up, and even if rejected can
>form the basis of an implementation.

Yes, this is a viable mechanism, but it doesn't serve the same purpose.
Suppose you and I write up conflicting proposals for adding first-class
continuations to C++.  [WARNING: This is meant to be a ridiculous example.
If you think first-class continuations in C++ are a good idea, please
substitute some other example. :GNINRAW]  One would hope that the "better"
proposal would win, but we both know the real world doesn't always work that
way.  My proposal may lose because my implemenation only works on a
17-bit Soviet vacuum-tube computer, or it may win because it is secretly backed
by H. Ross Perot. An impartial and competent standards body acting as jury
can help to select the best proposal on the basis of technical merit.
Much more important, however, is the value of the standards body's blessing
as an insurance policy.  Given the choice of a technically excellent
proposal or a somewhat inferior (but not hopelessly broken) incompatible
but "official" alternative, anybody with money at risk is much more likely
to choose the latter.  A careful, thorough, persuasive write-up of
an excellent proposal with an implementatin to back it up is the first
step towards standardization, not a substitute for it.
--
Marvin Solomon                  Professor and Chair
Computer Sciences Department    University of Wisconsin
1210 W. Dayton St.              Madison WI, USA
(608) 262-1204                  solomon@cs.wisc.edu

In article <solomon.744981850@cs.wisc.edu> solomon@gjetost.cs.wisc.edu (Marvin Solomon) writes:
>maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>
>>In article <solomon.744893157@cs.wisc.edu> solomon@gjetost.cs.wisc.edu (Marvin Solomon) writes:
>
>>>Thus at any time each extension would have its own status:  Proposed,
>>>draft, or frozen.  The benefits of a standard for the core language would
>>>not be delayed by waiting for the various extensions to settle down.
>>>This approach would also expedite the generation of extensions.
>>>Because publication of an extension standard would not "obsolete" existing
>>>compilers (and programs), there would be less pressure to prove the importance
>>>of an extension before adopting a standard for it.  Once the extension is
>>>standardized, the marketplace can decide whether it is worthwhile.
>
>> The ISO process does not work like that. There is a Standard,
>>it stands for a while, then lapses or gets renewed. There is no provision
>>for continuous upgrades or additions, other than a creation of a new
>>ISO work item.
>
>I may not have made myself clear, or I may not completely understand the
>current C++ standardization effort.  I was under the impression that
>the C++ standard will include EH, etc. as an integral part of the standard
>(rather like the Ada "no extensions, no subsets" policy).  I was not advocating
>evolution of standards, but rather splitting the standard into multiple
>"work units":  "Core C++ Language", "Standard C++ Extension for Exception
>Handling", etc.  Perhaps the mention of "status" in the first sentence quoted
>above was misleading.  I was refering to the process by which a proposal
>*becomes* a standard.  An extension would not be a "standard" until it was
>"frozen".  Perhaps the old ISO terms DP, DIS, and IS would make this clearer.
>I believe the term "addendum" is also relevant here.

Despite the potential nuisance as far as determining standards conformance,
I like this idea.  There is certainly precedent for this kind of approach,
e.g. in the POSIX 1003.x standards and various ISO-9000 levels.  Any head-
aches in maintaining a set of standard extensions should be less than the
headaches of trying to decide whether to include the extensions in a
monolithic standard.  Later standards efforts could then choose whether to
let extension standards lapse or to fold them into the base language standard.
Extension standards would also help reduce the need for revisions to the base
standard except for clarification purposes, thus potentially improving the
quality of all part of the standard by reducing the number of issues the com-
mitte needs to address at any given time.

- Brad
--
Brad Daniels   |  "Let others praise ancient times.
daniels@neosoft.com  |   I am glad I was born in these."
I don't work for NeoSoft, and | - Ovid (43 B.C. - 17 A.D)
don't speak for my employer. |

solomon@gjetost.cs.wisc.edu (Marvin Solomon @ U of Wisconsin Madison - Computer Sciences) writes

 > I may not have made myself clear, or I may not completely understand the
 > current C++ standardization effort.  I was under the impression that
 > the C++ standard will include EH, etc. as an integral part of the standard
 > (rather like the Ada "no extensions, no subsets" policy).  I was not advocating
 > evolution of standards, but rather splitting the standard into multiple
 > "work units":  "Core C++ Language", "Standard C++ Extension for Exception
 > Handling", etc.  Perhaps the mention of "status" in the first sentence quoted
 > above was misleading.  I was refering to the process by which a proposal
 > *becomes* a standard.  An extension would not be a "standard" until it was
 > "frozen".  Perhaps the old ISO terms DP, DIS, and IS would make this clearer.
 > I believe the term "addendum" is also relevant here.

The splitting of the standard process into separate ``work groups'' for
issues such as ``core,'' ``environment,'' ``libraries,'' ``extensions,'' etc.
was done at the first meeting back in 1990.

 > The main point of my suggestion is that a "core" C++ standard could be
 > "frozen" (accepted as an International Standard) while various extensions
 > were still making their way through the standardization process.  A slightly
 > more subtle point was that this split would make it easier to standardize
 > extensions.  The standards-making bodies would probably feel less nervous
 > about foisting a Standard for EH on the world if it didn't immediately
 > invalidate (make non-conforming) all the existing implementations.

The major extensions (templates, exception handling, run-time type information,
and namespaces) are all in the language now and all are backed by implementation
experience. The group dealing with ``extensions'' (chaired by me), like all
other working groups, has a year to polish the existing wording, remove any
glaring mistakes or incompletenesses, and ensure that coordination with other
working groups is complete. I expect to finish on time. I don't anticipate a
need to play games with the ISO procedure or split the C++ standard into layers.

 - Bjarne

In article <CBJpyz.Cn8@sugar.NeoSoft.COM> daniels@NeoSoft.com (Brad Daniels) writes:
>
>Despite the potential nuisance as far as determining standards conformance,
>I like this idea.  There is certainly precedent for this kind of approach,
>e.g. in the POSIX 1003.x standards and various ISO-9000 levels.  Any head-
>aches in maintaining a set of standard extensions should be less than the
>headaches of trying to decide whether to include the extensions in a
>monolithic standard.  Later standards efforts could then choose whether to
>let extension standards lapse or to fold them into the base language standard.
>Extension standards would also help reduce the need for revisions to the base
>standard except for clarification purposes, thus potentially improving the
>quality of all part of the standard by reducing the number of issues the com-
>mitte needs to address at any given time.
>

 The problem is that instead of one committee we would
have several working on different documents. There is enough
problem now finding the time and money to work on one document.
We're just a bunch of volunteers, many of who fork out their
own personal money.

 If a second document is to be worked on, it probably
ought to be for an extended C++ library. I am considering
proposing such a Work Item to SC22. But the problem with
this idea is that I for one could probably not attend any
meetings of the people who would be interested in this item.
I'll be lucky to get to another meeting of WG21 :-)

 In other words, turning something from a good idea
into a reality costs time and money and manpower, and
Standards organisations are not setup to collect this
money from the people who would finally benefit from
the research and development that would be required.

 They are set up to Standardise 'Existing Practice',
and the C++ committee is already doing something a long
way from that (necessarily) and thus has enough problems
operating in an inappropriate framework already.

 The world and the role of Standards are changing,
but the bodies involved in the processes are not keeping up.
[Thats not because they dont try, but because its hard
to obtain consenus on issues that are at the research
and innovation level]

 Its no longer appropriate to just standardise existing
practice: the costs of global non-standardisation are
so high that manufacturing and marketting efforts will
often not be made until a standard for interoperability
*already* exists.

 So now, the Standards must come first, and their
implementations second. Which means Standardising
'existing practice' is no longer a completely
appropriate viewpoint.

 The problem of course is that 'planned' things
are often abysmal failures (for example, planned economies).

 C++ is half way: its being Standardised at an appropriate
time by an inappropriate mechanism.  We just have to do the
best that is possible within this framework. Breaking
up C++ into 'modules' might be a good idea were there sufficent
resources: it would accelerate the creation of some standards
(eg core) at the expense of others (eg extensions). But there
aren't those resourses available. So we're likely to be
stuck with a compromise in both quality and timing.

 The long term costs of not allocating sufficent
resources to this project are hard to guess at. But the
short term direct benefits are mainly what the contributers
to the Standardisation process must consider. What does
company 'X' gain from committing resources to this
project? How does X gain an advantage over Y who does
not contribute?


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <rfgCB7s1z.CGG@netcom.com>, rfg@netcom.com (Ronald F.
Guilmette) writes:
> >In article <C9vACE.EEM@hawnews.watson.ibm.com>
> >krk@charmed.torolab.ibm.com () writes:
> >
> >|> It is always in the implementation that the truth of a spec is
> found. Well,
> >|> we implement this stuff here, so perhaps I can offer a counter
> opinion.
> >
> >|> EH has very few holes in its definition. Certainly no major ones.
>
> That you have managed to find anyway... :-)
>
> Just be patient and wait until users get ahold of this stuff and
> start
> seriously banging on it!
>

I am patient. Users have had my product well over a year externally. We have
a large internal user community that have had it even longer. By all accounts,
they are 'banging on it'. I stand by my comment.

>
> >|> Comparing
> >|> implementation notes with the HP/USL work has shown a very strong
> consistency
> >|> in our implementations.
>
> Great.  So you both made the same mistakes in the same ways, yes?

I guess that's one way to look at it...

>
> Is this supposed to be comforting?  Is it offered as proof that the current
> definition of exception handling is really fully cooked?  (Sorry.  I'm not
> convinced.)
>

Really? Jeez, I'm sorry. Help me understand your concern with regards to EH.
For my part, I'll certainly try to include any points you have in
the finished standard.

[snip, snip, snip]

>
> >|>In a world of conformance to standards,
> >|> it is hard to convince companies to invest in proprietary solutions.
>
> Nonsense.  Just TRY to find ANY compiler vendor than hasn't implemented
> his/her own specialized extensions (where they saw a need) already.  Good
> luck.  In a world of conformance to standards, implementors try their best
> to conform AND to provide their own pet extensions (often as a way of
> helping to lock-in their respective customer bases... a technique which
> IBM employees should be familiar with, as IBM practically invented the
> concept of customer lock-in).
>

BWAHAHAHAHA... I love this one:-) Thanks for the day brightener!

> In short, compiler vendors DO invest in proprietary solutions, and often,
> so do their customers.  Why do you think that languages like FORTRAN and
> COBOL have undergone several separate standardizations?  And where did
> you think the innovations which went into the later revisions of those
> language standards came from?  They came from independent innovations
> (i.e. "extensions") BEYOND the earlier standards, which were implemented
> by implementors and then used and requested (frequently) by users.
>
> That's actually not a bad way to standardize new features.  Let them soak
> awhile.  Let them prove themselves in widespread practice.  THEN put them
> in a standard.
>

I stand by my original post. I work in a C/C++ compiler shop. We simply do not
invest in proprietary solutions unless we must. Even then, it's small stuff,
or stuff not yet addressed by the standards group that needs a solution now.
It is much preferrable to me to have the current situation than to try to
merge multiple vendor solutions for something as large as, say, EH.

> --
>
> -- Ronald F. Guilmette ------------------------------------------------------
> ------ domain address: rfg@netcom.com ---------------------------------------
> ------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

--
Regards,

krk.

Kim Knuttila  | Do I need to say it?... oh why not...
C/C++ Architecture | IBM doesn't Speak for Me, I don't Speak for Them,
IBM Toronto  | I don't even Speak for Jake,
(416)448-2171  | but I do Speak for myself... Woof.

When I first saw the phrase "standard extensions" I thought it meant
"standardized extensions" rather than "extensions to the standard".
After reading all the flaming on this group, it still seems to me that
the former interpretation would have been preferable.  What I'm suggesting
is something like this:  "EH [or RTTI, NS, etc.] is an extention.  A
conforming compiler need not implement it.  However, a compiler that claims
to implement 'standard EH' should do so as follows: ...".  In other words,
standardize both the "core" lanaguage and extensions, but clearly indicate which
is which.  Each conforming compiler should come with a list of extensions it
purports to support.  It could even have a switch turn the extension on
and off (to support pre-extension code and to aid in portability testing).

It would only be practical to apply this approach to relatively "separable"
and upward-compatible extensions.  An "extension" that caused substantial
changes to the unextended part of the language would lead to large
headaches in maintaining multiple versions of tools.  However, the kinds of
things that have been mentioned as extensions generally affect the core only
in usurping a couple of reserved words.

The advantage to this approach is that it could substantially speed the
standardization process.  For the core standard, concentrate on cleaning
up ambiguities in the ARM.  If ANSI could get a core standard (or even
a draft core standard) out quickly, compiler vendors could concentrate on
making sure their products conform and application programmers with a strong
portability requirement could work on confining their code to the core.
(Such users probably avoid anything that smacks of "extension" anyhow).
A standard is a useful tool to adjudicate disputes: When a program behaves
differently on different compilers, the consumer knows whom to blame.
It also server as a bit of insurance for conscientious compiler writers
(if they adhere carefully to the standard, there is less likelihood that
they will be forced to make expensive changes to their compilers) and
conscientious application writers (their code is more likely to be portable).
Finally, it helps to foster a market for standards-conformance-testing tools.

Standard extensions provide many of the same benifits.  They encourage
vendors to differentiate themselves by offering extensions ("The Acme
compiler supports ANSI standard exceptions") without the danger of
isolating themselves (Nobody uses the Acme compiler because it doesn't
support the style of exceptions implemented by Best Corp, which
has emerged as the industry leader).

Standard extension can be introduced later than the core standard.  The
extension process should be an on-going activity:  Someone suggests the
need for a new extension (e.g., in this news group).  After some discussion,
a specification is proposed.  One or two vendors create experimental
implementations.  Based on their experiences, the spec is revised and issued
as a draft standard.  More vendors implement the proposal and offer it
to selected customers.  Experience leads to further refinements, and
the standard is revised and "frozen".  Emboldened by the existence of
a standard, and driven by market pressure, many more vendors choose to offer
the extension.  Eventually, the feature becomes so popular that no serious
vendor would consider offering a compiler that doesn't support the "extension".

Thus at any time each extension would have its own status:  Proposed,
draft, or frozen.  The benefits of a standard for the core language would
not be delayed by waiting for the various extensions to settle down.
This approach would also expedite the generation of extensions.
Because publication of an extension standard would not "obsolete" existing
compilers (and programs), there would be less pressure to prove the importance
of an extension before adopting a standard for it.  Once the extension is
standardized, the marketplace can decide whether it is worthwhile.
--
 Marvin Solomon
 Professor and Chair
 Computer Sciences Department
 University of Wisconsin

>In article <C9vACE.EEM@hawnews.watson.ibm.com>
>krk@charmed.torolab.ibm.com () writes:
>
>|> It is always in the implementation that the truth of a spec is found. Well,
>|> we implement this stuff here, so perhaps I can offer a counter opinion.
>
>|> EH has very few holes in its definition. Certainly no major ones.

That you have managed to find anyway... :-)

Just be patient and wait until users get ahold of this stuff and start
seriously banging on it!


>|> Comparing
>|> implementation notes with the HP/USL work has shown a very strong consistency
>|> in our implementations.

Great.  So you both made the same mistakes in the same ways, yes?

Is this supposed to be comforting?  Is it offered as proof that the current
definition of exception handling is really fully cooked?  (Sorry.  I'm not
convinced.)

>|> To reiterate, I think that the extensions that have gone in since the
>|> standardization process has started have been improvements. I also think
>|> that encouraging implementors to implement the extensions results in
>|> complete extensions. Lastly I don't believe that these extensions would
>|> be implemented if they weren't in the Working Paper. Certainly not
>|> as widely. Its fine to wish for implementations. The only way to get
>|> them to happen is vote 'em in.

This is THE rationalization that has been used for the past several years
for turning the C++ standardization committee into a big research project
rather than simply trying to write a standard for a pre-existing language.

No matter how many times it is repeated, it is still just a rationalization
for doing what some (most?) of the committee members enjoy doing, rather
than what the industry as a whole (and all of those poor dumb users out
there) need to have done.

>|>In a world of conformance to standards,
>|> it is hard to convince companies to invest in proprietary solutions.

Nonsense.  Just TRY to find ANY compiler vendor than hasn't implemented
his/her own specialized extensions (where they saw a need) already.  Good
luck.  In a world of conformance to standards, implementors try their best
to conform AND to provide their own pet extensions (often as a way of
helping to lock-in their respective customer bases... a technique which
IBM employees should be familiar with, as IBM practically invented the
concept of customer lock-in).

In short, compiler vendors DO invest in proprietary solutions, and often,
so do their customers.  Why do you think that languages like FORTRAN and
COBOL have undergone several separate standardizations?  And where did
you think the innovations which went into the later revisions of those
language standards came from?  They came from independent innovations
(i.e. "extensions") BEYOND the earlier standards, which were implemented
by implementors and then used and requested (frequently) by users.

That's actually not a bad way to standardize new features.  Let them soak
awhile.  Let them prove themselves in widespread practice.  THEN put them
in a standard.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <rfgCB7s1z.CGG@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:

> In short, compiler vendors DO invest in proprietary solutions, and often,
> so do their customers.  Why do you think that languages like FORTRAN and
> COBOL have undergone several separate standardizations?

One reason is certainly important: At least in the USA, standards have
a well-defined lifetime.  After that, they must either be revised,
reaffermed, or withdrawn.

So when revision time rolls around, there is a great temptation to
`do it right this time.'

I once saw a wonderful letter that recommended reaffirming the ANSI
standard for flowcharts.  The letter pointed out:

 1. The members of the committee tried to find anyone who
 actually *used* ANSI standard flowcharts and couldn't.
 They therefore concluded that the standard should be withdrawn.

 2. However, there were lots of government contracts out there
 that specified that projects should accompany their work by
 flowcharts that meet the standard.  These flowcharts were
 invariably generated by programs that read the source text,
 were handed over to the client in big fat binders, and were
 then never looked at again.

 3. If the standard were allowed to lapse, all those contracts
 would have to be rewritten, presumably at considerable expense.

 4. Therefore they recommended that the standard be reaffirmed
 without change.

The usual lifetime for ANSI standards is five years, I think.
--
    --Andrew Koenig
      ark@research.att.com

In article <25937@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes:
>
>
>rfg@netcom.com (Ronald F. Guilmette @ Netcom Online Communications Services (408-241-9760 login: guest)) writes
>
> > P.S. At this point in time, even if X3J16 totally ignored *all* suggested
> > extensions (including the ones that Bjarne himeself is ramming... ummm...
> > I'm sorry... "sheparding" through X3J16)
>
>For the record: I don't ``ram'' extensions through X3J16/ISO-WG. It is by no means
>certain that I could ram one extension through if I tried. I certainly couldn't do
>it twice.

 Having just come from my first WG21 meeting at Munich, and having
been part of the extensions subgroup, I can only support Bjarnes statement.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <21gqc9$h5v@nic.lth.se> dag@control.lth.se (Dag Bruck) writes:
>In <comp.std.c++> rfg@netcom.com (Ronald F. Guilmette) writes:
>>
>>Hummm.... You're right.  How about if we give them all company-paid trips to
>>exotic and scenic destinations like Munich and Hawaii along with company-paid
>>first class accomodations.  (I know.  I know.  It's a tough job but somebody's
>>got to do it. :-)
>
>Hmmm.  San Jose is more exotic than Munich to me (see signature).

 Anywhere outside Australia is exotic and expensive. :-)
I went to Munich and I paid thousands of dollars for the 'priviledge'.
Support from Standards Australia was welcome, but didnt even cover
the airfare, let alone the hotel bill.

 (You can check *my* signature too. The C++ standard is
an *international* effort.)

>--
>Department of Automatic Control  E-mail: dag@control.lth.se
>Lund Institute of Technology
>P. O. Box 118    Phone: +46 46-104287
>S-221 00 Lund, SWEDEN   Fax:    +46 46-138118


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <C9vACE.EEM@hawnews.watson.ibm.com>
krk@charmed.torolab.ibm.com () writes:

|> It is always in the implementation that the truth of a spec is found. Well,
|> we implement this stuff here, so perhaps I can offer a counter opinion.

|> EH has very few holes in its definition. Certainly no major ones. Comparing
|> implementation notes with the HP/USL work has shown a very strong consistency
|> in our implementations. The minor things that have come up will be tidied
|> up at the committee.

I suppose EH is exception handling.

|> PT sufferes a bit from other definitional problems in the language that are
|> being cleaned up as the language is being cleaned up. It also suffers from
|> being more closely linked to the compiler environment. It is also, hands down,
|> the most appreciated extension in the community using our compiler. In the
|> end, PT will also be complete, definitionally, because of the number of
|> implementors that will have it in their compilers. This was one reason, of
|> many, for including it in the Working Paper.

In article <KANZE.93Jul19191939@slsvhdt.us-es.sel.de>,
kanze@us-es.sel.de (James Kanze) writes:
> In article <C9vACE.EEM@hawnews.watson.ibm.com>
> krk@charmed.torolab.ibm.com () writes:
>
> |> It is always in the implementation that the truth of a spec is
> found. Well,
> |> we implement this stuff here, so perhaps I can offer a counter
> opinion.
>
> |> EH has very few holes in its definition. Certainly no major ones.
> Comparing
> |> implementation notes with the HP/USL work has shown a very strong
> consistency
> |> in our implementations. The minor things that have come up will be
> tidied
> |> up at the committee.
>
> I suppose EH is exception handling.

Yep. Sorry for dribbling off into acrynonym land.
>
> |> PT sufferes a bit from other definitional problems in the language
> that are
> |> being cleaned up as the language is being cleaned up. It also
> suffers from
> |> being more closely linked to the compiler environment. It is also,
> hands down,
> |> the most appreciated extension in the community using our compiler.
> In the
> |> end, PT will also be complete, definitionally, because of the
> number of
> |> implementors that will have it in their compilers. This was one
> reason, of
> |> many, for including it in the Working Paper.
>
> From the context of the previous posting, PT is templates?

Yep again. PT == Parameterized Types.
>
> |> We haven't implemented 'namespaces' yet, but supposing that it is accepted
> |> into the draft, we'll get started. Why? Because our user community
> has also
> |> expressed a need for a solution in this area. That is, of course,
> the only
> |> reason for doing any of this stuff.
>
> |> To reiterate, I think that the extensions that have gone in since
> the
> |> standardization process has started have been improvements. I also
> think
> |> that encouraging implementors to implement the extensions results
> in
> |> complete extensions. Lastly I don't believe that these extensions
> would
> |> be implemented if they weren't in the Working Paper. Certainly not
> |> as widely. Its fine to wish for implementations. The only way to
> get
> |> them to happen is vote 'em in. In a world of conformance to
> standards,
> |> it is hard to convince companies to invest in proprietary
> solutions.
>
> I don't think the problem has been with the quality of the individual
> extensions (although I personally have some doubts concerning
> namespaces).

But that is the issue to which I was responding...

>              The problem is the trade-off, extensions *or* a standard
> anytime soon.  My guess is that each of the aforementioned extensions
> have delayed or will delay the standard by about a year.  (Maybe a bit
> less for exceptions, certainly more for templates.)

Well, I don't know if I buy the estimate. How did you come up with it?
If we had accepted no extensions (which as Andy pointed out earlier
was not possible in our charter), I'm not sure we would be done
noticeably quicker.

>
> My customers are beginning to shy away from C++, because they ask
> themselves: "if the experts on the C++ committee don't understand the
> language well enough to be able to define it, how can we expect our
> programmers to be able to write portable programs in it?"  Now I know
> enough about C++ *and* the current standards effort to know 1) you can
> write relatively portable programs with the language just as it
> stands, standard or no, and 2) most of the extensions *are* an
> improvement, and address important issues.  But there is a perception
> problem here.  One of the more frequent criticisms of C++ is that it
> is overly complex.  By continually delaying the standard, we add to
> the effectiveness of this arguement.

Firstly, I doubt that concerns regarding C++ 'complexity' will be
alleviated by the appearance of a standard. People using this
argument are usually referring to properties of the language,
and the properties referred to are not likely to disappear.

Secondly, standards last a long time. We are in that uncomfortable
zone between the establishment of a defacto standard, and the issue
of the first standard for the language. This is not really the best
time to be in a hurry. Sure, timing is a factor, but it is one of
several.

Of course, your customers are right to assess the risks and rewards
of the paths available to them. If they believe the best balance is
for another standard programming language, it is their business to
make the choice. Programming in C++ today is probably analagous
to programming in C in 1987. Most people's code was not broken by
the C standard, but some was. Some breakage was avoidable by keeping
track of the C standardization activity.

So... keep track of the C++ committee, and keep an eye on your
vendor. And if you have specific concerns, voice them. Use your
vendor, or this forum, or even direct mail to the committee. We
all want this to work.

> --
> James Kanze                             email: kanze@us-es.sel.de
> GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
> Conseils en informatique industrielle --
>                    -- Beratung in industrieller Datenverarbeitung

--
Regards,

krk.

Kim Knuttila  | Do I need to say it?... oh why not...
C/C++ Architecture | IBM doesn't Speak for Me, I don't Speak for Them,
IBM Toronto  | I don't even Speak for Jake,
(416)448-2171  | but I do Speak for myself... Woof.

In article <25936@alice.att.com> ark@alice.UUCP () writes:
>> Exponentiation is a very small addition to a compiler.
>
>I wish that were true.  It is a very small addition to a parser, but
>there is a *lot* of other work to do.

Why not just provide a pow operator than can only be overloaded, but not
used with built-in types?  That really would be trivial, and would be
the key part of the solution, such that the rest could be provided by
class libraries.

In article <rfgC9KttA.AKq@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
|> P.S. At this point in time, even if X3J16 totally ignored *all* suggested
|> extensions (including the ones that Bjarne himeself is ramming... ummm...
|> I'm sorry... "sheparding" through X3J16) the committee would *still* not
|> be able to produce anything approximating a clear and unambiguous standard
|> for at least three years past the originally scheduled completion date.
|>
I think this is very unfair, both to Bjarne and to the rest of the committee.
Bjarne would not try to "ram" anything through the committee, and the they
would not let him if he tried. There are enough diverse opinions and experiences
represented on the committee that no one person, not even Bjarne, could hope to
influence the proceedings in the way suggested above.

This standards process is *hard work*. Nobody on the committee is playing at it.
Anybody who didn't take the work seriously would not still be doing it.

Ron has contributed much to the process, and the final standard will be better
because of it, but I couldn't let this pass.

Steve.
--
UUCP:  ...!uknet!warwick!steve Internet: steve@maths.warwick.ac.uk
JANET:  steve@uk.ac.warwick.maths PHONE:  +44 203 524657
--
--
UUCP:  ...!uknet!warwick!steve Internet: steve@maths.warwick.ac.uk
JANET:  steve@uk.ac.warwick.maths PHONE:  +44 203 524657

In article <SCHOUTEN.93Jul5141810@sp95.csrd.uiuc.edu> schouten@sp95.csrd.uiuc.edu writes:

> I don't see how this is relevant.  All we (proponents of
> an exponentiation operator) are asking for is a character or two
> to be defined as a right-associative high priority operator.  Forget
> about semantics.

No -- that's what *you* (as an individual) are asking, presumably
along with some other people.  But I am sure that other people want,
at the very least, an operator with the property that evaluating
x~2 (or whatever the operator is) is no slower and no less accurate
than evaluating x*x.  I suspect that people who do serious numerical
work will accept no less.

Then there is the problem of what character to use for the operator.
I picked ~ for this example, but that's really inappropriate because
it's not among the characters guaranteed to be present in every country
(remember: this is an international standard we're working on).
Indeed, if I remember the discussions properly (I'm not in the extensions
working group), there is no appropriate character: $ is also a national
character and ^ is already defined with the wrong precedence.
--
    --Andrew Koenig
      ark@research.att.com

In article <25939@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:

>> I don't see how this is relevant.  All we (proponents of
>> an exponentiation operator) are asking for is a character or two
>> to be defined as a right-associative high priority operator.  Forget
>> about semantics.
>
>No -- that's what *you* (as an individual) are asking, presumably
>along with some other people.
I was being presumptuous for the sake of simplicity.

>                               But I am sure that other people want,
>at the very least, an operator with the property that evaluating
>x~2 (or whatever the operator is) is no slower and no less accurate
>than evaluating x*x.  I suspect that people who do serious numerical
>work will accept no less.
Yet you're asking them to accept much less.
You're chasing shadows here.  As I and others have pointed out, this
is irrelevant becase; 1) All these numerical restrictions equally
whether you're talking about an operator or a `pow' function and
2) you can make exactly the same arguments about * w.r.t. +.  Your
points just don't make sense in this context.


>Then there is the problem of what character to use for the operator.
>I picked ~ for this example, but that's really inappropriate because
>it's not among the characters guaranteed to be present in every country
>(remember: this is an international standard we're working on).
>Indeed, if I remember the discussions properly (I'm not in the extensions
>working group), there is no appropriate character: $ is also a national
>character and ^ is already defined with the wrong precedence.

Oh come on!
Surely you aren't seriously suggesting that it's not feasible because
we've already used up all the characters?  There are lots of possibilities.

Dale Schouten
schouten@uiuc.edu

In article <25939@alice.att.com> ark@alice.UUCP () writes:

>Then there is the problem of what character to use for the operator.
>I picked ~ for this example, but that's really inappropriate because
>it's not among the characters guaranteed to be present in every country
>(remember: this is an international standard we're working on).

Do you plan to remove destructors and unary ~ from the language?  I think
it's too late to object to use of ~.

--
    John Carr (jfc@athena.mit.edu)

In article <KANZE.93Jul5144659@slsvdnt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:

[referring to a proposed exponentiation operator for C++]

> In sum, the committee has decided to do the hard part (handling the
> difficulties in definition, which will be necessary for the library
> function too), and forgo the easy part (extending the syntax).

The hard part, and also the important part.  There were two reasons
why I wanted an exponentiation operator: to provide more convenient
syntax, and to provide a good method for raising numbers to small
integral powers.  (I *do* hope that none of you write pow(x,2) when
you want to square x...  I've seen code that does this.)

The convenient syntax would have been nice, but overloading pow() for
the case where the second argument is integral will at least remove a
rather large deficiency in the language.  I'm glad that the Committee
approved of the idea of making this addition to the Standard Library.
I hope that this does happen when the time actually comes to make the
Standard Library standard, and that compiler vendors will start
including pow(double,int) in their libraries some time soon.  I'm
getting tired of writing "inline double square(double x) {return x*x;}".
--
Matthew Austern                       Maybe we can eventually make language a
matt@physics.berkeley.edu             complete impediment to understanding.

In article <SCHOUTEN.93Jul6105421@sp95.csrd.uiuc.edu> schouten@sp95.csrd.uiuc.edu writes:

> You're chasing shadows here.  As I and others have pointed out, this
> is irrelevant becase; 1) All these numerical restrictions equally
> whether you're talking about an operator or a `pow' function and
> 2) you can make exactly the same arguments about * w.r.t. +.  Your
> points just don't make sense in this context.

I understand that there are some people who just want an exponentiation
operator and don't care what results it gives, but I don't think there
are enough of those to form a consensus in the committee.

> Oh come on!
> Surely you aren't seriously suggesting that it's not feasible because
> we've already used up all the characters?  There are lots of possibilities.

So far, no one has come up with even one possibility that enough
people on the committee like to be willing to approve it.
--
    --Andrew Koenig
      ark@research.att.com

>In article <SCHOUTEN.93Jul5141810@sp95.csrd.uiuc.edu> schouten@sp95.csrd.uiuc.edu writes:
>> I don't see how this is relevant.  All we (proponents of
>> an exponentiation operator) are asking for is a character or two
>> to be defined as a right-associative high priority operator.  Forget
>> about semantics.

Schouten is asking for a minimum, from which something useful could
presumably be constructed.  I'm not so sure, because I'm not sure how
all the int~int, int~float, float~int, and float~float combinations
would interact with overloading.

In article <25939@alice.att.com> ark@alice.UUCP () writes:
>No -- that's what *you* (as an individual) are asking, presumably
>along with some other people.  But I am sure that other people want,
>at the very least, an operator with the property that evaluating
>x~2 (or whatever the operator is) is no slower and no less accurate
>than evaluating x*x.  I suspect that people who do serious numerical
>work will accept no less.

Haven't you got any better reasons for disliking exponentiation?
I've seen this one repeated several times, and it hasn't gotten any
more convincing.

It would be consistent with the language to treat "~ is to *" in much
the same way that the language already treats "* is to +".  Same
performance guarantees (none), same automatic generation of overloaded
operators (none).  How fast "*~2" runs is a quality-of-implementation
issue, and it isn't hard to get good quality out of the non-overloaded
case.  The "other people" will get what they want, without any
performance constraints written into the standard.

I can see where some other "other people" would want interesting
optimizations involving overloaded "*" to take place on overloaded "~"
applied to a constant, and I think that is worth addressing AFTER the
analogous question has been answered for overloaded "+" and "*".  I
suspect that you could reuse the answer, whatever it is.

As to the operator used, I notice that "??-" is the trigraph for "~"
in ANSI C.

David Chase
Sun

In article <21cgc4$l1@senator-bedfellow.MIT.EDU> jfc@athena.mit.edu (John F Carr) writes:

> Do you plan to remove destructors and unary ~ from the language?  I think
> it's too late to object to use of ~.

There is a new keyword, `compl,' that is a synonym for ~.
I thought that was fine for unary ~ because it isn't used
too often, but that it was ugly for destructors.  I therefore
tried to convince the committee that it would be a good idea
to use ! as a synonym for ~ in destructors, but was unsuccessful.

I also think it is unlikely that the committee will agree to
any new uses of operator symbols on the national-character list.
--
    --Andrew Koenig
      ark@research.att.com

In article <25953@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:

>I understand that there are some people who just want an exponentiation
>operator and don't care what results it gives, but I don't think there
>are enough of those to form a consensus in the committee.
...
>So far, no one has come up with even one possibility that enough
>people on the committee like to be willing to approve it.

So the real problem has nothing to do with numerical issues or
character availability or whether the moon is made of green cheese.
It is simply that there are not enough people on the committee that
want an exponentiation operator.  We could have saved a lot of
time and frustration if you'd just admitted that from the start.

Is there any official or semi-official opinion from the committee on
this particular subject?  It seems to come up with some regularity in
discussions as well as in newsgroups (which IMHO belies the idea that
it is in no great demand).  Mind you, I have no problem with the
committee making an arbitrary decision on the matter (many important
decisions are somewhat arbitrary), just don't try to tell me that
it's too difficult, or you've run out of characters or any of that
nonsense.  That's like saying you won't put it into the language
because the moon is made of green cheese: 1) It ain't, 2) even
if it were, it would have little impact on the matter.

Dale Schouten
schouten@uiuc.edu

In article <25939@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:

>Then there is the problem of what character to use for the operator.
>I picked ~ for this example, but that's really inappropriate because
>it's not among the characters guaranteed to be present in every country

Then try `*^' or `@' or binary `!' or `!!' send me a list of characters
present in every country and I'll pick some for you.

Dale Schouten
schouten@uiuc.edu

In article <25939@alice.att.com> ark@alice.UUCP () writes:
|I suspect that people who do serious numerical
|work will accept no less.

People who do serious numerical work will accept nothing less than noalias
1/2 ;-)

|Then there is the problem of what character to use for the operator.

I believe ^^ has been one suggestion.

In article <SCHOUTEN.93Jul7125407@sp95.csrd.uiuc.edu> schouten@sp95.csrd.uiuc.edu writes:
>In article <25953@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:
>
>>I understand that there are some people who just want an exponentiation
>>operator and don't care what results it gives, but I don't think there
>>are enough of those to form a consensus in the committee.
>...
>>So far, no one has come up with even one possibility that enough
>>people on the committee like to be willing to approve it.
>
>So the real problem has nothing to do with numerical issues or
>character availability or whether the moon is made of green cheese.
>It is simply that there are not enough people on the committee that
>want an exponentiation operator.  We could have saved a lot of
>time and frustration if you'd just admitted that from the start.
>
[..elided material..]
>
>Dale Schouten
>schouten@uiuc.edu

I can live without an exponentiation operator, but the attitude
expressed above does bother me because of the lack of respect it shows
for numerics programming.  I don't think that a standards committee
should give in to every special interest.  On the other hand, the
numerics programming community shouldn't be treated as just another
special interest.
   In my opinion C++ is the best chance numerics programmers have for
breaking away from Fortran and into a language with widespread support
and full features.  C is certainly not that language and I'm not for any
change there.  But the C++ standards committees would do well, I
believe, to pay some attention to features of interest to numerics
programmers.  There aren't so many numerics programmers doing C++
right now and they are therefore under-represented on standards
committees.  That will change, however, if the members of those
committees will give them some respect.  There is much to be gained by
designing and supporting a C++ that serves both the numerics and
general programming communities.  And there is little to be gained by
the non-numerics programmers from continuing to isolate and alienate
numerics programmers.

--
Ronald Schoenberg                    fax: 206-727-6521
University of Washington           email: rons@u.washington.edu

In article <SCHOUTEN.93Jul7125407@sp95.csrd.uiuc.edu>, schouten@sp95.csrd.uiuc.edu (Dale Schouten) writes:
> In article <25953@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:

> So the real problem has nothing to do with numerical issues or
> character availability or whether the moon is made of green cheese.
> It is simply that there are not enough people on the committee that
> want an exponentiation operator.  We could have saved a lot of
> time and frustration if you'd just admitted that from the start.

No, that's not right either.

There are plenty of people on the committee who want an exponentiation
operator.  There is just no single proposal that everyone likes well
enough to be willing to approve.  Some people like one, some like another.

I've told you my opinion, which is one of many.  I don't know all of
them, because I don't go to Extensions working group meetings.

> Is there any official or semi-official opinion from the committee on
> this particular subject?  It seems to come up with some regularity in
> discussions as well as in newsgroups (which IMHO belies the idea that
> it is in no great demand).

I believe that each time it has come up, it has lost in the priority vote.

Each meeting, Bjarne (who chairs the Extensions group) presents a list of
extensions for which proposals are on the table.  I don't think that
an exponentiation operator has even made it out of that list.

> Mind you, I have no problem with the
> committee making an arbitrary decision on the matter (many important
> decisions are somewhat arbitrary), just don't try to tell me that
> it's too difficult, or you've run out of characters or any of that
> nonsense.  That's like saying you won't put it into the language
> because the moon is made of green cheese: 1) It ain't, 2) even
> if it were, it would have little impact on the matter.

I am telling you some of the arguments I have heard.  I know I haven't
heard them all.  I also know that despite several proposals, there is
no proposal that has even gotten enough support to be put to a vote.

Perhaps someone who sits in on the Extensions WG sessions can supply
more detail.
--
    --Andrew Koenig
      ark@research.att.com

In article <215t2r$sv4@senator-bedfellow.MIT.EDU> jfc@athena.mit.edu (John F Carr) writes:
>In response to rfg's comments I should clarify a few points in my
>earlier message:
>
...
>I wrote the extension so that the proposal could be considered on its
>merits instead of being rejected due to lack of an implementation or
>programs which used the extension.

I should say that I think that John did a good and noble thing by providing
an example implementation for this particular proposed extension.  Indeed,
I wish that *all* extensions had publically available implementations which
could be carefully evaluated before x3j16 considered the extensions in
question.

So anyway, I apologize if I sounded like I was getting on John's case before.
That wasn't my intent.  But I did want to make the point that there is a
seemingly never ending list of things that people want to add to the standard
definition of C++.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In <comp.std.c++> schouten@sp95.csrd.uiuc.edu writes:
>
>Is there any official or semi-official opinion from the committee on
>this particular subject?

The committee has considered a well-written proposal by Matt Austern
(matt@physics.berkeley.edu).  The proposal for exponentiation operator
was rejected, but a related proposal to add a standard library
function

 double pow(double, int);

to the existing

 double pow(double, double);

was accepted.

Both the proposal and the rejection have been posted on this newsgroup
by Matt Austern.

References:

Matthew H. Austern (1992): "A proposal to add an exponentiation
operator to the C++ language," document numbers X3J16/92-0099 and
WG21/N0176.

Dag M. Bruck (1992): "Analysis of exponentiation operator," document
numbers X3J16/92-0127 and WG21/N0204.

Best regards,

Dag Br\"uck
--
Department of Automatic Control  E-mail: dag@control.lth.se
Lund Institute of Technology
P. O. Box 118    Phone: +46 46-104287
S-221 00 Lund, SWEDEN   Fax:    +46 46-138118

In article <25937@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes:
>
>
>rfg@netcom.com (Ronald F. Guilmette @ Netcom Online Communications Services (408-241-9760 login: guest)) writes
>
> > P.S. At this point in time, even if X3J16 totally ignored *all* suggested
> > extensions (including the ones that Bjarne himeself is ramming... ummm...
> > I'm sorry... "sheparding" through X3J16)
>
>For the record: I don't ``ram'' extensions through X3J16/ISO-WG.

Yes.  Sorry about that.  As chariman of the extensions working group, you
don't exactly have to.

(It is interesting to note however that huge and rather poorly defined hunks
of extension-stuff which were proposed by you, e.g. templates, exceptions,
namespaces, were adopted, while several trivially small and well defined
extension proposals have fallen by the wayside.)

>I find Ron's observations about the workings of X3J16/ISO-WG mostly inaccurate and
>based on heresay...

I find that statement rather inaccurate and entirely inspecific.

You might as well just say that my mother wears army boots. :-)

>Standardizing a language in widespread use is neither easy nor fun and the people
>who actually struggle through that process deserves better than Ron's innuendo.

Hummm.... You're right.  How about if we give them all company-paid trips to
exotic and scenic destinations like Munich and Hawaii along with company-paid
first class accomodations.  (I know.  I know.  It's a tough job but somebody's
got to do it. :-)

>PS I think we have a decent chance at meeting the September '94 deadline for a
>draft standard.

A draft standard is one thing, and an *approved* standard is another.  The
current working paper could be send out to ballot today, but it would have
to go through so many repeated rounds of public review (to find and clean
up all of the holes) that we would not have an approved standard for at
least five years.

By the way, don't forget that I made a very explicit offer to take bets on
the *actual* completion date of the *actual* standard.  That offer still
stands, and I'm still looking for any takers.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In <comp.std.c++> rons@hardy.u.washington.edu (Ronald Schoenberg) writes:
>
>I can live without an exponentiation operator, but the attitude
>expressed above does bother me because of the lack of respect it shows
>for numerics programming.  I don't think that a standards committee
>should give in to every special interest.  On the other hand, the
>numerics programming community shouldn't be treated as just another
>special interest.

You can probably substitute any "X" for "numerics programming" and
people would agree with you.  One of the major problems in
standardization is the conflict of interests.

>....  There aren't so many numerics programmers doing C++
>right now and they are therefore under-represented on standards
>committees.  That will change, however, if the members of those
>committees will give them some respect.

I claim that you don't know what you're talking about, wrt to the
standards committee.

    -- Dag

In article <21flho$mg@news.u.washington.edu> rons@hardy.u.washington.edu (Ronald Schoenberg) writes:
>
>I can live without an exponentiation operator, but the attitude
>expressed above does bother me because of the lack of respect it shows
>for numerics programming.  I don't think that a standards committee
>should give in to every special interest.  On the other hand, the
>numerics programming community shouldn't be treated as just another
>special interest.
>   In my opinion C++ is the best chance numerics programmers have for
>breaking away from Fortran and into a language with widespread support
>and full features.  C is certainly not that language and I'm not for any
>change there.

I think you're way off base.  What *exactly* have you got against C?  Have
you ever tried it?  More to the point, have you ever tried using a C
implementation which supported the full range of features recently codified
as a set of industry recomendations by the Numerical C Extensions Group?

(Actually, I already know the answer to that last question.  No vendors have
fully implemented the NCEG recomendations yet, so you *can't* possibly have
tried such an implementation yet, as such compilers do not yet exist.)

I am in complete agreement with the sentiment that numerical programmers
are more than just another special interest.  And so are a lot of other
people.  In fact, the NCEG was formed expressely to investigate the exact
needs of this community of programmers, and to develop a set of specs for
how C could be extended to support them... something which the NCEG has
already done.

I really think that *serious* numerical programmer ought to look to C
(with the NCEG extensions) in the first instance to help them transition
out of Fortran.  Then, if you wait long enough, there may one day be a
C++ standard which may itself incorporate some or all of the NCEG recomen-
dations.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In <comp.std.c++> rfg@netcom.com (Ronald F. Guilmette) writes:
>
>Hummm.... You're right.  How about if we give them all company-paid trips to
>exotic and scenic destinations like Munich and Hawaii along with company-paid
>first class accomodations.  (I know.  I know.  It's a tough job but somebody's
>got to do it. :-)

Hmmm.  San Jose is more exotic than Munich to me (see signature).  I
only remember seeing Ron at one meeting, the one in San Jose, but I
could be mistaken.

People on the net should be relieved that Ron's comments on the
committee mail reflectors are much more constructive and interesting.

>A draft standard is one thing, and an *approved* standard is another.  The
>current working paper could be send out to ballot today, but it would have
>to go through so many repeated rounds of public review (to find and clean
>up all of the holes) that we would not have an approved standard for at
>least five years.

Exactly, and that is why we still spend time on the working paper
instead of just sending it out for ballot now.

Dag Bruck
--
Department of Automatic Control  E-mail: dag@control.lth.se
Lund Institute of Technology
P. O. Box 118    Phone: +46 46-104287
S-221 00 Lund, SWEDEN   Fax:    +46 46-138118

In article <rfgC9uAoB.L4D@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:

>I think you're way off base.  What *exactly* have you got against C?  Have
>you ever tried it?  More to the point, have you ever tried using a C
>implementation which supported the full range of features recently codified
>as a set of industry recomendations by the Numerical C Extensions Group?
>
>(Actually, I already know the answer to that last question.  No vendors have
>fully implemented the NCEG recomendations yet, so you *can't* possibly have
>tried such an implementation yet, as such compilers do not yet exist.)
>
[......]
>
>-- Ronald F. Guilmette ------------------------------------------------------
>------ domain address: rfg@netcom.com ---------------------------------------
>------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

For the issue is productivity.  I use the M++ array classes and I can
get about 10 lines of code in C++ do what would take hundreds of lines
of code in C.  I don't have to allocate any memory or mess with
pointers.  Or write endless numbers of loops cycling through data
arrays because I have overloaded operators that sift through the
largest data sets with a single expression.  I used to write in
Fortran, and I would estimate that my productivity has gone up
somewhere between five and ten times by moving to C++.  I don't think
that would happen in C.  I have on occasion worked in C, just as I am
occasionally forced to work in Fortran (i.e., when I'm working with
existing code), and the longer I'm in it the more dramatic becomes my
desire to get back to my array classes.
  I also do a lot of work using the Zortech compliler (the 3.0
version) which does incorporate the NCEG extensions.  The M++ classes also
incorporate the extensions.  You are correct about them - I think they
are necessary for good numerics programming.  However, it appears you
are incorrect about there being no C or C++ that has them.
--
Ronald Schoenberg                    fax: 206-727-6521
University of Washington           email: rons@u.washington.edu

In article <21gqc9$h5v@nic.lth.se> dag@control.lth.se (Dag Bruck) writes:
>In <comp.std.c++> rfg@netcom.com (Ronald F. Guilmette) writes:
>>
>>Hummm.... You're right.  How about if we give them all company-paid trips to
>>exotic and scenic destinations like Munich and Hawaii along with company-paid
>>first class accomodations.  (I know.  I know.  It's a tough job but somebody's
>>got to do it. :-)
>
>Hmmm.  San Jose is more exotic than Munich to me (see signature).  I
>only remember seeing Ron at one meeting, the one in San Jose, but I
>could be mistaken.

Hummm... San Jose may *seem* exotic, but if you had lived in this area
for most of your life (as I have, and as I still do) it would seem pretty
bland in comparison to Japan, or Sweden or some of the other interesting
places that x3j16 has met or is planning to meet.

So anyway, I really would love it if someone would buy me a fully company-
expense-paid trip to Japan or Sweden or Munich or Hawaii, but unlike the
vast majority of the people on the committee, I have no large company
behind me who is willing and able to pay for me to take these little
jet-set junkets.  (I'm an independent contractor.)  I'd gladly cut off
my right arm for the opportunity to enjoy the beer halls of Munich,
or to swim in the warm clear waters of Hawaii (as I have never been to
either of these places) let alone to have someone paying for my time PLUS
my expenses while I spend a week arguing my own point of view in x3j16,
but alas, I have no such sugar-daddy, so I have to wait for those rare
occasions when x3j16 comes to me rather than vise versa.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <21hc1v$ati@news.u.washington.edu> rons@hardy.u.washington.edu (Ronald Schoenberg) writes:
>
>For the issue is productivity.  I use the M++ array classes and I can
>get about 10 lines of code in C++ do what would take hundreds of lines
>of code in C.  I don't have to allocate any memory or mess with
>pointers.  Or write endless numbers of loops cycling through data
>arrays because I have overloaded operators that sift through the
>largest data sets with a single expression.  I used to write in
>Fortran, and I would estimate that my productivity has gone up
>somewhere between five and ten times by moving to C++.  I don't think
>that would happen in C.  I have on occasion worked in C, just as I am
>occasionally forced to work in Fortran (i.e., when I'm working with
>existing code), and the longer I'm in it the more dramatic becomes my
>desire to get back to my array classes.

Just to clarify, the real intent of my earlier message on this subject
(of numerical programming in C and/or C++) was to implicitly raise the
following question:  "Where were these folks who are complaining about
the lack of support for numerical programming in C++ when the NCEG was
doing its work, and preparing its recomendations?"

In other words, if you've got a serious beef with the way numerical pro-
gramming is supported in *either* C or C++, I think that you should (or
should have) taken in up with NCEG, as that seems to be the most appro-
priate group, and the most appropriate forum for the consideration of
such issues.

(And by the way, I have some hopes that the NCEG's work will be largely
folded into the final ANSI/ISO C++ standard.)

What I've seen here recently (in the discussion regarding an exponentiation
operator) is that some advocates are trying to make the claim that serious
numerical programming is significantly hampered by the lack of such a feature.
OK.  So let's pretend for the moment that I buy that point of view.  (I don't
really, but let's ignore that for the moment.)  If it is true that serious
numeric programmers really need a built-in operator to do exponentiation,
then I would imagine that this would be true for C as well as C++.  If it
is true for C, then why the blazes didn't these advocates bring their case
for an exponentiation operator to the NCEG in the first instance rather
than trying (in the first instance) to get x3j16 to buy into this feature?

Translation:  Should x3j16 really be treated as the dumping ground for *all*
of the ideas for nifty new language features that people think they would
like to have (or think that they *need* to have)?  I hope not.  Someone
made the point earlier that numerical programmers are more than just another
niche special interest group.  As I've said, I agree with that sentiment
entirely, as do a lot of other people, including all of the members of the
NCEG.  In fact, the whole area of numerical programming is SO important
that a special, highly-focused group (i.e. the NCEG) came together to write a
set of specs to help move C towards better support for numerical programming.
(This group even went so far as to obtain an official charter from ANSI,
and the group now operates under the designation x3j11.1.)

Bottom line:  I (for one) would be content to have the *real* heavyweight
numerical programming experts in the NCEG evaluate the degree to which
an exponentiation operator is indispensible, and I would like to know
what *they* think (in the first instance) more that I would like to know
what x3j16 thinks.  Separately, I would like very much to see x3j16 fold
essentially all of the specs developed by the NCEG (whatever those turn
out to look like) into the final C++ standard.

>  I also do a lot of work using the Zortech compliler (the 3.0
>version) which does incorporate the NCEG extensions.  The M++ classes also
>incorporate the extensions.  You are correct about them - I think they
>are necessary for good numerics programming.  However, it appears you
>are incorrect about there being no C or C++ that has them.

Quite true.  I stand corrected.  I forgot about Zortech.

(Footnote:  I know that Zortech is *claiming* to have implemented full
support for the whole range of NCEG floating-point recomendations, but
until I have a chance to beat on that particular compiler myself I'll
be a bit skeptical about this claim.  There are a lot of little subtleties
relating to the implementation of proper IEEE floating-point support in
either C or C++, especially on x86 machines, that are difficult to get
right.)

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <25957@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:

>   There is a new keyword, `compl,' that is a synonym for ~.

I think this alone is a bad idea.  Leave C++ as it was, including the
use of national chars.  The C++ programmer must use national chars
extensively anyway, as \ | ^ ~ (at least) and particularly {} [] are
all national chars.  Introduce a (possibly standard) complete set of
keywords `and' (&&), `or', `not' (!), `begin' {, `end' }, etc. as
#defines in a header file instead, not just this single, unnecessary
new keyword.

>   I also think it is unlikely that the committee will agree to
>   any new uses of operator symbols on the national-character list.

Though I am generally a fanatic proponent of concern for national
characters (using them myself), I would argue you will have to live
with them in C++ to such an extent that it makes no difference. (E.g.
{} and [].)

Just make sure the standard String class handles national characters!

 - geir
--
MSc Geir Halbo     !  Department of Computer Systems and Telematics (IDT)
Halbo@idt.unit.no  !  Norwegian Institute of Technology             (NTH)
+ 47 7 59 36 74    !  University of Trondheim                      (UNIT)
G=Geir; S=Halbo; OU=IDT; O=Unit; P=Uninett; C=No

In article <rfgC9u74I.IKC@netcom.com>, rfg@netcom.com (Ronald F.
Guilmette) writes:
> In article <25937@alice.att.com> bs@alice.att.com (Bjarne Stroustrup)
> writes:
> >
> >
> >rfg@netcom.com (Ronald F. Guilmette @ Netcom Online Communications
> Services (408-241-9760 login: guest)) writes
> >
> > > P.S. At this point in time, even if X3J16 totally ignored *all*
> suggested
> > > extensions (including the ones that Bjarne himeself is ramming...
> ummm...
> > > I'm sorry... "sheparding" through X3J16)
> >
> >For the record: I don't ``ram'' extensions through X3J16/ISO-WG.
>
> Yes.  Sorry about that.  As chariman of the extensions working group,
> you
> don't exactly have to.
>
> (It is interesting to note however that huge and rather poorly defined
> hunks
> of extension-stuff which were proposed by you, e.g. templates,
> exceptions,
> namespaces, were adopted, while several trivially small and well
> defined
> extension proposals have fallen by the wayside.)

It is always in the implementation that the truth of a spec is found. Well,
we implement this stuff here, so perhaps I can offer a counter opinion.

EH has very few holes in its definition. Certainly no major ones. Comparing
implementation notes with the HP/USL work has shown a very strong consistency
in our implementations. The minor things that have come up will be tidied
up at the committee.

PT sufferes a bit from other definitional problems in the language that are
being cleaned up as the language is being cleaned up. It also suffers from
being more closely linked to the compiler environment. It is also, hands down,
the most appreciated extension in the community using our compiler. In the
end, PT will also be complete, definitionally, because of the number of
implementors that will have it in their compilers. This was one reason, of
many, for including it in the Working Paper.

We haven't implemented 'namespaces' yet, but supposing that it is accepted
into the draft, we'll get started. Why? Because our user community has also
expressed a need for a solution in this area. That is, of course, the only
reason for doing any of this stuff.

To reiterate, I think that the extensions that have gone in since the
standardization process has started have been improvements. I also think
that encouraging implementors to implement the extensions results in
complete extensions. Lastly I don't believe that these extensions would
be implemented if they weren't in the Working Paper. Certainly not
as widely. Its fine to wish for implementations. The only way to get
them to happen is vote 'em in. In a world of conformance to standards,
it is hard to convince companies to invest in proprietary solutions.

>

[snip, snip, snip... lots of stuff .... snip, snip, snip]

> -- Ronald F. Guilmette ------------------------------------------------------
> ------ domain address: rfg@netcom.com ---------------------------------------
> ------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

--
Regards,

krk.

Kim Knuttila   | Do I need to say it?... oh why not
C/C++ Architecture  | IBM doesn't Speak for Me, I don't Speak for Them,
IBM Toronto   | but I do Speak for myself... Woof.
(416)448-2171

In article <rfgC9uutw.Gy0@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:

> So anyway, I really would love it if someone would buy me a fully company-
> expense-paid trip to Japan or Sweden or Munich or Hawaii, but unlike the
> vast majority of the people on the committee, I have no large company
> behind me who is willing and able to pay for me to take these little
> jet-set junkets.  (I'm an independent contractor.)  I'd gladly cut off
> my right arm for the opportunity to enjoy the beer halls of Munich,
> or to swim in the warm clear waters of Hawaii (as I have never been to
> either of these places) let alone to have someone paying for my time PLUS
> my expenses while I spend a week arguing my own point of view in x3j16,
> but alas, I have no such sugar-daddy, so I have to wait for those rare
> occasions when x3j16 comes to me rather than vise versa.

Let's see if we can push aside resentment for a few moments and look at facts.

Fact 1. When I go to standards meetings, I spend essentially all of my
 time there inside the hotel.  It is true that some hotels are
 more comfortable than others, but if you gave me a choice between
 holding a meeting in Murray Hill or anywhere else in the world,
 I would pick Murray Hill.  Instantly.  The travel is just not
 worth it.

Fact 2. There are no plans to hold meetings in Hawaii or Japan.  That
 might change for Japan, but it is essentially out of the question
 for Hawaii.

Fact 3. We do not go out of our way to find `nice' locations for meetings.
 Locations are set by two rules:

  a. Each meeting must be sponsored by a member.
     `Sponsor' in this context means supplying the
     meeting rooms, copying facilities, coffee breaks,
     and so on.  Given the size of the meetings, it costs
     about $10,000 to sponsor one.

  b. Each meeting must be held within 50 miles of
     the member's office.

 This virtually forces the meetings to be scattered all over
 the place; it's very hard to get anyone to sponsor more than one.

Fact 4. Company representatives may advocate their own viewpoint, but their
 companies aren't going to send them without evidence that their
 representatives' viewpoints are in the interests of the company.

Fact 5. It is sometimes possible for people to get someone other than
 their employer to pay for them to attend meetings.  I know of
 at least one person who has done so successfully.  This is
 much easier to do, of course, if you have some reason why
 it is in the prospective sponsor's interest to send you
 instead of someone else.

Fact 6. Some of the committee members are independent contractors who
 evidently believe it worth their while to attend.  For example,
 Reg Charney, Bill Plauger, Tom Plum, Jim Roskind, Dan Saks,
 Mike Vilot.  Tom Plum lives in Hawaii, so every meeting is
 a big trip for him.

If it's so important to you to be able to go on company-paid travel,
go work for a company that sends people to meetings.  You'll find that
it has both advantages and disadvantages.
--
    --Andrew Koenig
      ark@research.att.com

In article <GEIR.HALBO.93Jul8234702@villtind.ugle.unit.no> Geir.Halbo@ugle.unit.no (Geir Halbo) writes:

> I think this alone is a bad idea.  Leave C++ as it was, including the
> use of national chars.  The C++ programmer must use national chars
> extensively anyway, as \ | ^ ~ (at least) and particularly {} [] are
> all national chars.  Introduce a (possibly standard) complete set of
> keywords `and' (&&), `or', `not' (!), `begin' {, `end' }, etc. as
> #defines in a header file instead, not just this single, unnecessary
> new keyword.

A number of people on the committee felt that since ISO Latin-1
was on its way to becoming universal anyway, the issue would be moot.
However, some people pointed out that there were still large numbers of
terminals in existence that predated software-generated character sets,
and those terminals would probably be around for some time to come.
Moreover, even though your terminal may handle those characters, your
printer might not, or your operating system.

For that reason, the committee agreed to a collection of keywords and digraphs
intended to handle all the cases where national characters are required.
The C committee is doing the same thing for C; with a little luck the
two sets will be compatible :-)

There are two arguments, one of them fairly subtle, that using macros
for this purpose is no better than introducing new keywords.
One argument is that macros can't handle digraphs.  Thus if it
makes sense to use (< and >) as equivalents for { and }
(which I think is what the committee agreed to do), there is no
way a macro can accomplish that.

The subtle argument has to do with how such a header would be used.
Suppose for the sake of argument that the header is called <charmacros.h>,
so that saying

 #include <charmacros.h>

defines `begin' and `end' as synonyms for `{' and `{'.  The first observation
is that there is no good way for user-defined header files to use this
facility.

The reason for that is as follows: Suppose you are defining a library that
someone else will use.  Among other things you supply is a file called
"Lib.h" for your users to include.  May Lib.h include charmacros.h?

Unfortunately, the answer is no: if it did, and your user said

 #include "Lib.h"

that would turn on the macros whether the user wanted it or not.
Thus it would be safe for Lib.h to include charmacros.h only if there
were some way to save the previous state of the macros and restore them
at the end of Lib.h.  Unforunately, there is no way to do that without
somehow extending the preprocessor.

So we see that library authors cannot use a macro-based facility.  What
about people writing .c files?  Here, we have a new problem: even though
authors of header files shouldn't include charmacros.h, some of them will.
That means that for portability's sake, authors of .c files have to assume
that the macros will be turned on and avoid other use of those names.
Given that, they might as well turn on the macros themselves.

Moreover, the same argument applies to header files.  A user might say

 #include <charmacros.h>
 #include "Lib.h"

and for that to work, Lib.h must not use the names of the macros for any
other purpose.

Thus we have the following constraints on portable programs:

 Header files may not include charmacros.h, but must assume that
 it might have been included for them.

 .c files may include charmacros.h or not, but must assume that
 it might have been included anyway.

Thus for portable programs, macros have all the disadvantages of keywords
as well as the additional disadvantage that header files cannot profitably
use them.  Of course, nonportable programs might behave differently, but
the Standard addresses only portable programs.

It was this line of reasoning that led to the committee's adoption of
keywords instead of macros, even though the C committee is going with the
macro approach.

> >   I also think it is unlikely that the committee will agree to
> >   any new uses of operator symbols on the national-character list.
>
> Though I am generally a fanatic proponent of concern for national
> characters (using them myself), I would argue you will have to live
> with them in C++ to such an extent that it makes no difference. (E.g.
> {} and [].)
>
> Just make sure the standard String class handles national characters!
>
>  - geir
> --
> MSc Geir Halbo     !  Department of Computer Systems and Telematics (IDT)
> Halbo@idt.unit.no  !  Norwegian Institute of Technology             (NTH)
> + 47 7 59 36 74    !  University of Trondheim                      (UNIT)
> G=Geir; S=Halbo; OU=IDT; O=Unit; P=Uninett; C=No


--
    --Andrew Koenig
      ark@research.att.com

In article <C9vACE.EEM@hawnews.watson.ibm.com> knuttila@vnet.ibm.com writes:

> PT sufferes a bit from other definitional problems in the language that are
> being cleaned up as the language is being cleaned up. It also suffers from
> being more closely linked to the compiler environment. It is also, hands down,
> the most appreciated extension in the community using our compiler. In the
> end, PT will also be complete, definitionally, because of the number of
> implementors that will have it in their compilers. This was one reason, of
> many, for including it in the Working Paper.

Perhaps a more important reason is that the original letter in which
Hewlett-Packard officially requested the formation of the committee
explicitly said that templates (and exceptions) should be part of the
standard.  Those two particular features therefore have special status,
not through any action on Bjarne's part, but because of what HP did
before the committee was even formed.  All other new feature proposals
have had to stand up to more detailed scrutiny than templates or EH.
Incidentally, at the time, both Bjarne and I argued against forming the
committee at that time, saying that it was premature and we should have
more implementation experience with templates and exceptions first.

It might also be worth pointing out that neither of us has ever held a
voting position on the committee.  The first AT&T representative was
Peggy Quinn [as distinct from Peggy Ellis], followed by Jonathan Shopiro
[as distinct from Jonathan Shapiro], both from USL.  Now that USL is a
subsidiary of Novell rather than of AT&T, Jonathan will represent Novell;
AT&T's representative will be Drew Lettington from NCR.
--
    --Andrew Koenig
      ark@research.att.com

In article <1993Jul6.103211.779@dcs.warwick.ac.uk>
steve@maths.warwick.ac.uk (Steve Rumsby) writes:

|> In article <rfgC9KttA.AKq@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
|> |> P.S. At this point in time, even if X3J16 totally ignored *all* suggested
|> |> extensions (including the ones that Bjarne himeself is ramming... ummm...
|> |> I'm sorry... "sheparding" through X3J16) the committee would *still* not
|> |> be able to produce anything approximating a clear and unambiguous standard
|> |> for at least three years past the originally scheduled completion date.
|> |>

|> I think this is very unfair, both to Bjarne and to the rest of the
|> committee.  Bjarne would not try to "ram" anything through the
|> committee, and the they would not let him if he tried. There are
|> enough diverse opinions and experiences represented on the committee
|> that no one person, not even Bjarne, could hope to influence the
|> proceedings in the way suggested above.

This is probably unfair to Bjarne.  I was at the Portland meeting, and
my impression was that Bjarne himself is very sensitive concerning his
role in the language development, and concerned *not* to ram things
through.

On the other hand, for many people, he *is* the language's founder, so
when he suggests something, they do the ramming.  And the ramming is
happening, even if I don't think that Bjarne is actually part of it,
or even approves of it.

This, of course, has nothing to do with the question of whether the
extensions are putting the standards at risk.  My personal opinion is
that they are, and getting the core issues right must be our first
priority.  I know (since he said so in Portland) that Bjarne thinks
that most of the people working on extensions would not work on the
core issues anyway, so the extensions will not cause any delay in the
standards.  I would feel better about this point of view if I felt we
were making any real progress on the core issues, and if I could be
convinced that the extensions will not introduce more problems in the
core.  (Templates are a major offender here.)

My present impression, however, is that the only way we have any
chance of getting a standard done before 1996 is by dropping *all*
extensions, including templates and exceptions, and all libraries
except iostream and new/delete, and putting all of our efforts on the
core.

|> This standards process is *hard work*. Nobody on the committee is
|> playing at it.  Anybody who didn't take the work seriously would not
|> still be doing it.

|> Ron has contributed much to the process, and the final standard will
|> be better because of it, but I couldn't let this pass.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

>>>>> "Andrew" == Andrew Koenig <ark@alice.UUCP> writes:

Andrew> The C committee is doing the same thing for C; with a little luck the
Andrew> two sets will be compatible :-)

This seems unlikely given

Andrew> Thus if it makes sense to use (< and >) as equivalents for {
Andrew> and } (which I think is what the [ C++ ] committee agreed to do),
Andrew> there is no way a macro can accomplish that.

and

Andrew> [ ... ] even though the C committee is going with the
Andrew> macro approach.

It seems like we will and up with two incompatible solutions to a
problem many ISO 646 users would prefer to see unresolved.

In article <rfgC9uAoB.L4D@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>I really think that *serious* numerical programmer ought to look to C
>(with the NCEG extensions) in the first instance to help them transition
|out of Fortran.  Then, if you wait long enough, there may one day be a
|C++ standard which may itself incorporate some or all of the NCEG recomen-
|dations.
|
|--

I disagree.  I see the NCEG work as a terrible historical mistake.
The serious numerical programmer needs the abstractions that C++
provides.  This is the reason a great deal of numerical programmers
are moving to C++ in spite of its imperfections for numerical work.
The great disappointment to me is the great deal of work that NCEG is
doing which is directly in conflict with C++, or which already
has better solutions within C++.  Thus I see the NCEG branch off
of C as being a big backwards mistake.  If this work was based off of C++
to begin with *then* and only then would significant progress be made for
the serious numerical programmer.  Time for NCEG to move forward and
become NC++.

In article <25972@alice.att.com>, ark@alice.att.com (Andrew Koenig) writes:
> In article <rfgC9uutw.Gy0@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:

> > So anyway, I really would love it if someone would buy me a fully company-
> > expense-paid trip to Japan or Sweden or Munich or Hawaii, but unlike the
> > vast majority of the people on the committee, I have no large company
> > behind me who is willing and able to pay for me to take these little
> > jet-set junkets.  ...

Yes, but what happens when that big company decides to send you on a trip
you _don't_ want to take?  You spend twelve days living in a lab in the
basement of some customer's factory in Midville, Louisiana in August, with
an occasional trip to the Holiday Inn for a shower ... and you realize that
the reason the customer can't get your product to work is that they should
be hiring chimpanzees instead of whoever they've managed to hire ...

> > ...  I'd gladly cut off my right arm for the opportunity to enjoy the
> > beer halls of Munich ...

When our X3J16/WG21 friends get back, let's see how many beer halls they
had a chance to visit.  There are four and a half days of meetings, with
evening sessions scheduled for presentations on technical issues (sometimes
two a night).  And, given the stuff under discussion, catatonia is the order
of the day.

> > ... but alas, I have no such sugar-daddy, so I have to wait for those rare
> > occasions when x3j16 comes to me rather than vise versa.

Hey, if anybody has a spare sugar-daddy (_not_ a Sugar Daddy, Mikey!) I'll
be happy to meet him/her/it.

> Let's see if we can push aside resentment for a few moments and look at facts.
>
> Fact 1. When I go to standards meetings, I spend essentially all of my
>  time there inside the hotel.  It is true that some hotels are
>  more comfortable than others, but if you gave me a choice between
>  holding a meeting in Murray Hill or anywhere else in the world,
>  I would pick Murray Hill.  Instantly.  The travel is just not
>  worth it.

Never mind that hotels sometime provide conference facilities that stink.
Seems to me in Portland we had meeting rooms in the basement, the third
floor, and the twenty-Nth and twenty-Nth+1 floors.  Meanwhile, there were
two conventions that were holding balls day and night, and the elevators,
inadequate to begin with, had three of the four cars jammed at all times
with inane, vapid people wearing tuxes and gowns so that after you waited
your twenty minutes for the elevator, you found that there was no room in
the car, whether it was going up or down.  (There were ballrooms both above
and below.)  The fourth car?  Oh, it was out of service.  And, as several
people discovered, one of the emergency stairwells emerged in the hotel
kitchen ...

And we couldn't even _get_ coffee service anywhere but in the basement.
It was on china, so it was hard to carry upstairs, and it was only there
in the morning.

Skip Hilton.  Schedule the next one in a George Washington just off the
Pennsylvania Turnpike.  With luck, they'll appreciate the business.

No, Ron, the travel isn't worth it--what is worth it is getting to work with
the people: with Andy and Bjarne and Dag and Tom and Reg and all the rest.
With luck, you even find a decent place for lunch.  With better luck, you
are having so much fun discussing the latest management gaff that you don't
notice.
--
 (This man's opinions are his own.)
 From mole-end    Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ

In article <25886@alice.att.com> ark@alice.UUCP () writes:
>In article <rfgC9FE01.ALz@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>> I did make a statement that C++ compilers should be able to accept and
>> ignore the `static' keyword in places where this very same keyword is
>> accepted and ignored by ANSI C compilers.
>
>Of course it should.  This is not at issue, and has never been.

I beg to differ.  ARM, section 7.1.1, page 98 says:

 The static and extern specifiers can be applied only to names of
 objects and functions.

 In particular:

  static class X {  // error
   int a;
   // ...
  };

Now my interpretation (and that of another knowledgable implementor I know)
of the above section of the ARM is that the following (very similar) example
must also be diagnosed as containing an error by any self-respecting C++
compiler:

  static struct X {  /* error */
   int a;
   /* ... */
  };

(The only difference between this example and the one shown in the ARM on
page 98 is that this one uses the `struct' keyword rather than the `class'
keyword... but that is just an irrelevant and trivial detail.)

Now, please note that (as I have pointed out repeatedly) the above code is
perfectly valid and acceptable ANSI C code.

So you are just plain wrong.  There *is* very clearly a C/C++ compatability
issue here.  Any existing ANSI C code containing usage like that shown above
will get errors when compiled as C++ code.

I wish that this were not the case (as C++ is already far to incompatible
with ANSI C for my liking) but the ARM clearly specifies this (frivolous
and unnecessary) incompatability.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

   cpeck@uckbv5.ece.uc.edu (Charles Peck) writes:
   >One extension he [Stroustrup] lists as rejected or withdrawn is:
   >
   >>    Exponentiation operator
   >
   >My question is quite simple: Why?  Does anyone know the reasoning behind this?

   You already have pow().  And what operator would you use?  You can't
   use a**b (what if b is a pointer).

The proposal suggests operator ~ , which has none of the syntactic
problems that concern you.  Pow is, for some programmers,
syntactically inconvenient.



   We seem to forget that any change to the language is enormously
   expensive.  Every compiler vendor would have to modify their software,
   and every programmer would have to allow for either version of the
   compiler for several years afterwards.  Even the most trivial
   change might break somebody's code.  The benefit of the change
   is small, and can't justify the cost.  Nearly all proposed changes
   are rejected for this reason.

I disagree.  Some language changes are more expensive than others.
The recent namespace extension required 5 days to implement, according
to Stroustrup in the latest "C++ Report", and is no easier than the
exponentiation extension.  Extensions that to not change the meaning
of any pre-existing code, like the exponentiation proposal, but only
give meaning to previously invalid code, cannot be said to require
programmers to do anything.  Don't change old code, don't use the new
feature, and you are not harmed by it.  All extensions should be
subject to the cost-benefit ratio test; the proposed exponentiation
operator is low cost, and benefits a minority of programmers.  If that
test were applied fairly, recent extensions like the new operators
new[] and delete[] for array allocation would not have been accepted
either.

Flames to /dev/null.  I'll be on vacation and unable to read them
anyway.

Doug Moore
(dougm@cs.rice.edu)

In article <C9Js78.E7F@jabba.ess.harris.com>
 mvm@epg.harris.com (Matt Mahoney) writes:

>We seem to forget that any change to the language is enormously
>expensive.  Every compiler vendor would have to modify their software,
>and every programmer would have to allow for either version of the
>compiler for several years afterwards.

The ANSI C committee adopted the position "existing code is important;
existing implementations are not".  It's already a lot of work to support
an ANSI C++ compiler.   Adding a new operator should be relatively cheap:
I added exponentiation to g++ in a couple hours; I might have spent a day
on it if I wanted to do more testing and optimization.

I've decided for C programs that I'm going to assume a useful large
subset of ANSI C (prototypes, const, volatile, the common and useful
library functions, but not wide characters) and not attempt to support
old compilers.  I will probably do the same once ANSI C++ is standarized:
use the useful new features unconditionally.

There are a lot of people who make the same choice -- assume ANSI C or
close enough and don't make use of ANSI features conditional -- for
different reasons (for example, a program that's only going to run on one
machine).

Incompatible changes ("quiet changes" or changes that break existing code)
can have a major effect on programmers for years, but the exponentiation
operator was not such a change.

--
    John Carr (jfc@athena.mit.edu)

In article <212tii$5nb@senator-bedfellow.MIT.EDU> jfc@athena.mit.edu (John F Carr) writes:
>...   Adding a new operator should be relatively cheap:
>I added exponentiation to g++ in a couple hours; I might have spent a day
>on it if I wanted to do more testing and optimization.

I have two things to say about this.

First, John Carr seems to forget that every clown who has ever written a
line of C++ code also has his own pet ideas for how to extend the language.
The majority of these may also be no-brainers to add to existing implementa-
tions.  But so what?  People who want to hack their favorite implementation
(and who have access to the source) to add their own pet extensions will
always be free to do so.  (It's a free country after all!)  The issue in this
thread (and in the newsgroup) is what extensions will be *imposed* upon
all implementors, all users, and all teachers of the language (for the
indefinite future).  Now I don't give a flying $%%^&*# what *you* want to
do with your implementation, or with your code, but when people start
going out of their way to make a language I'm trying to use harder to
use, harder to learn, harder to teach, and harder to standardize, then I
start to get a little testy.

Second, I note that John says that he hacked an exponentiation operator into
g++ in a couple of hours, but that he didn't really test it or try to
optimize it.  That's fine in the world of free software, but some people
who make their living writing code have somewhat more rigorous requirements
regarding the quality and reliability of their tools (e.g. compilers).

Summary:  People who want their own "extended" C++ features are always welcome
to play as much as they like in their own private sandboxes.  But this kind
of free-form playing should not be confused with the serious (and very time
consuming) business of getting a basic international programming language
standard finished up or with creating production quality compiler tools.

P.S. At this point in time, even if X3J16 totally ignored *all* suggested
extensions (including the ones that Bjarne himeself is ramming... ummm...
I'm sorry... "sheparding" through X3J16) the committee would *still* not
be able to produce anything approximating a clear and unambiguous standard
for at least three years past the originally scheduled completion date.

P.P.S.  With regard to the above estimate of the minimum amount by which
X3J16 will blow their schedule, I'm confident enough of my estimate to be
willing to bet money on it.  Any takers?  (Will I have to give odds?)

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In response to rfg's comments I should clarify a few points in my
earlier message:

I'm not supporting or opposing standardizing the exponentiation operator.
There's a moderate but not large chance that I would use it some time in
the next two years if compilers supported it.  Others have said they would
use it.  Most C++ users wouldn't care.

I wrote the extension so that the proposal could be considered on its
merits instead of being rejected due to lack of an implementation or
programs which used the extension.

Exponentiation is a very small addition to a compiler.  Even with the
type of testing and quality control that a good compiler should have
exponentiation is lost in the noise: if I were doing a cost estimate
to convert a pre-ANSI C++ compiler to ANSI C++, I'd probably give the
same answer with or without exponentiation.

I don't know how much committee time it costs to approve an extension
relative to the time to reject an extension, but that's not relevant
to what I was saying.

Rejection may be justified because it would delay the standard, and it
might also be justified because considering good ideas that aren't
essential to the language is outside the charter of the committee, but
I don't think "it would take too much time to implement" is a good reason
to reject the proposal.


--
    John Carr (jfc@athena.mit.edu)

In article <1993Jun27.155845.28679@ucc.su.OZ.AU>
maxtal@physics.su.OZ.AU (John Max Skaller) writes:

|> >>    Exponentiation operator

|> >My question is quite simple: Why?  Does anyone know the reasoning behind this?

|> >I have seen many flare ups on this subject, with some apparently well
|> >conceived proposals.  My intention is not to instigate another of these
|> >debates.  Rather, my intention is simply to understand the reasoning of the
|> >committee.

|>  The exponentiation operator supposedly had limited appeal
|> (specialised for numerical work), had difficulties
|> in definition, and provided only one advantage
|> that 'pow' does not: clean syntax.

|>  This wasnt considered enough to justify an extension.
|> However, one of the ideas in the proposal, a specific version
|> of pow that accepts an integral index, will probably make it
|> into the standard library.

In sum, the committee has decided to do the hard part (handling the
difficulties in definition, which will be necessary for the library
function too), and forgo the easy part (extending the syntax).
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <215t2r$sv4@senator-bedfellow.MIT.EDU> jfc@athena.mit.edu (John F Carr) writes:

> Exponentiation is a very small addition to a compiler.

I wish that were true.  It is a very small addition to a parser, but
there is a *lot* of other work to do.

For example, what should the language guarantee about accuracy?
If x is a floating-point value, it should presumably be guaranteed
that x~2 (I'll use ~ for exponentiation in this note) is equal to
x*x.  But what about x~3?  Should that be required to be equal to
x*x*x?  Or should x~3 be required to be the closest possible approximation
to x cubed?  The two are not necessarily the same, because x*x*x is
not the most accurate possible way of cubing x.

Either way you do it, you lose in some cases.  For example, if x~3
is not required to be equal to x*x*x, then an optimizer can't rewrite
x~3+3*x~2 as x*x*(x+3).  On the other hand, if x~3 IS required to be
equal to x*x*x, then x~3 won't be equal to pow(x,3), assuming a
careful implementation of pow that always returns the most accurate
result possible.

This problem becomes even worse for 4th powers, because x~4 might be
evaluated as ((x*x)*(x*x)) or x*(x*x*x), neither of which is guaranteed
to produce the most accurate possible result.  That means there are at
least three legitimate values for x~4; which one should we pick?

Finally, one might argue that x~2 should be equivalent to x*x even
if x is of user-defined type -- so long as x*x is well-defined and
~ isn't explicitly overridden.  That is, of course, the most straightforward
way of obtaining sensible results of x is, say, of class Complex.
But now we have the possibility that user-defined * isn't even
associative, let alone commutative.  How much implementation latitude
should be allowed?  And so on.

I'm not claiming these questions don't have answers, but I shudder to
think how much committee time it would take to answer them.
--
    --Andrew Koenig
      ark@research.att.com

In article <25936@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:

>> Exponentiation is a very small addition to a compiler.
>
>I wish that were true.  It is a very small addition to a parser, but
>there is a *lot* of other work to do.

[Lots of examples about round-off and equivalence semantics deleted]

I don't see how this is relevant.  All we (proponents of
an exponentiation operator) are asking for is a character or two
to be defined as a right-associative high priority operator.  Forget
about semantics.  I would think this kind of flexibility would
be quite useful.  Mathematicians use such things all the time for
the expression of various different functions.  I don't see why
this is such a complex thing to do.

>Finally, one might argue that x~2 should be equivalent to x*x even
>if x is of user-defined type -- so long as x*x is well-defined and
>~ isn't explicitly overridden.
That's silly.  You might as well get rid of * because one might
argue that x*2 must equal x+x even for user defined types!  Same goes
for all this discussion of numerical issues; replace * with + and
~ with * and you have the same problem.

If it bothers everyone so much, forget about exponentiation, I just
want a right associative binary operator with precedence higher than / & *.
What's wrong with that?

Dale Schouten
schouten@uiuc.edu

rfg@netcom.com (Ronald F. Guilmette @ Netcom Online Communications Services (408-241-9760 login: guest)) writes

 > P.S. At this point in time, even if X3J16 totally ignored *all* suggested
 > extensions (including the ones that Bjarne himeself is ramming... ummm...
 > I'm sorry... "sheparding" through X3J16)

For the record: I don't ``ram'' extensions through X3J16/ISO-WG. It is by no means
certain that I could ram one extension through if I tried. I certainly couldn't do
it twice.

I find Ron's observations about the workings of X3J16/ISO-WG mostly inaccurate and
based on heresay. Similarly, I find his conjectures about the X3J16/ISO-WG members'
understanding of C, C++, etc. widely off the mark. There are far more expertise and
good will in the committee than Ron seems willing to acknowledge.

Standardizing a language in widespread use is neither easy nor fun and the people
who actually struggle through that process deserves better than Ron's innuendo.

 - Bjarne

PS I think we have a decent chance at meeting the September '94 deadline for a
draft standard.

ark@alice.UUCP () writes:
>> Exponentiation is a very small addition to a compiler.
>
>I wish that were true.  It is a very small addition to a parser, but
>there is a *lot* of other work to do.
>
>For example, what should the language guarantee about accuracy?

The same thing it guarantees about the accuracy of the * operator:
nothing at all.  This argument was a red herring the last time
you brought it up and is a red herring now.

>If x is a floating-point value, it should presumably be guaranteed
>that x~2 (I'll use ~ for exponentiation in this note) is equal to
>x*x.  But what about x~3?  Should that be required to be equal to
>x*x*x?  Or should x~3 be required to be the closest possible approximation
>to x cubed?  The two are not necessarily the same, because x*x*x is
>not the most accurate possible way of cubing x.

Replace * and ~ in the above with + and *.  You can create the same
sort of example, but no one would advocate that * therefore not be
implimented.

In any case, you're talking about differences in the least significant
bit, differences that would affect code only if people expected floating
point computations by different paths to come out exactly equal.

>I'm not claiming these questions don't have answers, but I shudder to
>think how much committee time it would take to answer them.

Zero time should be spent answering them, unless the committee wants to
mandate something like the IEEE floating point standard for all floating
point computation.  (It won't).  Since the committee says nothing about
the mathematical accuracy of floating point operations in other cases,
it should treat any hypothetical new operator on an equal basis.


--
Joe Buck jbuck@ohm.EECS.Berkeley.EDU

Andrew:

ark@alice.att.com (Andrew Koenig) writes:

> It is a very small addition to a parser, but there is a *lot* of other
> work to do.

If there is indeed a lot of other work to do, then definitely the
committee should concentrate on other things besides giving pow() a
slightly better syntax.


> For example, what should the language guarantee about accuracy?

Why need the committee say anything about accuracy?

For ordinary use, so what if the least significant bits get a bit off.
Right now you can't say `assert((x / 3 * 3)  ==  x)' anyhow.

For number-crunching, ya already have to deal with
mathematically-correct formulae that make the error term too big, so
what's wrong?

> Finally, one might argue that x~2 should be equivalent to x*x even
> if x is of user-defined type

Er, well, the thing where some operators imply other operators might be
a fine thing if it was already in the language. Writing operator == and
getting a free operator !=, or a free operator + from operator +=, or
operator -> from operator*, would indeed be very convenient.

But since it's not part of the language now, it's not standing in the
way of the would-be exponentiation operator.

        Tom

--
The Tom spreads its huge, scaly wings and soars into the sky...
(tob@world.std.com, TomBreton@delphi.com)

I have a question related to Bjarne Stroustrup's posting regarding extensions
to C++.  I haven't followed this group closely for about a year, so if the
subject is particularly well trodden, please forgive me (I did check to FAQ
first, just to be sure).

In article <25699@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) provides
many criteria for evaluating extensions.  He also lists extensions that have
been approved, rejected or withdrawn, and are pending or suggested.  One
extension he lists as rejected or withdrawn is:

>    Exponentiation operator

My question is quite simple: Why?  Does anyone know the reasoning behind this?

I have seen many flare ups on this subject, with some apparently well
conceived proposals.  My intention is not to instigate another of these
debates.  Rather, my intention is simply to understand the reasoning of the
committee.

Any insights will be appreciated,
Charles Peck
--
Charles Peck   ML #30
(513) 556-6297    Dept. of Electrical and Computer Engineering
cpeck@uckbv1.ece.uc.edu  University of Cincinnati, Cincinnati, OH 45221

In article <25807@alice.att.com>, ark@alice.att.com (Andrew Koenig) writes:
|> > Good question.  This is just another C (in-)compatability wart in my
|> > opinion... and an almost totally pointless one.
|>
|> This kind of behavior seems to be almost universal among people interested
|> in the C++ language: one moment they're saying that the language has enough
|> stuff in it already and the next moment they're proposing a new feature.
|>
|> I don't mean to single out Ron here -- he just happened to provide a
|> convenient example.  As far as I can tell, almost EVERYONE does this.
|> For example, when Bjarne sent in his paper to the "History of Programming
|> Languages" conference, he told me that essentially every reviewer told him
|> that his paper was too long and then gave him a list of things to add.

Being more concise and more general are often not conflicting goals.
Conflicts usually arise only if there are other constraints, such as
backwards compatibility (as in C++) or very limited design time (as in
revising a paper).

I'm quite confident that if we were willing to break with C++ backwards
compatibility (but even maintaining C interoperability), many of C++'s
serious deficiencies and limitations could be fixed, while at the same
time simplifying the language.  But since backwards compatibility
with early versions of C++ is what defines C++ (rather than some other
OO extension of C), that's not an option.

      Thomas.

In article <1993Jun23.171846.26235@borland.com> pete@borland.com (Pete Becker) writes:
>In article <1993Jun23.103931.24251@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>>In article <1993Jun22.214246.27155@borland.com> pete@borland.com (Pete Becker) writes:
>>> The key here is that type names do not have linkage.
>>
>> Sure they do. C++ class names have extern linkage.
>> In C++ *all* file-scope names have linkage.
>> See 3.3.
>>
>
> You're absolutely right. This is a change from C.

 The change with respect to classes is intentional.
The change to not having 'no linkage' might have been
an ommission.

 f() {
  float x;
 };

Should 'x' really have internal linkage?

There is a proposal to re-introduce 'no linkage'. I feel inclined
to accept this. Any comments?

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <20evjs$b77@babbage.ece.uc.edu> cpeck@uckbv5.ece.uc.edu (Charles Peck) writes:
>I have a question related to Bjarne Stroustrup's posting regarding extensions
>to C++.  I haven't followed this group closely for about a year, so if the
>subject is particularly well trodden, please forgive me (I did check to FAQ
>first, just to be sure).
>
>In article <25699@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) provides
>many criteria for evaluating extensions.  He also lists extensions that have
>been approved, rejected or withdrawn, and are pending or suggested.  One
>extension he lists as rejected or withdrawn is:
>
>>    Exponentiation operator
>
>My question is quite simple: Why?  Does anyone know the reasoning behind this?
>
>I have seen many flare ups on this subject, with some apparently well
>conceived proposals.  My intention is not to instigate another of these
>debates.  Rather, my intention is simply to understand the reasoning of the
>committee.
>

 The exponentiation operator supposedly had limited appeal
(specialised for numerical work), had difficulties
in definition, and provided only one advantage
that 'pow' does not: clean syntax.

 This wasnt considered enough to justify an extension.
However, one of the ideas in the proposal, a specific version
of pow that accepts an integral index, will probably make it
into the standard library.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

[ much discussion on type names with internal/no linkage ]

I don't quite see the need to invent a new syntax to hide a "top
level" type name, if name spaces are being adopted.

==pena
--
Olli-Matti Penttinen <pena@niksula.cs.hut.fi>
Lehdesniityntie 3 F 91
00340 HELSINKI, Finland            "When in doubt, use brute force."
tel. + 358 0 1399 0110                -- Ken Thompson

In article <25820@alice.att.com> ark@alice.UUCP () writes:
>In article <rfgC91JEK.182@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>
>> "selective reading" on my prior posting.
>> He fixated on my suggestion that things like:
>
> static struct S { int member; };
> static enum color { red, green, blue };
>
>> should be allowed, and he seems to have failed entirely to notice that I
>> also mentioned the fact that in ANSI C, the names of types simply DO NOT
>> HAVE EXTERNAL LINKAGE.  Thus, in C, the above declarations are precisely
>> and exactly equivalent to:
>
>>  struct S { int member; };
>>  enum color { red, green, blue };
>
>True.
>
>> In other words, the `static' specifiers in the previous set of declarations
>> are entirely superfluous in C, and they are (in effect) simply ignored by
>> any conformant ANSI C compiler.
>
>Not quite true.  It is true for these particular declarations...

So what was I talking about???  I agree that my statement applied to the
things that I said (very plainly) it applied to.  I also agree that the
statement I made did not (and does not) apply to my dog, spot, to the
history of metaphyisical thought in western literature, or to the price
of yak fat in Tibet.

In other words, if you want to disagree with what I have said, please try
to understand that I meant exactly what I said, and nothing else.  In
particular, I did not mean something else that you seem to wish to
interpret me to have really meant.

>> What I suggested was that this should be the case in C++ also, for the sake
>> of compatability with ANSI C.  Now perhaps this constitutes a "new feature",
>> but it does not exactly provide any new functionality to the programmer.
>
>Of course it does.  The linkage of class names is one of the areas in
>which C++ is deliberately different from C.  This difference is closely
>tied up with the difference between structural equivalence and...

There you go again... trying to fit *my* words into *your* mental framework.

I guess I have to try to clarify this again.

I did not make a statement relating to the linkage of classes in C++, or
relating to whether or not it should be possible to control such linkage.

I did make a statement that C++ compilers should be able to accept and
ignore the `static' keyword in places where this very same keyword is
accepted and ignored by ANSI C compilers.

The capability for a compiler to ignore a given keword in a given context
does NOT provide new functionality in the language, not matter how many times
you erroneously say that it does.

I don't mind if you want to disagree with what I have said, but if you
choose to do so, please do make some effort to understand what I REALLY
said, not what you belived you thought you heard me say.

The linkage (or non-linkage) of class types in C++ is a matter wholly
separate from (and by and large unrelated to) the issue of whether or not
C++ compilers can or can not ignore the `static' keyword in certain
contexts where ANSI C compilers already ignore it.

It is rather silly for you to disagree with me about the former issue
when I have in fact been attempting to express my views on the latter
issue.  Once again, let me stress that these are two different and
unrelated issues.

>> It is a pity that this simple message was so completely misconstrued, but
>> it does illustrate (I think) the level to which ignorance of the ANSI C
>> standard abounds in the C++ community (and also in the C++ standardization
>> committee).
>
>Tom Plum, Bill Plauger, and Sam Harbison are on the C++ committee.
>If you think they're ignorant of C, whom do you think isn't?

Having worked on C++ for so long you should know that the cardinal rule is
that for every general rule there are a few exceptions.

You named three members of x3j16 (out of 100+ members?) who are on really
intimate terms with the ANSI C standard.  (I could name perhaps two or
three more, but so what?)

I think the very fact that you could only come up with three names actually
tends to support my earlier statement.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <rfgC9FE01.ALz@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:

> >> In other words, the `static' specifiers in the previous set of declarations
> >> are entirely superfluous in C, and they are (in effect) simply ignored by
> >> any conformant ANSI C compiler.

> >Not quite true.  It is true for these particular declarations...

> So what was I talking about???  I agree that my statement applied to the
> things that I said (very plainly) it applied to.

I meant exactly what I said.  Your statement is not quite true:
the "static" specifiers are superfluous (so that part of the statement
is true) but they are not simply ignored (so that part of the statement
is not true).  If they were simply ignored, then there would be no way
to distinguish a declaration with the "static"

 static struct foo {
  int a;
 };

from one without it:

 struct foo {
  int a;
 };

But there is a way -- merely insert "static" in front of each one:

 static static struct foo {
  int a;
 };

 static struct foo {
  int a;
 };

Now the first one becomes invalid and the second does not.

A compiler that fails to make this distinction cannot be a conforming compiler.
A compiler that ignores "static" in the first example above cannot make
this distinction.
Therefore no conforming compiler can ignore "static" in this context.

> In other words, if you want to disagree with what I have said, please try
> to understand that I meant exactly what I said, and nothing else.  In
> particular, I did not mean something else that you seem to wish to
> interpret me to have really meant.

And I also meant exactly what I said, and nothing else.  I did not think
it would be necessary to go into this much detail, but you seem to insist.

> I did make a statement that C++ compilers should be able to accept and
> ignore the `static' keyword in places where this very same keyword is
> accepted and ignored by ANSI C compilers.

Of course it should.  This is not at issue, and has never been.

> I don't mind if you want to disagree with what I have said, but if you
> choose to do so, please do make some effort to understand what I REALLY
> said, not what you belived you thought you heard me say.

Ditto.  I couldn't have said it better myself.

> You named three members of x3j16 (out of 100+ members?) who are on really
> intimate terms with the ANSI C standard.  (I could name perhaps two or
> three more, but so what?)

> I think the very fact that you could only come up with three names actually
> tends to support my earlier statement.

Hmmm... If I remember correctly, you said you thought it was a pity that
the C++ committee was not populated by experts in the C standard.  In that
case, I must continue to disagree -- there are plenty of expert C programmers
on the C++ committee but I don't think having additional experts in the
C standard would help.  There are relatively few issues that come up in
the meetings for which knowledge of the C standard is relevant in that
level of detail; when such issues do come up they are invariably referred
to one of the people know the appropriate details.

In any event, since the committee is open to anyone who wants to pay dues,
such regrets are moot.
--
    --Andrew Koenig
      ark@research.att.com

One possible way to specify a static class would be something like:


class x : static ...

Since static is a reserved word, the syntax would be unambiguous.

In article <1993Jun15.214156.3591@mole-end.matawan.nj.us> mat@mole-end.matawan.nj.us writes:
>In article <1993Jun14.150349.778@udel.edu>, carroll@hercules.cis.udel.edu (Mark C. Carroll) writes:
>> In article <rfgC8KuAB.FKu@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>> >I find it a particularly telling comment that (in the context of an ANSI/ISO
>> >standardization effort) a strong committment to the plain and simple
>> >standardization of existing practice is considered to be a view held only
>> >by radical extremists.
>>
>> It *would* be telling, if it were a comment given by nearly any other
>> standardization process. The problem with saying that about C++ is, at
>> the time the standardization process started, there was virtually no
>> existing practice to build on! The design of the language was not, and
>> still is not, finished.  ...
>
>These extensions are not extensions in the usual sense of the word.  They
>are the completion of one or another major part of the language.

Humm... well... I guess a Rolls-Royce is just a Volkswagon which has been
"completed". :-)

All I can say is that I have some hope that all those folks who are working
feverishly to build a Rolls-Royce (ahem... I mean to "complete" the Volks-
wagon) will occasionally stop and remember that a lot of people are more
than happy with Volkswagons.  They work today, and they are economical to
operate.

Now don't get me wrong.  I like a good Rolls-Royce as much as the next guy,
but given my immediate needs, I'll take the Volkswagon today, rather than
the Rolls-Royce in (maybe) five years.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <rfgC9086A.8xv@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:

> Now don't get me wrong.  I like a good Rolls-Royce as much as the next guy,
> but given my immediate needs, I'll take the Volkswagon today, rather than
> the Rolls-Royce in (maybe) five years.

and in  <rfgC908xI.AMv@netcom.com> he writes:

> In article <C8qDu4.6Jw@sugar.NeoSoft.COM> daniels@NeoSoft.com (Brad Daniels) writes:
>> Section 3.3 of the working document makes explicit mention of the fact
>> that it is not possible to declare a class name static.  What is the
>> rationale behind this restriction?

> Good question.  This is just another C (in-)compatability wart in my
> opinion... and an almost totally pointless one.

This kind of behavior seems to be almost universal among people interested
in the C++ language: one moment they're saying that the language has enough
stuff in it already and the next moment they're proposing a new feature.

I don't mean to single out Ron here -- he just happened to provide a
convenient example.  As far as I can tell, almost EVERYONE does this.
For example, when Bjarne sent in his paper to the "History of Programming
Languages" conference, he told me that essentially every reviewer told him
that his paper was too long and then gave him a list of things to add.

I don't think this behavior is limited to C++, or even to programming languages.
Just look at how much advertising tries to get people to buy products based
on how many features they have.
--
    --Andrew Koenig
      ark@research.att.com

In article <25807@alice.att.com> ark@alice.UUCP () writes:
>In article <rfgC9086A.8xv@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>
>>> Section 3.3 of the working document makes explicit mention of the fact
>>> that it is not possible to declare a class name static.  What is the
>>> rationale behind this restriction?
>
>> Good question.  This is just another C (in-)compatability wart in my
>> opinion... and an almost totally pointless one.
>
>This kind of behavior seems to be almost universal among people interested
>in the C++ language: one moment they're saying that the language has enough
>stuff in it already and the next moment they're proposing a new feature.
>
>I don't mean to single out Ron here -- he just happened to provide a
>convenient example.  As far as I can tell, almost EVERYONE does this.

 Actually, picking Ron is probably particularly unfair,
since he's been a consistent advocate of removing features:
of course, removing features is defined by the committee as
requiring an extension proposal :-)

 For example, I'd like to have nested functions.

 Just cant understand why removing a restriction against
 them has to be considered an extension--- I want to
 simplify the language not add a feature ;-)


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <1993Jun22.162345.18549@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:

> of course, removing features is defined by the committee as
> requiring an extension proposal :-)

>  For example, I'd like to have nested functions.

>  Just cant understand why removing a restriction against
>  them has to be considered an extension--- I want to
>  simplify the language not add a feature ;-)

I rest my case.
--
    --Andrew Koenig
      ark@research.att.com

In article <25807@alice.att.com> ark@alice.UUCP () writes:
>In article <rfgC9086A.8xv@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>
>> Now don't get me wrong.  I like a good Rolls-Royce as much as the next guy,
>> but given my immediate needs, I'll take the Volkswagon today, rather than
>> the Rolls-Royce in (maybe) five years.
>
>and in  <rfgC908xI.AMv@netcom.com> he writes:
>
>> In article <C8qDu4.6Jw@sugar.NeoSoft.COM> daniels@NeoSoft.com (Brad Daniels) writes:
>>> Section 3.3 of the working document makes explicit mention of the fact
>>> that it is not possible to declare a class name static.  What is the
>>> rationale behind this restriction?
>
>> Good question.  This is just another C (in-)compatability wart in my
>> opinion... and an almost totally pointless one.
>
>This kind of behavior seems to be almost universal among people interested
>in the C++ language: one moment they're saying that the language has enough
>stuff in it already and the next moment they're proposing a new feature.
>
>I don't mean to single out Ron here -- he just happened to provide a
>convenient example...

OK.  I don't mean to single out Andrew Koenig here, but this kind of
behavior seems to be almost universal among people interested in C++.

Lots of people seem to work real hard to put on blinders when it comes to
discussing C++ and they seem to go out of their way to view everything
strictly in a C++ context, without either an adequate understanding of,
nor an adequate respect for the rules embodied in the ANSI C standard.
Thus, it is often the case that such people have a hard time really
grasping even simple concepts which are apparent to anyone who is on
intimate terms with the ANSI C standard.

So it is in this case.  Andrew seems to have exercized some "selective
reading" on my prior posting.  He fixated on my suggestion that things
like:

 static struct S { int member; };
 static enum color { red, green, blue };

should be allowed, and he seems to have failed entirely to notice that I
also mentioned the fact that in ANSI C, the names of types simply DO NOT
HAVE EXTERNAL LINKAGE.  Thus, in C, the above declarations are precisely
and exactly equivalent to:

 struct S { int member; };
 enum color { red, green, blue };

In other words, the `static' specifiers in the previous set of declarations
are entirely superfluous in C, and they are (in effect) simply ignored by
any conformant ANSI C compiler.

What I suggested was that this should be the case in C++ also, for the sake
of compatability with ANSI C.  Now perhaps this constitutes a "new feature",
but it does not exactly provide any new functionality to the programmer.

Let me be quite clear about this.  I *DID NOT* suggest adding any new
functionality to the C++ language.  I seems that Andrew and others may
have totally misunderstood what I said however, and may have come to the
incorrect conclusion that I was agreeing with those (confused?) folks
who have here suggested that type names may have external linkage, and
that some method of controlling the linkage of such names ought to be
provided in C++.

But nothing could be further from the truth.  It is my contention that
(in ANSI C at least) there simply is no such thing as a type name which
has external linkage.  I believe that this is also true for C++.  (If
not, it should be.)  Thus, as I tried to point out earlier, it is simply
nonsensical to even talk about adding a feature to the language which
would enable the program to DISABLE external linkage for some selected
type names, because those type names never even had external linkage to
begin with!  (Repeat after me... linkers make links for variables and
functions... NOT FOR TYPE NAMES.)

In short, I disagree completely with those people who believe that types
names can have (or do have) external linkage, and that the keyword `static'
might be used as a way to disable this external linkage.  I believe that
these people are just confused, and that they ought to get copies of the
ANSI C standard, and spend some more time trying to understand what the
term "external linkage" (which is well defined therein) really means.

Separately however, I attempted to note that in ANSI C, a declaration such
as:

 static enum color { red, green, blue };

... is allowed, and that the `static' keyword in such a declaration is
simply treated as superfluous noise, and is ignored by the compiler.

Sadly, the current definition of the C++ language does not seem to be
compatible with ANSI C in this respect.  In C++, you are not allowed to
put such a superfluous `static' specifier in a declaration of this kind.

I would like to see C++ follow C in this regard.  Specifically, I would
like to see the keyword be allowed but ignored.

It is a pity that this simple message was so completely misconstrued, but
it does illustrate (I think) the level to which ignorance of the ANSI C
standard abounds in the C++ community (and also in the C++ standardization
committee).

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <rfgC91JEK.182@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>
> static struct S { int member; };
> static enum color { red, green, blue };
>
>should be allowed, and he seems to have failed entirely to notice that I
>also mentioned the fact that in ANSI C, the names of types simply DO NOT
>HAVE EXTERNAL LINKAGE.  Thus, in C, the above declarations are precisely
>and exactly equivalent to:
>
> struct S { int member; };
> enum color { red, green, blue };
>
>In other words, the `static' specifiers in the previous set of declarations
>are entirely superfluous in C, and they are (in effect) simply ignored by
>any conformant ANSI C compiler.
>

 On the other hand, in

 static struct S { int member; } s;

the 'static' is not superfluous. It says that 's' is static. So it's a bit
broad to say that the the 'static' specifiers are entirely superfluous. They
have no effect because there is no object for them to apply to.
 The key here is that type names do not have linkage. Because of this,
"static" and "extern" simply do not apply to types. They do, however, apply
to objects, and because we can include type definitions inside of object
definitons, this quickly becomes somewhat confusing.
 -- Pete

In article <rfgC91JEK.182@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>In article <25807@alice.att.com> ark@alice.UUCP () writes:
...
>>> In article <C8qDu4.6Jw@sugar.NeoSoft.COM> daniels@NeoSoft.com (Brad Daniels) writes:
>>>> Section 3.3 of the working document makes explicit mention of the fact
>>>> that it is not possible to declare a class name static.  What is the
>>>> rationale behind this restriction?
...
>So it is in this case.  Andrew seems to have exercized some "selective
>reading" on my prior posting.  He fixated on my suggestion that things
>like:
>
> static struct S { int member; };
> static enum color { red, green, blue };
>
>should be allowed, and he seems to have failed entirely to notice that I
>also mentioned the fact that in ANSI C, the names of types simply DO NOT
>HAVE EXTERNAL LINKAGE.  Thus, in C, the above declarations are precisely
>and exactly equivalent to:
>
> struct S { int member; };
> enum color { red, green, blue };
>
>In other words, the `static' specifiers in the previous set of declarations
>are entirely superfluous in C, and they are (in effect) simply ignored by
>any conformant ANSI C compiler.

Good point...  It confuses matters in this context, but nonetheless,
there is no reason it shouldn't work the same way in C++.

>But nothing could be further from the truth.  It is my contention that
>(in ANSI C at least) there simply is no such thing as a type name which
>has external linkage.  I believe that this is also true for C++.  (If
>not, it should be.)  Thus, as I tried to point out earlier, it is simply
>nonsensical to even talk about adding a feature to the language which
>would enable the program to DISABLE external linkage for some selected
>type names, because those type names never even had external linkage to
>begin with!  (Repeat after me... linkers make links for variables and
>functions... NOT FOR TYPE NAMES.)
>
>In short, I disagree completely with those people who believe that types
>names can have (or do have) external linkage, and that the keyword `static'
>might be used as a way to disable this external linkage.  I believe that
>these people are just confused, and that they ought to get copies of the
>ANSI C standard, and spend some more time trying to understand what the
>term "external linkage" (which is well defined therein) really means.


Since I'm the one whose message started all this, I'd like to clarify
what I meant.  I never said anything about class *names* having external
linkages, it's the identifiers for the member functions and static data
members associated with the class which have external linkage, and which
should be allowed to have internal linkage through the use of the static
keyword at the class declaration level, resulting in a "static" class
whose *members* all have internal or no linkage.  I referred to this as
a class with internal linkage because I thought it was obvious what that
meant, since nothing else makes sense.

Also, I did not propose changing the semantics of static declarations.
I *did* in fact propose a syntactic extension which I feel regularizes
the language with regard to scoping rules.  To put it in context of the
working grammar,  I would modify the specifications for elaborated-type-
specifier and nested-class-specifier as follows:

 qualified-class-name:
  class-name
  "static" class-name

 elaborated-type-specifier:
  class-key qualified-class-name
  class-key qualified-class-specifier :: qualified-class-name
  "enum" identifier
  "enum" qualified-class-specifier :: identifier

        nested-class-specifier:
  qualified-class-name
  qualified-class-name :: nested-class-specifier

(the definition for qualified-class-specifier would remain the same:
 qualified-class-specifier:
  nested-class-specifier
  :: nested-class-specifier)

This would mean that the keyword "static" could follow "class", "struct",
or "enum" to indicate that all of its associated member functions and
static data members should have internal linkage or no linkage.

- Brad
--
Brad Daniels  ` |  "If money can't buy happiness,
daniels@neosoft.com  |   I guess I'll have to rent it."
I don't work for NeoSoft, and |  - Weird Al Yenkovic
don't speak for my employer. |

In article <rfgC91JEK.182@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>
>So it is in this case.  Andrew seems to have exercized some "selective
>reading" on my prior posting.  He fixated on my suggestion that things
>like:
>
> static struct S { int member; };
> static enum color { red, green, blue };
>
>should be allowed, and he seems to have failed entirely to notice that I
>also mentioned the fact that in ANSI C, the names of types simply DO NOT
>HAVE EXTERNAL LINKAGE.

>What I suggested was that this should be the case in C++ also, for the sake
>of compatability with ANSI C.  Now perhaps this constitutes a "new feature",
>but it does not exactly provide any new functionality to the programmer.
>
>Let me be quite clear about this.  I *DID NOT* suggest adding any new
>functionality to the C++ language.

>But nothing could be further from the truth.  It is my contention that
>(in ANSI C at least) there simply is no such thing as a type name which
>has external linkage.  I believe that this is also true for C++.  (If
>not, it should be.)

 J Stephen Adamczyk points out that C has names with
'no linkage' such as

 g() {
  float f; // no linkage
 }

while C++ does not, and suggests the committee adopt the notion
of 'no linkage' in X3J16/93-0075==WG21/N0282. In fact, he suggests
adopting the C definition of linkage with three categories.

Briefly, global class names would continue to have external
linkage, while local variables and enumeration constants
would have 'no linkage'.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <1993Jun22.214246.27155@borland.com> pete@borland.com (Pete Becker) writes:
> The key here is that type names do not have linkage.

 Sure they do. C++ class names have extern linkage.
 In C++ *all* file-scope names have linkage.
 See 3.3.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <rfgC91JEK.182@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:

> "selective reading" on my prior posting.
> He fixated on my suggestion that things like:

 static struct S { int member; };
 static enum color { red, green, blue };

> should be allowed, and he seems to have failed entirely to notice that I
> also mentioned the fact that in ANSI C, the names of types simply DO NOT
> HAVE EXTERNAL LINKAGE.  Thus, in C, the above declarations are precisely
> and exactly equivalent to:

>  struct S { int member; };
>  enum color { red, green, blue };

True.

> In other words, the `static' specifiers in the previous set of declarations
> are entirely superfluous in C, and they are (in effect) simply ignored by
> any conformant ANSI C compiler.

Not quite true.  It is true for these particular declarations, but in

 static struct S { int member; } x, y;

the `static' modifies x and y.  That is, the declaration above is equivalent to

 struct S { int member; };
 static struct S x, y;

Because this particular bit of syntax is already taken, there is not
a convenient syntax for the logical C++ extension of giving types
internal linkage.  One might consider

 struct static S { int member; };

but on balance I think that's too confusing.

> What I suggested was that this should be the case in C++ also, for the sake
> of compatability with ANSI C.  Now perhaps this constitutes a "new feature",
> but it does not exactly provide any new functionality to the programmer.

Of course it does.  The linkage of class names is one of the areas in
which C++ is deliberately different from C.  This difference is closely
tied up with the difference between structural equivalence and name equivalence.
Thus a C programmer can define two structures named X in two different
translation units and, if those two definitions happen to be enough alike,
can pretend they are the same.  C++ is more rigorous about type checking than
that, so it might sometimes be an advantage to do things the C way.  From
the C++ viewpoint, that's an extension.

> Let me be quite clear about this.  I *DID NOT* suggest adding any new
> functionality to the C++ language.  I seems that Andrew and others may
> have totally misunderstood what I said however, and may have come to the
> incorrect conclusion that I was agreeing with those (confused?) folks
> who have here suggested that type names may have external linkage, and
> that some method of controlling the linkage of such names ought to be
> provided in C++.

In C++, type definitions are conceptually external things.  For any
given type, there must be one single definition in the entire program
and the implementation is permitted to verify that that is so.
It is true that this notion does not fit well with C-style linkers,
but that is just an implementation issue.

...

> Sadly, the current definition of the C++ language does not seem to be
> compatible with ANSI C in this respect.  In C++, you are not allowed to
> put such a superfluous `static' specifier in a declaration of this kind.

> I would like to see C++ follow C in this regard.  Specifically, I would
> like to see the keyword be allowed but ignored.

C++ should probably allow

 static struct X { int a; } x, y;

with the same meaning as in C (that is, the keyword is not ignored).
However, in C++ such a definition should clash with a conflicting
definition of struct X in a different translation unit.

That is the price for type-safe linkage, which experience has shown to
be well worthwhile.

> It is a pity that this simple message was so completely misconstrued, but
> it does illustrate (I think) the level to which ignorance of the ANSI C
> standard abounds in the C++ community (and also in the C++ standardization
> committee).

Tom Plum, Bill Plauger, and Sam Harbison are on the C++ committee.
If you think they're ignorant of C, whom do you think isn't?
--
    --Andrew Koenig
      ark@research.att.com

In article <1993Jun23.103931.24251@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>In article <1993Jun22.214246.27155@borland.com> pete@borland.com (Pete Becker) writes:
>> The key here is that type names do not have linkage.
>
> Sure they do. C++ class names have extern linkage.
> In C++ *all* file-scope names have linkage.
> See 3.3.
>

 You're absolutely right. This is a change from C.
 -- Pete

There has been a lot of messages arguing for or against extensions
in general and for or against particular proposed extensions.
The extreme positions can be summarized as:

 This extension is essential now!
and
 No extensions!

I will post two long messages on extensions. The first ``How to Propose
and extension'' states the position of the extensions working group of
the ANSI/ISO C++ standards group (this is a re-post from last year).
The other ``Why consider language extensions?'' explains some of my views.

Summary:

 A sceptical, conservative, and thorough approach to extensions
 provides a greater degree of stability and utility than either
 of the extreme positions.

Naturally, this position will not please people with more extreme views.

 - Bjarne Stroustrup (extensions WG chair)

     H H H Ho o o ow w w w t t t to o o o w w w wr r r ri i i it t t te e e e a a a a C C C C+ + + ++ + + + l l l la a a an n n ng g g gu u u ua a a ag g g ge e e e e e e ex x x xt t t te e e en n n ns s s si i i io o o on n n n p p p pr r r ro o o op p p po o o os s s sa a a al l l l f f f fo o o or r r r
                    A A A AN N N NS S S SI I I I- - - -X X X X3 3 3 3J J J J1 1 1 16 6 6 6/ / / /I I I IS S S SO O O O- - - -W W W WG G G G2 2 2 21 1 1 1


      members of the X3J16 working group on extensions






_ 1   _ I_ n_ t_ r_ o_ d_ u_ c_ t_ i_ o_ n
  First, let us try to dissuade you from proposing an exten-
sion to the C++ language.  C++ is already too large and com-
plicated for our taste and there are millions  of  lines  of
C++  code  ``out there'' that we endeavor not to break.  All
changes to the language must undergo  tremendous  considera-
tion.   Additions  to  it are undertaken with great trepida-
tion.  Whereever possible we prefer to see programming tech-
niques  and  library  functions used as alternatives to lan-
guage extensions.
  Many communities of programmers want to see their favorite
language  construct  or  library  class propagated into C++.
Unfortunately, adding useful features from diverse  communi-
ties  could turn C++ into a set of incoherent features.  C++
is not perfect, but adding features  could  easily  make  it
worse instead of better.
  The aim of ANSI-X3J16/ISO-WG21 is standardization of  C++,
not the design of C++++.  The ANSI/ISO committees are trying
hard to avoid inventing a new language.  Few  if any commit-
tee  members   believe  in  ``design  by  committee.''   The
committee's purpose is to ``Standardize existing practice.''
This  means that any proposed extension, with only very rare
exception, should be  implemented  somewhere.   However,  as
noted  below,  that  a  feature  is  implemented  and useful
doesn't in itself imply that it is  suitable  for  inclusion
into C++.
  Let us consider what is involved in making a  proposal  to
the  committee.  A modest proposal is going to cost the 100+
active members of the ANSI committee at least  a  couple  of
hours  each to review and debate with other members and col-
leagues.  It could easily cost the equivalent six full work-
ing  weeks  of  a senior technical person's time to consider
and reject a modest proposal.  A complex proposal,  such  as
exception  handling or run-time type identification costs at
least ten or even a hundred times that.  A  successful  pro-
posal  implies  more work.  The cost to the C++ community of
implementing, documenting, and learning to use your proposal
is  proportionally  higher.   If the ANSI/ISO committees and
possibly the C++ community are going to make such a substan-
tial  investment  in  considering  your proposal, you should

                        May 3, 1992






                           - 2 -


have a proposal worth considering.  Thus,  if  you  want  to
make  an  extension  to  C++, you must be prepared to make a
``substantial investment'' of your own time  and  effort  to
present the case to the committee.  Please remember that the
committee members are volunteers and that your proposal com-
petes  for  time  with  other proposals and with the profes-
sional and private lives of the committee members.
  We do understand that missing features  also  carry  costs
that  is why we consider extensions at all.  However, please
do realize that the time and energy of every committee  mem-
ber  is limited and that every proposal for an extension not
only carries a cost but also diverts time  and  energy  from
the  committees primary activity of creating an unambiguous,
comprehensible, and complete description of the language and
the library.

_ 2   _ Q_ u_ e_ s_ t_ i_ o_ n_ s
  Here is a list of questions that might help you to  refine
your  suggestion  and  possibly present it to the committee.
The list presents criteria that have been used  to  evaluate
features for C++.
  [1]Is it precise? (Can we understand what you are suggest-
    ing?)   Make  a clear precise statement of the change as
    it effects the current draft of the  language  reference
    standard.
    [a]What changes to the grammar are needed?
    [b]What changes  to  the  description  of  the  language
      semantics are needed?
    [c]Does it fit with the rest of the language?
  [2]What is the rationale for the extension? (Why do    _ y_ o_ u
    want it, and why would  _ w_ e also want it?)
    [a]Why is the extension needed?
    [b]Who is the audience for the change?
    [c]Is this a general purpose change?
    [d]Does it affect one group of C++ language  users  more
      than others?
    [e]Is it implementable on all  reasonable  hardware  and
      systems?
    [f]Is it useful on on all reasonable hardware  and  sys-
      tems?
    [g]What kind of programming and design  styles  does  it
      support?
    [h]What kind of programming and design  styles  does  it
      prevent?
    [i]What other languages (if any) provide such features?
    [j]Does it ease the design, implementation,  or  use  of
      libraries?
  [3]Has it been implemented? (If so,  has  it  been  imple-
    mented in the exact form that you are suggesting; and if
    not, why can you assume that experience from ``similar''
    implementations  or  other  languages will carry over to
    the feature as proposed?)
    [a]What affect does it have on a C++ implementation?
      [x]compiler organization

                        May 3, 1992






                           - 3 -


      [y]run-time support
    [b]Was the implementation complete?
    [c]Was  the  implementation  used  by  others  than  the
      implementor(s)?
  [4]What difference does the feature have on code?
    [a]What does the code look like without the change?
    [b]What is the affect of not doing the change?
    [c]Does use of the new feature lead to demands  for  new
      support tools?
  [5]What impact does the change have on efficiency and com-
    patibility with C and existing C++?
    [a]How does the change affect run-time efficiency?
      [x]of code that use the new feature
      [y]of code that does not use the new feature
    [b]How does the change affect compile and link times?
    [c]Does the change affect existing programs
      [x]Must C++ code that does not use the feature be  re-
        compiled?
      [y]Does the change affect linkage to languages such as
        C and Fortran?
    [d]Does the  change  affect  the  degree  of  static  or
      dynamic checking possible for C++ programs?
  [6]How easy is the change to document and teach
    [a]to novices?
    [b]to experts?
  [7]What reasons could there be for NOT making  the  exten-
    sion?   There  will be counter arguments and part of our
    job is to find and evaluate them so you can just as well
    save time by presenting a discussion.
    [a]Does it affect old code that does not  use  the  con-
      struct?
    [b]Is it hard to learn?
    [c]Does it lead to demands for further extensions?
    [d]Does it lead to larger compilers?
    [e]Does it require extensive run-time support?
  [8]Are there
    [a]alternative ways of providing a feature to serve  the
      need?
    [b]alternative ways of using the syntax suggested?
    [c]attractive generalizations of the suggested scheme
  Naturally, this list is not exhaustive. Please  expand  it
to cover points relevant to your specific proposal and leave
out points that are irrelevant.

_ 3   _ R_ e_ m_ e_ m_ b_ e_ r _ t_ h_ e _ V_ a_ s_ a!
  Then, if the proposal is accepted for detailed  considera-
tion in the committee, you should be prepared to attend sev-
eral ANSI/ISO committee sessions or sessions of  a  national
C++  standards  committee.   There   as  a  member  or as an
observer  you could present your proposal and take  part  in
the  debate  about  it  and other proposals.  If that is not
possible try to find someone on the committee who is willing
to make the case on your behalf.
  Please understand that most  extensions  to  the  language

                        May 3, 1992






                           - 4 -


cannot be accepted. Do not take it personally.  Frequently a
problem that is solved with a  language  extension  is  also
solved  by  suitable use of existing C++ features.  Alterna-
tively, a smaller extension to  an  existing  feature  or  a
library  class  might  do  the job acceptably.  This was the
case with a recent extension proposal for  generalize  over-
riding  (see  Ellis and Stroustrup: The Annotated C++ Refer-
ence Manual j f10.11, pg236) that Bjarne Stroustrup made.   If
the  designer of C++ is willing to learn and withdraw a pro-
posal, so should you.
  Please also understand that there are dozens of reasonable
extensions  and  changes  being proposed. If every extension
that is reasonably  well-defined,  clean  and  general,  and
would  make life easier for a couple of hundred or couple of
thousand C++ programmers were accepted, the  language  would
more  than  double in size. We do not think this would be an
advantage to the C++ community.
  We often remind ourselves of the good ship Vasa.   It  was
to  be the pride of the Swedish navy and was built to be the
biggest and most beautiful battleship ever.   Unfortunately,
to  accommodate  enough  statues and guns it underwent major
redesigns and extension during construction.  The result was
that it only made it half way across Stockholm harbor before
a gust of wind blew it over and it  sank  killing  about  50
people.   It  has  been  raised  and you can now see it in a
museum in Stockholm.  It is a beauty  to  behold   far  more
beautiful  at  the time than its unextended first design and
far more beautiful today than if it had suffered  the  usual
fate  of a 17th century battle ship  but that is no consola-
tion to its designer, builders, and intended users.

_ 4   _ S_ a_ m_ p_ l_ e _ P_ r_ o_ p_ o_ s_ a_ l
  So you still want to make an extension?  Here is an  exam-
ple  of  a proposal that almost made it.  It was proposed by
the ISO representative from Sweden and strongly supported by
the representative from Apple.  There was implementation and
usage experience from both a  C++  implementation  and  from
another  language.   In  general, we liked it.  The ``snag''
that caused the proposers to withdraw the proposal  is  pre-
sented at the end.


                       New keyword for C++: inherited



                             Dag M. Br" uck

                     Department of Automatic Control
                       Lund Institute of Technology
                     Box 118, S-221 00 Lund, Sweden
                        E-mail: dag@control.lth.se

1.    Description

                        May 3, 1992






                           - 5 -


The keyword inherited is a qualified-class-name that  repre-
sents an anonymous base class (RM, Section 5.1).

                           inherited :: name

denotes  the  inherited  member  name.    The   meaning   of
inherited::name is that of name, pretending that name is not
defined in the derived class (RM, Section 10).

    struct A { virtual void handle(); };
    struct D : A { void handle(); };


    void D :: handle()
    {
         A::handle();
         inherited::handle();
    }

In this example A::handle and inherited::handle  denote  the
same name.
    When a class is  derived  from  multiple  base  classes,
access  to  inherited::name  may  be  ambiguous,  and can be
resolved by qualifying with the class name instead (RM, Sec-
tion 10.1.1).
    The dominance rule does not apply  to  qualified  names,
and   consequently   not  to  inherited::name  (RM,  Section
10.1.1).



2.    Motivation


Many class hierarchies are built  "incrementally,"  by  aug-
menting the behaviour of the base class with added function-
ality of the derived class. Typically, the function  of  the
derived class calls the function of the base class, and then
performs some additional operations:

    struct A { virtual void handle(int); };
    struct D : A { void handle(int); };


    void D :: handle(int i)
    {
         A::handle(i);
         // other stuff
    }

The call to handle() must be qualified to avoid a  recursive
loop. The example could with the proposed extension be writ-
ten as follows:



                        May 3, 1992






                           - 6 -


    void D :: handle(int i)
    {
         inherited::handle(i);
         // other stuff
    }

Qualifying by the keyword inherited can  be  regarded  as  a
generalization  of  qualifying  by  the name of a class.  It
solves a number of potential problems  of  qualifying  by  a
class  name, which is particularly important for maintaining
class libraries.


2.1   Unambiguous inheritance

There is no way to tell whether A::handle() denotes the mem-
ber of a base class or the member of some other class, with-
out knowing the inheritance tree for class  D.  The  use  of
inherited::handle()   makes   the  inheritance  relationship
explicit, and causes an error message  if  handle()  is  not
defined in a base class.


2.2   Changing name of base class

If the name of the base class A is changed, all  occurrences
of A::handle() must be changed too; inherited::handle() need
not be changed. Note that  the  compiler  can  probably  not
detect  any  forgotten A::name if name is a data member or a
static member function.


2.3   Changing base class

Changing the inheritance tree so class D is derived  from  B
instead  of  A  requires  the same changes of A::handle() as
changing the name of the base class.


2.4   Inserting intermediate class

Assume that we start out with class D  derived  from  A.  We
then insert a new class B in the inheritance chain between A
and D:

    struct A { virtual void handle(int); };
    struct B : A { void handle(int); };
    struct D : B { void handle(int); };

Calling A::handle() from D::handle()  would  still  be  per-
fectly legal C++  after this change, but probably wrong any-
way. On the other hand, inherited::handle() would now denote
B::handle(),  which I believe reflects the intentions of the
programmer in most cases.


                        May 3, 1992






                           - 7 -


2.5   Multiple inheritance

Most class hierarchies are developed with single inheritance
in  mind.   If  we change the inheritance tree so class D is
derived from both A and B, we get:

    struct A { virtual void handle(int); };
    struct B { virtual void handle(int); };
    struct D : A, B { void handle(int); };


    void D :: handle(int i)
    {
         A::handle(i);               // unambiguous
         inherited::handle(i);      // ambiguous
    }

In this case A::handle() is legal C++   and possibly  wrong,
just  as  in the previous example. Using inherited::handle()
is ambiguous here, and causes an error  message  at  compile
time. I think this behaviour is desirable, because it forces
the person merging two  class  hierarchies  to  resolve  the
ambiguity. On the other hand, this example shows that inher-
ited may be of more limited use with multiple inheritance.



3.    Consequences


Programs currently using the identifier  inherited  must  be
edited before recompilation. Existing C++  code is otherwise
still legal after the introduction of the keyword inherited.
Existing libraries need not be recompiled.
    I believe inherited has a small impact on the complexity
of  the  language and on the difficulty of implementing com-
pilers.
    Although this is  another  feature  to  teach,  I  think
inherited makes teaching and learning C++   easier.  This is
not an entirely new concept, just a generalization of quali-
fying names by the name of a class.



4.    Experience


This is not a new idea, and similar mechanisms are available
in  other object- oriented languages, notably Object Pascal.
The C++   compiler from Apple  has  inherited  as  described
above,  although its use has been restricted to solving com-
patibility problems with Object Pascal.




                        May 3, 1992






                           - 8 -


5.    Summary


This paper proposes the extension of C++   with the  keyword
inherited,  a  qualified-class-name used to denote an inher-
ited class member.  The advantages are a clearer inheritance
relationship  and  increased programming safety.  The imple-
mentation cost is small, and the consequences  for  existing
code minor.

_ 5   _ C_ o_ m_ m_ e_ n_ t_ s _ o_ n _ t_ h_ e _ i_ n_ h_ e_ r_ i_ t_ e_ d:: Proposal
  Dag Br" uck is a member of the X3J16 working group for eval-
uating  proposed extensions; he volunteered his proposal for
this use.  The proposal is well-argued and  as is  the  case
with most proposals  there was more expertise and experience
available in the committee itself.  In this case  the  Apple
representative  had  implemented  the  proposal.  During the
discussion we soon agreed that  the  proposal  was  free  of
major  flaws.  In particular, in contrast to earlier sugges-
tions along this line (some  as  early  as  the  discussions
about  multiple inheritance in 1986) it correctly dealt with
the ambiguities that can arise when multiple inheritance  is
used.   We  also  agreed  that  the  proposal was trivial to
implement and would in fact be helpful to programmers.
  Note that this is  _ n_ o_ t sufficient for acceptance.  We know
of  dozens  of  minor  improvements like this and at least a
dozen major ones.  If we accepted  all  the  language  would
sink  under  its  own  weight (remember the Vasa!).  We will
never know if  this  proposal  would  have  passed,  though,
because  at  this  point  in the discussion, Michael Tiemann
walked in and muttered something like ``but  we  don't  need
that extension; we can write code like that already.''  When
the murmur of ``but of course  we  can't!''  had  died  down
Michael showed us how:
     class foreman : public employee {
         typedef employee inherited;
         // ...
         void print();
     };
     class manager : public foreman {
         typedef foreman inherited;
         // ...
         void print();
     };
     void manager::print()
     {
         inherited::print();
         // ...
     }
A further discussion of this example can be  found  on  page
205  of  B.Stroustrup:  _ T_ h_ e  _ C++  _ P_ r_ o_ g_ r_ a_ m_ m_ i_ n_ g  _ L_ a_ n_ g_ u_ a_ g_ e (_ 2_ n_ d

                        May 3, 1992






                           - 9 -


_ E_ d_ i_ t_ i_ o_ n); Addison-Wesley 1991.  What we hadn't  noticed  was
that  the  re-introduction  of  nested  classes into C++ had
opened the possibility of controlling the scope and  resolu-
tion of type names exactly like other names.
  Given this technique we decided that our efforts was  bet-
ter  spent  on  some  other standards work.  The benefits of
inherited:: as a built-in facility didn't sufficiently  out-
weigh  the  benefits  of  what  the programmer could do with
existing features.  In consequence, we decided not  to  make
inherited::  one  of the very few extensions we could afford
to accept for C++.

_ 6   _ A_ d_ d_ r_ e_ s_ s_ e_ s
  If you still want to propose an extension please send mail
(electronic mail is preferred) to one of these X3J16 members
that will make sure that your proposal comes to  the  atten-
tion of the committee.  Please make it clear if you are mak-
ing an official proposal.  We all get lots of casual sugges-
tions and inquiries.
  Dmitry Lenkov, HP, dmitry@hpcldnl.hp.com (X3J16 chairman).
  19447 Pruneridge Ave, MS 47LE. Cupertino CA95014. USA.
  Stephen D. Clamage,  TauMetric,  steve@taumet.com  (acting
  X3J16  vice  chairman).   8765 Fletcher Pkwy, Ste. 301. La
  Mesa CA91942, USA.
  Bjarne Stroustrup,  AT&T  Bell  Labs,  bs@research.att.com
  (chairman  of  the  X3J16  working group for extenstions).
  Murray Hill, NJ07974. USA.
  Dag Michael Br" uck, Sweden, dag@Control.LTH.Se
  Philippe Gautron, France, gautron@rxf.ibp.fr
  Bill Gibbons, Apple, bgibbons@apple.com
  Ted Goldstein, Sun, tedg@sun.com
  Aron Insinga, DEC, insinga@tle.enet.dec.com
  Konrad Kiefer, Siemens, kk@ztivax.siemens.com
  Kim Knuttila, IBM, knuttila@torolab6.iinus1.ibm.com
  Martin O'Riordan, Microsoft, martino@microsoft.com
You might also consider becomming a member of X3J16  or  one
of  the other national standards committees.  We can use all
the constructive help we can get.
  Here is how you become a member of X3J16: Have your  orga-
nization send a letter to
             Dan Arnold
             X3 Secretariat, CBEMA
             311 First St NW, Suite 500
             Washington  DC  20001-2178
saying that they want  to  join  the  X3J16  C++  Committee.
Include  a  brief  statement  of  why  -- the organization's
interest  in  C++,  standardization  efforts,  or  whatever.
Specify  who  the representative(s) will be, and the desired
class(es) of membership: Principal, Alternate, or Observer.
  Send a copy of the letter to




                        May 3, 1992






                           - 10 -


             Steve Clamage
             TauMetric Corporation
             8765 Fletcher Pkwy, Ste 301
             La Mesa, CA  91942
Include the address,  phone,  fax,  and  email  address  (as
applicable) of each person named.
  The organization may become and remain a voting member  by
sending  a  Principal  or  Alternate  member to two of every
three meetings.  There are three meetings per year, at least
2  of which are in the continental US or Canada.  The annual
fee is currently $250, which  allows  the  organization  one
Principal member and one Alternate.  X3 will send an invoice
for the fee.  Do not send money with the letter.
  The organization may have only one Principal  member,  and
as  many Alternate members as it wants, with additional fees
for additional members, but only one vote may  be  cast  per
organization.   The  organization  may have Observer members
(in addition to or instead of regular members), who need not
attend meetings (but who may do so), and who may not vote at
meetings.  The fee is the same for Observers.
  Each member organization gets one copy of  all  the  X3J16
documents  as  they  are issued (before and after each meet-
ing), mailed to the Principal  member  (or  to  one  of  the
Observer  members  if  there  is no Principal member).  Each
person on the membership list is added to the email  reflec-
tor  for  the  committee.  There are also reflectors for the
various working groups on particular topics, which any  mem-
ber may join.



























                        May 3, 1992

             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

In article <25697@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes:
>
>There has been a lot of messages arguing for or against extensions
>in general and for or against particular proposed extensions.
>The extreme positions can be summarized as:
>
> This extension is essential now!
>and
> No extensions!

I find it a particularly telling comment that (in the context of an ANSI/ISO
standardization effort) a strong committment to the plain and simple
standardization of existing practice is considered to be a view held only
by radical extremists.

What can I say?  It's a funny world we live in.

  Love is hate.
  War is peace.
  Freedom is slavery.
  Standardization is Research & Development.

--

// Ron ("Loose Cannon") Guilmette    uucp: ...uunet!lupine!segfault!rfg
//
//      "On the one hand I knew that programs could have a compelling
//       and deep logical beauty, on the other hand I was forced to
//       admit that most programs are presented in a way fit for
//       mechanical execution, but even if of any beauty at all,
//       totally unfit for human appreciation."
//                                              -- Edsger W. Dijkstra

In article <rfgC8KuAB.FKu@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>In article <25697@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes:
>>
>>There has been a lot of messages arguing for or against extensions
>>in general and for or against particular proposed extensions.
>>The extreme positions can be summarized as:
>>
>> This extension is essential now!
>>and
>> No extensions!
>
>I find it a particularly telling comment that (in the context of an ANSI/ISO
>standardization effort) a strong committment to the plain and simple
>standardization of existing practice is considered to be a view held only
>by radical extremists.

It *would* be telling, if it were a comment given by nearly any other
standardization process. The problem with saying that about C++ is, at
the time the standardization process started, there was virtually no
existing practice to build on! The design of the language was not, and
still is not, finished. The problem isn't that the standards team
isn't holding to the normal practice of standardizing current usage;
it's that the standards team was organized before the language was.

The C++ language, as it existed when the standards team was formed,
was simply not adequate for the purposes for which is was intended. It
needed things like templates (now, I don't like how they were
implemented, but it's certainly true that soemthing like them was
needed!), exception handling, etc. For the standards team, at that
point in the design of the language to say "Freeze the language here"
would have been disastrous - C++ needed some extensions.

 <MC>
--
|| Mark Craig Carroll: <MC>     || "Only love
|| CIS Grad, Univ of Delaware   ||     can make love"
|| PGP key available by finger  ||  -Peter Gabriel
|| carroll@udel.edu             ||

In article <1993Jun14.150349.778@udel.edu>, carroll@hercules.cis.udel.edu (Mark C. Carroll) writes:
> In article <rfgC8KuAB.FKu@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
> >I find it a particularly telling comment that (in the context of an ANSI/ISO
> >standardization effort) a strong committment to the plain and simple
> >standardization of existing practice is considered to be a view held only
> >by radical extremists.
>
> It *would* be telling, if it were a comment given by nearly any other
> standardization process. The problem with saying that about C++ is, at
> the time the standardization process started, there was virtually no
> existing practice to build on! The design of the language was not, and
> still is not, finished.  ...

These extensions are not extensions in the usual sense of the word.  They
are the completion of one or another major part of the language.
--
 (This man's opinions are his own.)
 From mole-end    Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ