🚀 go-pugleaf

In article ABupaSmSvP@qsar.chem.msu.su, "Eugene Radchenko" <eugene@qsar.chem.msu.su> writes:
>
>P.S. Oh why the standard process takes so long? I once hoped that the
>standard will be out by the end of the year. Now it seems it will be year
>1997 at least. Thus compiler vendors have an excuse to sell retarded
>compilers...
>On the other hand, commitee members have made references several times
>about this being 'only first round of the standardization process'. Maybe
>it would be better not to issue standard requiring updates immediately?..

The process takes so long because:
1. There was and is a lot of work to do.
2. The committee decided to add significant new features to the language,
   and most time-consuming, a large standard library.
3. The committee members are all volunteers, none of whom are able to
   work full-time on the project.
4. The standard represents a consensus of many intelligent and opinionated
   people who often have different ideas about how things should work.
   Reaching consensus takes time. There is little point in issuing a
   standard that does not represent a consensus, since it will be ignored.

It is not the case that a standard will be issued that requires immediate
updates -- at least not intentionally. The committee is required to follow
the procedures of ANSI and ISO in creating the standard. One step in the
ANSI process is to issue a draft for public comment, which was done last
April. The committee knew that much work remained to be done, but wanted
feedback from the public once all (or nearly all) language features 
were in place.

ISO procedures require certification of a "Committee Draft" (CD), which was
also done. The CD is the same document sent for ANSI public comments. ISO
member nations comment on the CD, and vote on whether to certify the CD
as a "Draft International Standard" (DIS). This CD is known not to be
suitable for DIS certification, so no matter how that vote comes out,
a second CD is required. Because of the timing of the ANSI and ISO processes,
apart from the time the committee needs to work on the draft, the second CD
will not be ready for certification until April or May 1996. Assuming that
CD is really all OK and no further corrections are needed, the ANSI and ISO
process requirements (ANSI public comment period, ISO vote on DIS, then
ISO vote on final acceptance) would mean publication of that document as an
"International Standard" (IS) late in 1997. The final standard is not
expected to differ in any important way from the second CD of May 1996.
---
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. ]

"Eugene Radchenko" <eugene@qsar.chem.msu.su> wrote:
>Hello readers!
>Maybe reference counting should be in the standard after all?

   Australia argued in favour of that, but the committee couldn't
agree on a proposal, so we'll have to do without.

>At least it would eliminate the sticking point of auto_ptr constructor and
>operator= taking const or non-const arguments (as both choices are bad)...

   Yes, auto_ptr is a horrible hack IMHO.

   (It's loosely based on a class I first submitted called "Holder"
   which had more restricted semantics)

>Did the commitee members expected its standardization to take so much time?
  
   Some did, some didn't. :-)

>Probably we need two versions of the reference counting - one basically
>extended auto_ptr (or maybe leave the name and only adjust the semantics?)
>and another containing the operator T&() to mimic the actual object (the
>problem of constructing it might be solved by appropriate subclassing of
>the basic template). 

   Yes, a standard counted_ptr class.

>In the second case it might be wise to require that
>all such objects be derived from common base class providing the counter
>field (to avoid having 'new int' in ref.counter class).

   This is probably a better technique (cf discussion with James Kanze).
However, it is a bit invasive for a Standard.

>P.S. Oh why the standard process takes so long? 


   Because it is funded by voluntary efforts; and many of the
participants wanted to extend the language to be powerful enough
to meet general programming needs for a short time.

>I once hoped that the
>standard will be out by the end of the year. Now it seems it will be year
>1997 at least. Thus compiler vendors have an excuse to sell retarded
>compilers...

   I do not think that is fair, a large fraction of the standardisation
effort is performed by the very same compiler vendors.

>On the other hand, commitee members have made references several times
>about this being 'only first round of the standardization process'. Maybe
>it would be better not to issue standard requiring updates immediately?..

   The problem is not "updates", but standardising something 
grossly inadequate, or even broken. Better to get it right,
because Standards are hard to "undo".

-- 
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 email: maxtal@suphys.physics.oz.au
AUSTRALIA                      email: skaller@maxtal.com.au



---
[ 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. ]