Status of auto_ptr
Scott Meyers
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...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Howard Hinnant
Scott Meyers <use...@aristeia.com> wrote:
> 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
John Nagle
> 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
Scott Meyers
> 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
Howard Hinnant
use...@aristeia.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).
-Howard
David Abrahams
> 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.
> 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
David Abrahams
> In article <11vo1sr...@corp.supernews.com>,
> use...@aristeia.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
---
Axter
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 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
Howard Hinnant
da...@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.
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
David Abrahams
> In article <uzmkj8...@boost-consulting.com>,
> da...@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.)
> 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?
> 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
---
Axter
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
Also see following help documents:
http://axter.com/smart_ptr
John Hickin
"David Abrahams" <da...@boost-consulting.com> wrote in message
news:u4q2ro...@boost-consulting.com...
> howard....@gmail.com (Howard Hinnant) writes:
>
> > In article <uzmkj8...@boost-consulting.com>,
> > da...@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.
David Abrahams
> 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
---
Howard Hinnant
"Axter" <goo...@axter.com> wrote:
> 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
Howard Hinnant
da...@boost-consulting.com (David Abrahams) wrote:
> howard....@gmail.com (Howard Hinnant) writes:
>
> > In article <uzmkj8...@boost-consulting.com>,
> > da...@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;}
...
};
> > 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.
> 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
Axter
> "Axter" <goo...@axter.com> writes:
>
> > 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?
What type of new problems would it create?
David Abrahams
> David Abrahams wrote:
>> "Axter" <goo...@axter.com> writes:
>>
>> > 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?
>
> What type of new problems would it create?
Complicated specification is just one. Any design with so many axes
of variability will bring along many new issues with the new
opportunities it provides.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
---
David Abrahams
> "David Abrahams" <da...@boost-consulting.com> wrote in message
> news:u4q2ro...@boost-consulting.com...
>> howard....@gmail.com (Howard Hinnant) writes:
>>
>> > In article <uzmkj8...@boost-consulting.com>,
>> > da...@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?
What do you mean by "feasible?" We have implementations of both
components in the current C++ language.
> [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(),
"Operator?" "Safe?" Maybe you need to define these terms.
> 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?
Sorry, but you've totally, utterly, lost me.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
---
Thorsten Ottosen
> In article <u4q2ro...@boost-consulting.com>,
> da...@boost-consulting.com (David Abrahams) wrote:
>>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;}
> ...
> };
>
Cool. That would also mean that we now can put auto_ptr
into containers, right?
Would it make sense to add an implicit auto_ptr<U> constructor
to unique_ptr<T> to allow a simpler interface. For example,
I currently have
foo( T* );
template<class U>
foo( auto_ptr<U> );
members. It might be nice if I could simply
replace the latter with unique_ptr<U> and have all existing code compile.
-Thorsten
Richard Smith
> 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.
Safe in what way? It would allow unintended conversions to bool (via
string -> char const* -> bool), but it wouldn't memory leak. And as
c_str() doesn't relinquish ownership, there's no memory leak. Surely
the reason there isn't an implicit conversion to char const* is that it
isn't desirable rather than for any technical reason? (My copy of D&E
is at home so I can't check.)
--
Richard Smith
Axter
> "Axter" <goo...@axter.com> writes:
>
> > David Abrahams wrote:
> >> "Axter" <goo...@axter.com> writes:
> >>
> >> > 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?
> >
> > What type of new problems would it create?
>
> Complicated specification is just one. Any design with so many axes
> of variability will bring along many new issues with the new
> opportunities it provides.
IMHO, it's well worth tackling what ever new issues may or may not
develop.
This well happen with any policy based class, and I think we do a
disservice to the language if we exclude every policy base class from
consideration to the standard, just because it's complex.
If we add a good policy base smart pointer, the result would be a
robust smart pointer that would be adaptable and functional in variety
of applications.
IMHO, this would be much better than having an auto_ptr and/or
tr1::shared_ptr class that have very limited applications.
Peter Dimov
> 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.
I've nothing against fixing the definition of auto_ptr<void>, but the
above snippet need not break even today, IMO. I don't see how anything
in the definition of auto_ptr<void> could possibly make it a better
match than shared_ptr<void> in the overload resolution of
operator=<void>. Of course this is an "interesting core language
issue". Still, a quality compiler should not need to instantiate
auto_ptr<void> in order to reach a decision.
But... on second thought,
shared_ptr<int> pi;
p.operator=<void>( pi );
needs to break. So maybe we do need to fix auto_ptr<void>.
David Abrahams
> IMHO, it's well worth tackling what ever new issues may or may not
> develop.
Easy for you to say -- you're not the one who has to tackle them :)
Come to a few committee meetings and work through issues in the
library working group, and then let's talk about what's worth
tackling. Many of these take a great deal of thought by a good number
of really smart people to work out. And the number of them that
arises is generally proportional to the complexity of an interface.
> This well happen with any policy based class, and I think we do a
> disservice to the language if we exclude every policy base class
> from consideration to the standard, just because it's complex.
We'd also do a great disservice if we accepted every policy based
design just because it was flexible. Either statement leaves me
asking "so what?"
Anyway, nobody is rejecting your design (did you submit a proposal?
the mailing deadline is either passed or very soon now), at least not
yet, and not just because it is policy-based (**). This is really
simple: auto_ptr can't go away without breaking code. We don't break
code except when really convinced it's worth the resulting pain. So
we're not going to "just update it to a policy based smart pointer."
Deprecation at least means that code using auto_ptr will not break
until some undetermined time in the future (in practice, never).
There may be a role for a policy-based smart pointer to play in std::,
but it's not a substitute for auto_ptr, and accepting one will
certainly do nothing to solve the problems people have with auto_ptr.
Those issues need to be worked out whether you spell the object with
auto_ptr semantics
auto_ptr<T>
or
policy_ptr<T, policy1, policy2, policy3>
> If we add a good policy base smart pointer, the result would be a
> robust smart pointer that would be adaptable and functional in
> variety of applications.
Or the result could be a large class of non-interoperable and
sometimes unreliable custom-made smart pointers with no common,
recognizable representatives. I don't claim to know which will
happen. How can you?
> IMHO, this would be much better than having an auto_ptr and/or
> tr1::shared_ptr class that have very limited applications.
The applications for tr1::shared_ptr are hardly "very limited." It
has proven itself to be highly usable in *many* contexts (even in
those requiring high performance), notwithstanding the fact that it
doesn't work everywhere that you might want a smart pointer.
(**) There are probably other reasons not to use your particular
design, like insufficient existing practice.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
---
Howard Hinnant
thorsten...@dezide.com (Thorsten Ottosen) wrote:
> Howard Hinnant wrote:
> > In article <u4q2ro...@boost-consulting.com>,
> > da...@boost-consulting.com (David Abrahams) wrote:
>
>
> >>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;}
> > ...
> > };
> >
>
> Cool. That would also mean that we now can put auto_ptr
> into containers, right?
You could assuming N1858 is standardized (even without this
reimplementation), but it won't be any safer than it was in 1997 or is
today. So it might be wise to explicitly disable it, which I did in the
CodeWarrior implementation:
std::vector<std::auto_ptr<int> > v;
Error : illegal use of incomplete struct/union/class
'std::vector<std::auto_ptr<int>, std::allocator<std::auto_ptr<int>>>'
HelloWorld.cp line 6 std::vector<std::auto_ptr<int> > v;
> Would it make sense to add an implicit auto_ptr<U> constructor
> to unique_ptr<T> to allow a simpler interface. For example,
> I currently have
>
> foo( T* );
> template<class U>
> foo( auto_ptr<U> );
>
> members. It might be nice if I could simply
> replace the latter with unique_ptr<U> and have all existing code compile.
I'm not sure this would be a good idea. It would simply expand
auto_ptr's ability to implicitly move from lvalues with copy syntax
(which is the fundamental reason unique_ptr is safer than auto_ptr).
If you say:
void foo(unique_ptr<T>);
You are saying: I only want to accept rvalues, or explicitly moved from
lvalue unique_ptr's. You are asking the compiler to help you prevent
this code:
unique_ptr<T> up(...); // #1
..
foo(up);
..
// up has been changed from line #1
In a large function it may be hard to spot something as subtle as an
implicit move. But the following is much easier to read:
unique_ptr<T> up(...); // #1
..
foo(move(up));
// It is now clear that up has been moved from
You can easily and quickly search for "move" in a large function to see
if up has been moved from prior to your point of interest.
If you want to transition this code from auto_ptr, the following
*explicit* transfer would be better:
foo(unique_ptr<T>(ap.release()));
-Howard
John Hickin
"Richard Smith" <ric...@ex-parrot.com> wrote in message
news:1140717708....@g44g2000cwa.googlegroups.com...
> John Hickin wrote:
>
> > 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.
>
> Safe in what way? It would allow unintended conversions to bool (via
> string -> char const* -> bool), but it wouldn't memory leak. And as
> c_str() doesn't relinquish ownership, there's no memory leak. Surely
> the reason there isn't an implicit conversion to char const* is that it
> isn't desirable rather than for any technical reason? (My copy of D&E
> is at home so I can't check.)
>
It wasn't memory leaks that I was thinkijng about, it was dangling pointers.
If you have a copy of the old Annotated Reference Manual, a.k.a., the ARM,
there was a suite of about 6 examples, each of which exposed a dangling
pointer problem. Although standard C++ is not ARM C++, I believe one or
more of these examples would still be a problem.
Regards, John.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]