Thread View: comp.std.c++
2 messages
2 total messages
Started by dak
Mon, 22 Jan 1996 22:13
Re: auto_ptr again
Author: dak
Date: Mon, 22 Jan 1996 22:13
Date: Mon, 22 Jan 1996 22:13
35 lines
2097 bytes
2097 bytes
In article <AUSTERN.96Jan18103535@isolde.mti.sgi.com>, Matt Austern (austern@isolde.mti.sgi.com) wrote: > In article <4djrn4$js1@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM > (Steve Clamage) writes: [snip] > > That is, single ownership is a deliberate design decision based on the > > semantics an auto-ptr should have. It is not an implementation issue. > > I thought it was generally agreed that auto_ptrs as currently defined > were broken---specifically, that the semantics of strict ownership, > constness, and the binding of temporary objects, ended up making an > auto_ptr nearly useless for returning a value from a function. [snip] I would like to know what happened to the suggestion that the choice of having temporaries be const be changed to a more relaxed rule. I do not recall the exact wording of the proposition, but I believed it only put const on temporaries that were the result of a conversion. 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). If it was rejected, I'd like to know on what ground, if anyone recalls. --- [ 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. ]
Re: auto_ptr again
Author: john (j.d.) hickin
Date: Tue, 23 Jan 1996 18:22
Date: Tue, 23 Jan 1996 18:22
43 lines
2727 bytes
2727 bytes
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. ]
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads