🚀 go-pugleaf

dak wrote:
[text elided]
|> Has it even been discussed ? I do find it quite cynical that this exact
|> choice (temporaries are const) makes it hard to use auto_ptr in return
|> value (and some other uses too in smart pointer), while most compiler have
|> a switch to allow non-const temporaries (and thus disabling any protection
|> from unexpected conversion on function argument that was the original
|> intent).

Perhaps the assumptions underlying the original decree are no longer valid
because of the extra control over conversions available in 'standard C++'.

Permit me to open a can of worms...

I can implement a version of auto_ptr that is fully const correct because the
implementation uses a pointer to a pointer to hold onto the basic resource.

One could, therefore, argue that because a const correct implementation can
exist that an implementation with the same observables, but with const
correctness twisted a bit, should be OK.  (See note 1 below).

One could also turn this about-face; the net result of banishing the proposed
hackery being an argument in favour of deep const.  I warned you about a can of
worms!

J.


Notes:
-----

1. As far as I can see, true const correctness with a pointer-to-pointer
   implementation might require bounding the number of auto_ptr instances.
   The implementation, therefore, would not quite live up to the spec for
   auto_ptr (but in any practical system there will be an upper bound).

-- 
John Hickin      Bell-Northern Research, Montreal, Quebec
(514) 765-7924   hickin@bnr.ca
---
[ 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. ]