In article <pkt-110194130108@138.52.2.129> pkt@lpi.liant.com (Scott Turner) writes:

> The C++ committee is also enhancing its language in major ways, notably
> templates and exceptions.  But the committee is near unanimous that
> those features should be in the standard, and many vendors are already
> supporting templates and exceptions in the form proposed.

... and templates and exceptions were explicitly mentioned as being within
the committee's charter in the letter that originally requested formation
of the committee.
--
    --Andrew Koenig
      ark@research.att.com

rfg@netcom.com (Ronald F. Guilmette) writes:

>The bottom line however is that it is a lot more fun to play language
>designer than it is to write precise documentation of existing features.
>So what do you think the committee has been doing over the past four
>years?  You guessed it.  Playing a big collective game of on-the-fly
>``language designer''.  Guess what the committee has not yet even *begun*
>to do seriously.  You guessed it.  Specifying the *existing* language in
>detail.  (Why spoil the fun by doing real work?)

>Well, in all fairness, I should note the valiant efforts of at least some
>members of the committee in their work on *defining* the existing language,
>rather than merely trying to cook up a new language before the old one is
>even documented.  You know who you are.

As an outsider, I don't know if this characterization is fair or not, but
I do know the perception is widely shared that the committee has gone off
the tracks. Remember FORTRAN 8x? Now we have C++ 9x.

Bob Foster

objfactory@aol.com

In article <2gqg11$1m7@news.delphi.com> bobkf@news.delphi.com (BOBKF@DELPHI.COM) writes:
>rfg@netcom.com (Ronald F. Guilmette) writes:
>
>>The bottom line however is that it is a lot more fun to play language
>>designer than it is to write precise documentation of existing features.

>>Well, in all fairness, I should note the valiant efforts of at least some
>>members of the committee in their work on *defining* the existing language,
>>rather than merely trying to cook up a new language before the old one is
>>even documented.  You know who you are.
>
>As an outsider, I don't know if this characterization is fair or not, but
>I do know the perception is widely shared that the committee has gone off
>the tracks. Remember FORTRAN 8x? Now we have C++ 9x.
>
>Bob Foster
>

 Whose tracks? Who determines what is required?
What you need may not be what others need.

 In my opinion, the committee is doing an excellent job
of bring diverse implementations into line --- whether an
actual document has been produced yet or not. Its very hard to
codify "existing practice" when its not standard. We need to
make the practice standard before we can make it Standard.

 If you want a standard NOW, you already have one.
Its called the ARM.
--
        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

From: bobkf@news.delphi.com (BOBKF@DELPHI.COM @ Delphi Internet Services Corporation) writes

 > As an outsider, I don't know if this characterization is fair or not, but
 > I do know the perception is widely shared that the committee has gone off
 > the tracks.

At the start of standardization the target date for a first draft was ``late '93
or early '94.'' Compared to other language standards efforts this was VERY ambitious.
For example, C standardization took 7 years. Our current target in September '94
and I think we'll meet that.

Again, I encourage people to stick to facts, to listen to people actually working
in the committee, and ignore some of the exaggerated rumors that some people seem
to like to spread. There can be a wide gap between perception and reality.

 - Bjarne

In article <WARSAW.93Dec20133210@anthem.nlm.nih.gov> warsaw@nlm.nih.gov (Barry A. Warsaw) writes:
>
>>>>>> "RFG" == Ronald F Guilmette <rfg@netcom.com> writes:
>
>    RFG> Some folks (like me) might feel that this is a good idea, but
>    RFG> are aware of the fact that there are still about a zillion
>    RFG> other good ideas for things that could be changed and/or
>    RFG> added to the language... but we want to see it (the language)
>    RFG> be ``finished'' some time this century.  For that to happen,
>    RFG> a lot of ``good ideas'' are just going to have to be held
>    RFG> over for the *next* standard (or perhaps the next language).
>
>Hmm, I just can't completely buy this argument since it seems to me
>somebody or bodies are deciding which of those zillions of great ideas
>to add.

Quite so, but I am not among them.

>Of the < 1Z mods I've seen adopted recently, there are those
>that I personally think are trivial, of questionable use, and just
>slow the ponderous journey towards a `finished' language sometime this
>century.

Hey!  Join the club!

>But others *must* have them.  Fine.  But come on, don't use
>this argument only when it suites you (sorry Ronald, I don't mean to
>single you out personally).

Don't worry.  I do not take offense because *I'm* not one of the people
who has been shoveling new and untested ideas into the language on a
wholesale basis (at the last minute, as it were).

Rather, I (and a number of other voices in the wilderness) have for quite
some time been trying to get the C++ standardization committee to stop
playing the ``language laboratory'' game, and to start getting down to
the serious (and much harder) business of precisely specifying all of
the features which were already in the language four years ago (when
the committee *began* their work).

The bottom line however is that it is a lot more fun to play language
designer than it is to write precise documentation of existing features.
So what do you think the committee has been doing over the past four
years?  You guessed it.  Playing a big collective game of on-the-fly
``language designer''.  Guess what the committee has not yet even *begun*
to do seriously.  You guessed it.  Specifying the *existing* language in
detail.  (Why spoil the fun by doing real work?)

Well, in all fairness, I should note the valiant efforts of at least some
members of the committee in their work on *defining* the existing language,
rather than merely trying to cook up a new language before the old one is
even documented.  You know who you are.  Your nobel efforts have advanced
the *true* goals of the committee, but have also served to underscore the
point that you can lead a horse to water, but you can't make him drink.

>Either an idea is good above some
>threshold and goes into the language, or its not and doesn't.

Oh, youthful innocence!  How I do miss it. :-)

--

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

In <comp.std.c++> rfg@netcom.com (Ronald F. Guilmette) writes:
>
>Well, in all fairness, I should note the valiant efforts of at least some
>members of the committee in their work on *defining* the existing language,
>rather than merely trying to cook up a new language before the old one is
>even documented.  You know who you are.

Thank you!  That was good to hear.

     -- Dag Bruck

In article <2gqg11$1m7@news.delphi.com>, bobkf@news.delphi.com
(BOBKF@DELPHI.COM) wrote:

> As an outsider, I don't know if this characterization is fair or not, but
> I do know the perception is widely shared that the committee has gone off
> the tracks. Remember FORTRAN 8x? Now we have C++ 9x.

Having been active on both committees -- and Pascal too :-) :-(
I can confidently say that the C++ committee is entirely different
from the way Fortran was in 1984 or so.   Fortran had irreconcilable
differences between a slight majority who wanted to enhance the language
in major ways, and an important minority (including IBM and DEC and
at least one vocal user) which wanted not to go beyond existing
practice.  The logjam didn't break until IBM changed its approach
(after I had left the Fortran committee and was doing C++).

The C++ committee is also enhancing its language in major ways, notably
templates and exceptions.  But the committee is near unanimous that
those features should be in the standard, and many vendors are already
supporting templates and exceptions in the form proposed.  Even if
the committee were disbanded today, its work could be proved worthwhile
by noting compabibility among various implementations.  That
was not happening with Fortran.  The other extensions are not comparable in
extent to what the Fortran committee did.

Could the C++ process get bogged down as a result of objections
by committee members to its whole approach?  That does not appear to
be emerging.

I share some concerns about the editorial quality of the draft; that's
not what Fortran faced.
--
Scott Turner
Liant Software Corp.
959 Concord St., Framingham, MA 01701  USA
(508)872-8700
pkt@lpi.liant.com

In article <CJF2Hs.GCI@ucc.su.OZ.AU> maxtal@suphys.physics.su.oz.au writes:

 } Its very hard to
 } codify "existing practice" when its not standard. We need to
 } make the practice standard before we can make it Standard.

If you subscribe to this argument, then the committee need not
consider current implementations. It can simply define a language and
wait for implementations to follow.

 }  If you want a standard NOW, you already have one.
 } Its called the ARM.

While it has been the authoritative language definition, the ARM is
vague or unimplementable on critical issues, as you well know. It
cannot replace a Standard.  Furthermore, as a software engineer, I
would be ill-advised to write code conforming to the ARM, since that's
not the language definition that compiler writers are targeting.

Daniel Edelson
daniel@lia.com

>>>>> "RFG" == Ronald F Guilmette <rfg@netcom.com> writes:

    RFG> Some folks (like me) might feel that this is a good idea, but
    RFG> are aware of the fact that there are still about a zillion
    RFG> other good ideas for things that could be changed and/or
    RFG> added to the language... but we want to see it (the language)
    RFG> be ``finished'' some time this century.  For that to happen,
    RFG> a lot of ``good ideas'' are just going to have to be held
    RFG> over for the *next* standard (or perhaps the next language).

Hmm, I just can't completely buy this argument since it seems to me
somebody or bodies are deciding which of those zillions of great ideas
to add.  Of the < 1Z mods I've seen adopted recently, there are those
that I personally think are trivial, of questionable use, and just
slow the ponderous journey towards a `finished' language sometime this
century. But others *must* have them.  Fine.  But come on, don't use
this argument only when it suites you (sorry Ronald, I don't mean to
single you out personally).  Either an idea is good above some
threshold and goes into the language, or its not and doesn't.

