Hello readers!
Maybe reference counting should be in the standard after all?
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)...
Did the commitee members expected its standardization to take so much time?
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). 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).

Which reminds me - in localization library, wouldn't it be nicer to put
'id' field in Facet class itself instead of having all derived classes to
include it explicitly anyway?)

             Best regards                  Genie

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?..

--
--------------------------------------------------------------------
Eugene V. Radchenko           Graduate Student in Computer Chemistry
E-mail: eugene@qsar.chem.msu.su                Fax: +7-(095)939-0290
Ordinary mail:  Chair of Organic Chemistry, Department of Chemistry,
                      Moscow State University, 119899 Moscow, Russia
*****************  Disappearances are deceptive  *******************
---
[ 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. ]