🚀 go-pugleaf

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