C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Status of auto_ptr Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ language, library and standards View previous topic :: View next topic   Author Message Scott Meyers Guest Posted: Wed Feb 22, 2006 12:29 am    Post subject: Status of auto_ptr I was pretty up on auto_ptr through 1999, and I documented my understanding at http://www.awprofessional.com/content/images/020163371X/autoptrupdate%5Cauto_ptr_update.html (don't blame me for the funny line spacing, it got introduced sometime after I sent the document to my publisher). Then I slacked off, and though I knew that there were still issues being discussed, I didn't pay much attention until somebody complained to me that auto_ptr didn't support inheritance-based conversions as expected. They noted that an example equivalent to Case 4 in the "final" auto_ptr spec (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf) didn't compile under current compilers from MS, Gnu, and Comeau. The example is: struct Base {}; struct Derived : Base {}; auto_ptr<Derived> source(); void sink( auto_ptr<Base> ); int main() { sink( source() ); // fails to compile } Googling around yielded a thread devoted to this issue (http://tinyurl.com/r5ny8) suggesting that Case 4 was no longer considered valid per the TC1 resolution of CWG #84 (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#84). Is this the current state of affairs, i.e., that the above code should not compile -- that Case 4 in N1128 is no longer considered valid? Also, I know that there has been substantial discussion here about a revised auto_ptr spec, presumably for C++0x. What is the status of such discussions? Is it currently expected that auto_ptr will be revised for C++0x, is it more likely to be left as is, or are things still so cloudy that it's not apparent what will happen? Thanks, Scott --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Howard Hinnant Guest Posted: Wed Feb 22, 2006 7:06 am    Post subject: Re: Status of auto_ptr In article <11vnal43880r12d (AT) corp (DOT) supernews.com>, Scott Meyers <usenet (AT) aristeia (DOT) com> wrote: Quote: Also, I know that there has been substantial discussion here about a revised auto_ptr spec, presumably for C++0x. What is the status of such discussions? Is it currently expected that auto_ptr will be revised for C++0x, is it more likely to be left as is, or are things still so cloudy that it's not apparent what will happen? This is (imho) the best move forward: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#20.4.5 %20-%20Class%20template%20auto_ptr The EWG has reviewed the language features to make it possible (Lillehammer 2005-04) and voted to forward the issue to the CWG. The CWG reviewed the language features in Mont Tremblant, 2005-10. Subsequently a minor revision to the proposed wording has been written and will be submitted for the pre-Berlin meeting (2006-04). The revision is essentially clarifications and contains no functional modifications which would impact N1856. The LWG reviewed N1856 in Mont Tremblant (2005-10), and expressed support and no objections. My impression is that we are pending CWG approval of the language features. But nothing is official today (nor will it be until C++0X is ratified). -Howard --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top John Nagle Guest Posted: Wed Feb 22, 2006 7:06 am    Post subject: Re: Status of auto_ptr Scott Meyers wrote: Quote: I was pretty up on auto_ptr through 1999, and I documented my understanding at http://www.awprofessional.com/content/images/020163371X/autoptrupdate%5Cauto_ptr_update.html By now, it seems clearly established that no "tweaking" of the design of auto_ptr will really fix all the problems. After four major revisions, we're still not there. As previously discussed, this represents fundamental limitations of the core language. We have to accept that it will never really work right in this language. John Nagle Animats --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Howard Hinnant Guest Posted: Wed Feb 22, 2006 3:57 pm    Post subject: Re: Status of auto_ptr In article <11vo1sra2f4t597 (AT) corp (DOT) supernews.com>, usenet (AT) aristeia (DOT) com (Scott Meyers) wrote: Quote: Howard Hinnant wrote: modifications which would impact N1856. The LWG reviewed N1856 in Mont Tremblant (2005-10), and expressed support and no objections. So your impression is that auto_ptr may well be deprecated in C++0x, is that correct? It is my /recommendation/ that auto_ptr be deprecated in C++0X and replaced with a very similar smart pointer that avoids move with copy syntax from lvalues (named unique_ptr in the proposal). I consider auto_ptr very useful, but error prone due to its move-with-copy-syntax behavior. So I want to be clear that I'm proposing to keep the useful parts of auto_ptr while removing the error prone parts (which unfortunately requires a new name instead of just fixing auto_ptr). -Howard --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Scott Meyers Guest Posted: Wed Feb 22, 2006 4:06 pm    Post subject: Re: Status of auto_ptr Howard Hinnant wrote: Quote: modifications which would impact N1856. The LWG reviewed N1856 in Mont Tremblant (2005-10), and expressed support and no objections. So your impression is that auto_ptr may well be deprecated in C++0x, is that correct? Scott --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Axter Guest Posted: Wed Feb 22, 2006 5:17 pm    Post subject: Re: Status of auto_ptr John Nagle wrote: Quote: Scott Meyers wrote: I was pretty up on auto_ptr through 1999, and I documented my understanding at http://www.awprofessional.com/content/images/020163371X/autoptrupdate%5Cauto_ptr_update.html By now, it seems clearly established that no "tweaking" of the design of auto_ptr will really fix all the problems. After four major revisions, we're still not there. As previously discussed, this represents fundamental limitations of the core language. We have to accept that it will never really work right in this language. Instead of having auto_ptr be deprecated, why not upgrade it to a policy based smart pointer, similar to the following: http://code.axter.com/smart_ptr.h See following help document: http://axter.com/smart_ptr --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top David Abrahams Guest Posted: Wed Feb 22, 2006 6:06 pm    Post subject: Re: Status of auto_ptr nagle (AT) animats (DOT) com (John Nagle) writes: Quote: Scott Meyers wrote: I was pretty up on auto_ptr through 1999, and I documented my understanding at http://www.awprofessional.com/content/images/020163371X/autoptrupdate%5Cauto_ptr_update.html By now, it seems clearly established that no "tweaking" of the design of auto_ptr will really fix all the problems. After four major revisions, we're still not there. Four _major_ revisions? I thought there was one major revision just before standardization and a couple of small tweaks thereafer. Quote: As previously discussed, this represents fundamental limitations of the core language. We have to accept that it will never really work right in this language. Aside from the "move-with-copy-syntax" issue, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1908.html#463 fixes all the problems with auto_ptr. -- Dave Abrahams Boost Consulting www.boost-consulting.com --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top David Abrahams Guest Posted: Wed Feb 22, 2006 6:06 pm    Post subject: Re: Status of auto_ptr Howard Hinnant <howard.hinnant (AT) gmail (DOT) com> writes: Quote: In article <11vo1sra2f4t597 (AT) corp (DOT) supernews.com>, usenet (AT) aristeia (DOT) com (Scott Meyers) wrote: Howard Hinnant wrote: modifications which would impact N1856. The LWG reviewed N1856 in Mont Tremblant (2005-10), and expressed support and no objections. So your impression is that auto_ptr may well be deprecated in C++0x, is that correct? It is my /recommendation/ that auto_ptr be deprecated in C++0X and replaced with a very similar smart pointer that avoids move with copy syntax from lvalues (named unique_ptr in the proposal). I consider auto_ptr very useful, but error prone due to its move-with-copy-syntax behavior. So I want to be clear that I'm proposing to keep the useful parts of auto_ptr while removing the error prone parts (which unfortunately requires a new name instead of just fixing auto_ptr). And I agree, but I feel strongly that we should fix what we can in auto_ptr, per http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1908.html#463, before deprecation. -- Dave Abrahams Boost Consulting www.boost-consulting.com --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Howard Hinnant Guest Posted: Wed Feb 22, 2006 8:06 pm    Post subject: Re: Status of auto_ptr In article <uzmkj8j5t.fsf@boost-consulting.com>, dave@boost-consulting.com (David Abrahams) wrote: Quote: And I agree, but I feel strongly that we should fix what we can in auto_ptr, per http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1908.html#463, before deprecation. Or during deprecation. Personally I have no strong feelings about 463 as the next chance we have to make it normative is C++0X. I.e. by the time 463 goes into effect, rvalue references will (hopefully) be in the language and we could "fix" auto_ptr a lot more simply than 463 alludes to. One place 463 doesn't mention that needs fixing (and the same error is in the proposed unique_ptr) is the return type of operator*() when T is void. This will be lwg issue 541 in the pre-Berlin mailing. Martin Sebor shows this snippet: shared_ptr<void> p; p.operator=<void>(p); which breaks (at least on gcc) merely because auto_ptr exists and is recognized in the shared_ptr interface. So we absolutely have to fix that one, whether or not auto_ptr is deprecated (unless we were to pull auto_ptr from shared_ptr's interface, which I don't think is a good idea). -Howard --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Axter Guest Posted: Thu Feb 23, 2006 4:13 am    Post subject: Re: Status of auto_ptr John Nagle wrote: Quote: Scott Meyers wrote: I was pretty up on auto_ptr through 1999, and I documented my understanding at http://www.awprofessional.com/content/images/020163371X/autoptrupdate%5Cauto_ptr_update.html By now, it seems clearly established that no "tweaking" of the design of auto_ptr will really fix all the problems. After four major revisions, we're still not there. As previously discussed, this represents fundamental limitations of the core language. We have to accept that it will never really work right in this language. Instead of making auto_ptr deprecated, why not just update it to a policy base smart pointer, similar to the following? http://code.axter.com/smart_ptr.h Also see following help documents: http://axter.com/smart_ptr --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top David Abrahams Guest Posted: Thu Feb 23, 2006 5:06 am    Post subject: Re: Status of auto_ptr howard.hinnant (AT) gmail (DOT) com (Howard Hinnant) writes: Quote: In article <uzmkj8j5t.fsf@boost-consulting.com>, dave@boost-consulting.com (David Abrahams) wrote: And I agree, but I feel strongly that we should fix what we can in auto_ptr, per http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1908.html#463, before deprecation. Or during deprecation. Personally I have no strong feelings about 463 as the next chance we have to make it normative is C++0X. I.e. by the time 463 goes into effect, rvalue references will (hopefully) be in the language and we could "fix" auto_ptr a lot more simply than 463 alludes to. What did you have in mind? (Deprecation is no fix.) Quote: One place 463 doesn't mention that needs fixing (and the same error is in the proposed unique_ptr) is the return type of operator*() when T is void. This will be lwg issue 541 in the pre-Berlin mailing. Martin Sebor shows this snippet: shared_ptr<void> p; p.operator=<void>(p); which breaks (at least on gcc) And it's desirable to be able to explicitly specify the non-copy version of the assignment operator? Why is this important? Quote: merely because auto_ptr exists and is recognized in the shared_ptr interface. So we absolutely have to fix that one, whether or not auto_ptr is deprecated (unless we were to pull auto_ptr from shared_ptr's interface, which I don't think is a good idea). Sorry, I just don't see the imperative there. Not that I have an objection to it. BTW, have you made sure that unique_ptr is required to use the equivalent of checked_delete? -- Dave Abrahams Boost Consulting www.boost-consulting.com --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top John Hickin Guest Posted: Thu Feb 23, 2006 4:06 pm    Post subject: Re: Status of auto_ptr "David Abrahams" <dave@boost-consulting.com> wrote in message news:u4q2rou0y.fsf@boost-consulting.com... Quote: howard.hinnant (AT) gmail (DOT) com (Howard Hinnant) writes: In article <uzmkj8j5t.fsf@boost-consulting.com>, dave@boost-consulting.com (David Abrahams) wrote: And I agree, but I feel strongly that we should fix what we can in auto_ptr, per http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1908.html#463, [text elided] Has anybody checked that auto_ptr<> and/or unique_ptr<> are feasible? [not me, since I don't have that expertise]. Is is known (I think) that no language change short of garbage collection can allow string<> to have a safe operator that is equivalent to c_str(), which is why c_str() exists in the first place. So what has to be added to make foo_ptr<> work, and is it really worth the trouble? Regards, John. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Howard Hinnant Guest Posted: Thu Feb 23, 2006 4:06 pm    Post subject: Re: Status of auto_ptr In article <1140624650.953351.79290 (AT) g47g2000cwa (DOT) googlegroups.com>, "Axter" <google (AT) axter (DOT) com> wrote: Quote: John Nagle wrote: Scott Meyers wrote: I was pretty up on auto_ptr through 1999, and I documented my understanding at http://www.awprofessional.com/content/images/020163371X/autoptrupdate%5Cau to_ptr_update.html By now, it seems clearly established that no "tweaking" of the design of auto_ptr will really fix all the problems. After four major revisions, we're still not there. As previously discussed, this represents fundamental limitations of the core language. We have to accept that it will never really work right in this language. Instead of making auto_ptr deprecated, why not just update it to a policy base smart pointer, similar to the following? http://code.axter.com/smart_ptr.h Also see following help documents: http://axter.com/smart_ptr I'm assuming you're not proposing smart_ptr itself as its overhead is 4x that of auto_ptr (as far as I can tell). N1681 "A Proposal to Add a Policy-Based Smart Pointer Framework to the Standard Library" has been proposed. -Howard --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top David Abrahams Guest Posted: Thu Feb 23, 2006 4:06 pm    Post subject: Re: Status of auto_ptr "Axter" <google (AT) axter (DOT) com> writes: Quote: John Nagle wrote: Scott Meyers wrote: I was pretty up on auto_ptr through 1999, and I documented my understanding at http://www.awprofessional.com/content/images/020163371X/autoptrupdate%5Cauto_ptr_update.html By now, it seems clearly established that no "tweaking" of the design of auto_ptr will really fix all the problems. After four major revisions, we're still not there. As previously discussed, this represents fundamental limitations of the core language. We have to accept that it will never really work right in this language. Instead of making auto_ptr deprecated, why not just update it to a policy base smart pointer, similar to the following? http://code.axter.com/smart_ptr.h Perhaps because that doesn't fix any of the problems, and creates many new problems? -- Dave Abrahams Boost Consulting www.boost-consulting.com --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Howard Hinnant Guest Posted: Thu Feb 23, 2006 5:06 pm    Post subject: Re: Status of auto_ptr In article <u4q2rou0y.fsf@boost-consulting.com>, dave@boost-consulting.com (David Abrahams) wrote: Quote: howard.hinnant (AT) gmail (DOT) com (Howard Hinnant) writes: In article <uzmkj8j5t.fsf@boost-consulting.com>, dave@boost-consulting.com (David Abrahams) wrote: And I agree, but I feel strongly that we should fix what we can in auto_ptr, per http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1908.html#463, before deprecation. Or during deprecation. Personally I have no strong feelings about 463 as the next chance we have to make it normative is C++0X. I.e. by the time 463 goes into effect, rvalue references will (hopefully) be in the language and we could "fix" auto_ptr a lot more simply than 463 alludes to. What did you have in mind? (Deprecation is no fix.) Only that auto_ptr could be implemented something like (untested): template <class T> class auto_ptr { public: auto_ptr(auto_ptr& p) : ptr_(p.ptr_) {p.ptr_ = 0;} auto_ptr(auto_ptr&& p) : ptr_(p.ptr_) {p.ptr_ = 0;} ... }; Quote: One place 463 doesn't mention that needs fixing (and the same error is in the proposed unique_ptr) is the return type of operator*() when T is void. This will be lwg issue 541 in the pre-Berlin mailing. Martin Sebor shows this snippet: shared_ptr<void> p; p.operator=<void>(p); which breaks (at least on gcc) And it's desirable to be able to explicitly specify the non-copy version of the assignment operator? Why is this important? Good question, not sure. But it sure is easy to fix. Quote: BTW, have you made sure that unique_ptr is required to use the equivalent of checked_delete? <nod> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html search for "incomplete". -Howard --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ language, library and standards All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.