🚀 go-pugleaf

In article <AB29a1naHH@qsar.chem.msu.su> "Eugene Radchenko"
<eugene@qsar.chem.msu.su> writes:

> The fact is, multiauto_ptrs can be used in every place where singleauto_ptr
> can. The only possible drawback is the overhead in performance (negligible
> as compared to memory allocation - especially for list implementation) and
> storage (not so terrible as current compilers are not likely to put
> single_ap in register anyway).

By multiauto_ptr's, I presume you are refering to what are sometimes
called counted_ptr's.  If so, I explained the problems (at the
standardization level) in another posting.

> On the other hand, single_ap can't be put in
> STL container, can't be returned from the function, etc. Thus, the only its
> possible use is ensuring that temporarily allocated object is deleted on
> exception throw. (I would appreciate J.Kanze explaining the workarounds he
> mentioned in another follow-up).

The only `work-arounds' I can remember discussing are at the
implementation or standardization level.  I have my own implementation
of auto_ptr, which I use in containers (not STL, but the same basic
principal), as return values from functions, etc., etc.  In my case, I
simply declared the parameter to operator= to be a const reference
(instead of non-const), and cast away const in the implementation.  It's
not very pretty, but it gives me the single owner semantics defined in
the standard, while still allowing me to use the pointer in common
circumstances.  

There was a long discussion on this subject here not too long ago, and I
don't really want to open it up again.  I think it would be safe to
assume that enough of the standards committee members read this forum
(the chairman is, after all, one of the moderators), and that the
results of this previous discussion are being considered in the
standards committee.  This is certainly not the most important thing the
committee has to attend to, decisions in such a committee take time, and
there is not a `draft standard of the week'; in these conditions, I
think it only fair to give the committee time to act before re-opening
the question.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone
---
[ 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. ]