But that's beside the point I was making anyway. I was just saying
that since I hadn't even seen a *discussion* (or a single followup or
reply before yours), it simply appeared that nobody's even thought
about it much.  I figure that's probably because most folks don't
actually have covariant support in their compilers.  Maybe once they
do, they'll see this simple construct as a natural progression.

Go ahead, finish the language first.  Until then, I suppose I'll just
#include.

hall_j@sat.mot.com (Joseph Hall) writes:

>What do you think are the merits (if any) of:

>  class A {};

Makes a good common base class.

class Void {};


class Int : public Void {
 ...
};

...

--
Warwick

In article <WARSAW.93Dec7131801@anthem.nlm.nih.gov> warsaw@nlm.nih.gov (Barry A. Warsaw) writes:
>
>>>>>> "JH" == Joseph Hall <hall_j@sat.mot.com> writes:
>
>    JH> What do you think are the merits (if any) of:
>
>    JH> class A {};
>
>    JH> class B: public A; // <-- questionable construct
>
>    JH> So far as I know this isn't legal C++, but g++ supports it.
>
>In the face of covariant return types, forward declaration of derived
>classes would seem to be quite useful.  I posted a query about this on
>c.s.c++ a few weeks back but saw exactly zero responses!  Either my
>post didn't make it out, or no one else thinks its really that
>important (both are possibilities I guess ;-).

There is a third possibility.

Some folks (like me) might feel that this is a good idea, but are aware
of the fact that there are still about a zillion other good ideas for
things that could be changed and/or added to the language... but we want
to see it (the language) be ``finished'' some time this century.  For that
to happen, a lot of ``good ideas'' are just going to have to be held over
for the *next* standard (or perhaps the next language).

--

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

What do you think are the merits (if any) of:

  class A {};

  class B: public A;   // <-- questionable construct

So far as I know this isn't legal C++, but g++ supports it.

--
Joseph Nathan Hall |  Whales: smart food for smart people
Software Architect |
Gorca Systems Inc. |                 joseph@joebloe.maple-shade.nj.us (home)
(on assignment)    |         (602) 732-2549 (work)   Joseph_Hall@sat.mot.com

>>>>> "JH" == Joseph Hall <hall_j@sat.mot.com> writes:

    JH> What do you think are the merits (if any) of:

    JH> class A {};

    JH> class B: public A; // <-- questionable construct

    JH> So far as I know this isn't legal C++, but g++ supports it.

In the face of covariant return types, forward declaration of derived
classes would seem to be quite useful.  I posted a query about this on
c.s.c++ a few weeks back but saw exactly zero responses!  Either my
post didn't make it out, or no one else thinks its really that
important (both are possibilities I guess ;-).