Hello,

What is a current status of a *Subj* proposal? Is C++ Standard
Committee going to accept them or not?  What was a problem?
How was it solved, if it was?

Thanks in advance


Eugene Lazutkin
eugene@int.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

>>>>> "EL" == Eugene Lazutkin <eugene@int.com> writes:
EL> Hello, What is a current status of a *Subj* proposal? Is C++
EL> Standard Committee going to accept them or not?  What was a
EL> problem?  How was it solved, if it was?

An ``STL hash table'' proposal was submitted and rejected twice.
The rejection was apparently due to the proposal being too large for
inclusion at such a late stage of the standardization process; I've
heard no-one argue its technical merits and usefulness.

Hence, no standard C++ hash tables in ISO C++ 9X... however, an
implementation is available in:
 ftp://ftp.cs.rpi.edu/pub/stl
including documentation and rationale. Also, it is suspected variants
of it will be shipped with commercial STL distributions.

 Daveed
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Eugene Lazutkin <eugene@int.com> writes:

>What is a current status of a *Subj* proposal? Is C++ Standard
>Committee going to accept them or not?  What was a problem?
>How was it solved, if it was?

A proposal was received for adding hash tables to the STL part
of the standard C++ library. Without addressing its technical
merit, the C++ Committee decided it was not possible to deal with
the proposal and still have any chance of meeting the schedule.

The proposal (or perhaps a modified version) was resubmitted
later. Again without considering the technical merit, the
Committee noted that the time situation had not changed, and
it was still not possible to consider the proposal.

To elaborate on the problem of time, nearly two years after
accepting the original STL proposal, details are still being
tweaked. The hash table proposal is about half the size of
the original STL proposal. Even if we had the resources to
devote to analyzing it, we could not afford to add another
year to the schedule.

For every person who wants just one more vital feature added to
the draft, someone else wants the standard to be declared
finished and published. The Committee has decided not to add
any more features, and to fix the remaining problems with
what we already have.
--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

> ==========Steve Clamage, 2/4/96==========

> Eugene Lazutkin <eugene@int.com> writes:
>
> >What is a current status of a *Subj* proposal? Is C++ Standard
> >Committee going to accept them or not?  What was a problem?
> >How was it solved, if it was?

> A proposal was received for adding hash tables to the STL part
> of the standard C++ library. Without addressing its technical
> merit, the C++ Committee decided it was not possible to deal with
> the proposal and still have any chance of meeting the schedule.

> The proposal (or perhaps a modified version) was resubmitted
> later. Again without considering the technical merit, the
> Committee noted that the time situation had not changed, and
> it was still not possible to consider the proposal.

> To elaborate on the problem of time, nearly two years after
> accepting the original STL proposal, details are still being
> tweaked. The hash table proposal is about half the size of
> the original STL proposal. Even if we had the resources to
> devote to analyzing it, we could not afford to add another
> year to the schedule.

> For every person who wants just one more vital feature added to
> the draft, someone else wants the standard to be declared
> finished and published. The Committee has decided not to add
> any more features, and to fix the remaining problems with
> what we already have.

Since I have been something of a pot sturrer on similar
issues, it may come as a surprise that I completely endorse
this stand as the only possible course for the committee.
The language has not fully grown up, particularly in STL-related
issues.  Yet it desparately needs to leave home and grow up
after it does.

Actually, much of my pot sturring has been pointed at getting
people to think about how to continue helping it grow out of
some a rather awkward adolescence in some areas without
a major schedule wait.  The process to make it a standard
is not really under control of the committee, rather they have
to live with most of it being imposed on them.  It may not fit
this case as well as some others, but processes are like that.
The key is to keep the process from stunting the growth during
a key time of growth (why do schedules have such an uncanny
ability to find such awkward points in development?).

So, how does growth continue in such a forced, imperfect
circumstance?  "It will not be in the standard" has to be
a premise of ANY answer.


Good Day
Dick
Dick.Menninger@DaytonOH.ATTGIS.COM
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]