By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,156 Members | 989 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,156 IT Pros & Developers. It's quick & easy.

Smart Pointers : auto_ptr and array

P: n/a
Hi,

Let's say I have a vector of auto_ptr defined like this :

vector< auto_ptr<T v;

is it allowed ?
Is there any side effects ?

If it's not a good idea, how can I fix this ?
May 16 '07 #1
Share this Question
Share on Google+
10 Replies


P: n/a
* mosfet:
>
vector< auto_ptr<T v;

is it allowed ?
No, because auto_ptr is not copyable, and a good compiler will complain.

Is there any side effects ?
Yes, if it compiles.

If it's not a good idea, how can I fix this ?
Use e.g. boost::shared_ptr.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
May 16 '07 #2

P: n/a
On 5/16/2007 11:41 AM, mosfet wrote:
Hi,

Let's say I have a vector of auto_ptr defined like this :

vector< auto_ptr<T v;

is it allowed ?
Is there any side effects ?
No. Not allowed. Might not compile. Don't !
If it's not a good idea, how can I fix this ?
std::vector<boost::shared_ptr<T v;
S.
--
Stefan Naewe
stefan dot naewe at atlas-elektronik dot com
May 16 '07 #3

P: n/a
On 16 May, 10:41, mosfet <john....@anonymous.orgwrote:
Hi,

Let's say I have a vector of auto_ptr defined like this :

vector< auto_ptr<T v;

is it allowed ?
NO. read http://www.ddj.com/dept/cpp/184403719
Is there any side effects ?
If it's not a good idea, how can I fix this ?
use boost/TR1 shared_ptr instead.

May 16 '07 #4

P: n/a
On May 16, 12:00 pm, "Alf P. Steinbach" <a...@start.nowrote:
* mosfet:
vector< auto_ptr<T v;
is it allowed ?
No, because auto_ptr is not copyable, and a good compiler will
complain.
Is there any side effects ?
Yes, if it compiles.
I'm no longer very sure about this---the specification of
auto_ptr seems to change each time I look---but wasn't the
motivation behind its use of auto_ptr_ref, or whatever,
precisely so that trying to instantiate std::vector on one
couldn't compile?

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

May 16 '07 #5

P: n/a
* James Kanze:
On May 16, 12:00 pm, "Alf P. Steinbach" <a...@start.nowrote:
>* mosfet:
>>vector< auto_ptr<T v;
>>is it allowed ?
>No, because auto_ptr is not copyable, and a good compiler will
complain.
>>Is there any side effects ?
>Yes, if it compiles.

I'm no longer very sure about this---the specification of
auto_ptr seems to change each time I look---but wasn't the
motivation behind its use of auto_ptr_ref, or whatever,
precisely so that trying to instantiate std::vector on one
couldn't compile?
You're asking more than I currently know. I probably did know that at
one time, and I think Howard Hinnant knows. The auto_ptr_ref trick
enables construction from a temporary (into a copy constructor with
non-const formal arg), but what its main motivation was...

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
May 19 '07 #6

P: n/a
On May 19, 5:05 am, "Alf P. Steinbach" <a...@start.nowrote:
* James Kanze:
On May 16, 12:00 pm, "Alf P. Steinbach" <a...@start.nowrote:
* mosfet:
>vector< auto_ptr<T v;
>is it allowed ?
No, because auto_ptr is not copyable, and a good compiler will
complain.
>Is there any side effects ?
Yes, if it compiles.
I'm no longer very sure about this---the specification of
auto_ptr seems to change each time I look---but wasn't the
motivation behind its use of auto_ptr_ref, or whatever,
precisely so that trying to instantiate std::vector on one
couldn't compile?
You're asking more than I currently know. I probably did know that at
one time, and I think Howard Hinnant knows. The auto_ptr_ref trick
enables construction from a temporary (into a copy constructor with
non-const formal arg), but what its main motivation was...
It may even date before his time:-).

I know that auto_ptr went through at least three versions before
the first CD, and IIRC, auto_ptr_ref was originally introduced
because the British national body threatened to vote no on the
standard unless something was done to prevent instantiation of a
container on an auto_ptr. Since then: the version in the 2003
version of the standard is significantly different than that in
the 1998, so it continued to move after I stopped looking.

About all I know is that today, I can generally use it for the
purposes I want it for, with just about any compiler. Which is
considerable progress.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

May 19 '07 #7

P: n/a
In article <11**********************@w5g2000hsg.googlegroups. com>,
James Kanze <ja*********@gmail.comwrote:
On May 19, 5:05 am, "Alf P. Steinbach" <a...@start.nowrote:
* James Kanze:
On May 16, 12:00 pm, "Alf P. Steinbach" <a...@start.nowrote:
>* mosfet:
>>vector< auto_ptr<T v;
>>is it allowed ?
>No, because auto_ptr is not copyable, and a good compiler will
>complain.
>>Is there any side effects ?
>Yes, if it compiles.
I'm no longer very sure about this---the specification of
auto_ptr seems to change each time I look---but wasn't the
motivation behind its use of auto_ptr_ref, or whatever,
precisely so that trying to instantiate std::vector on one
couldn't compile?
You're asking more than I currently know. I probably did know that at
one time, and I think Howard Hinnant knows. The auto_ptr_ref trick
enables construction from a temporary (into a copy constructor with
non-const formal arg), but what its main motivation was...

It may even date before his time:-).
<nodIt does.
I know that auto_ptr went through at least three versions before
the first CD, and IIRC, auto_ptr_ref was originally introduced
because the British national body threatened to vote no on the
standard unless something was done to prevent instantiation of a
container on an auto_ptr. Since then: the version in the 2003
version of the standard is significantly different than that in
the 1998, so it continued to move after I stopped looking.

About all I know is that today, I can generally use it for the
purposes I want it for, with just about any compiler. Which is
considerable progress.
See the latest working draft:

http://www.open-std.org/jtc1/sc22/wg...2007/n2284.pdf

for the latest change in the continually evolving auto_ptr:

It's deprecated. ;-)

Currently the best write up I have on auto_ptr, why it is deprecated,
and its replacement unique_ptr (which *will* work in containers) is:

http://www.open-std.org/jtc1/sc22/wg...56.html#20.4.5
%20-%20Class%20template%20auto_ptr

-Howard
May 25 '07 #8

P: n/a
On May 25, 10:04 pm, Howard Hinnant <howard.hinn...@gmail.comwrote:
In article <1179563347.135800.218...@w5g2000hsg.googlegroups. com>,
James Kanze <james.ka...@gmail.comwrote:
About all I know is that today, I can generally use it for the
purposes I want it for, with just about any compiler. Which is
considerable progress.
See the latest working draft:
http://www.open-std.org/jtc1/sc22/wg...2007/n2284.pdf
for the latest change in the continually evolving auto_ptr:

It's deprecated. ;-)
Currently the best write up I have on auto_ptr, why it is deprecated,
and its replacement unique_ptr (which *will* work in containers) is:
http://www.open-std.org/jtc1/sc22/wg.../n1856.html#20...
%20-%20Class%20template%20auto_ptr
So you invent a new name for something which serves more or less
the same purpose.

Just curious, but why the new name? Are there any legal uses of
auto_ptr that won't work exactly the same with unique_ptr? And
if not, why not call it auto_ptr, assuming that that doesn't
break any working code? (I use auto_ptr a lot in multithreaded
programs, even when I'm also using the Boehm collector.)

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

May 25 '07 #9

P: n/a
In article <11*********************@g4g2000hsf.googlegroups.c om>,
James Kanze <ja*********@gmail.comwrote:
On May 25, 10:04 pm, Howard Hinnant <howard.hinn...@gmail.comwrote:
In article <1179563347.135800.218...@w5g2000hsg.googlegroups. com>,
James Kanze <james.ka...@gmail.comwrote:
About all I know is that today, I can generally use it for the
purposes I want it for, with just about any compiler. Which is
considerable progress.
See the latest working draft:
http://www.open-std.org/jtc1/sc22/wg...2007/n2284.pdf
for the latest change in the continually evolving auto_ptr:

It's deprecated. ;-)
Currently the best write up I have on auto_ptr, why it is deprecated,
and its replacement unique_ptr (which *will* work in containers) is:
http://www.open-std.org/jtc1/sc22/wg.../n1856.html#20...
%20-%20Class%20template%20auto_ptr

So you invent a new name for something which serves more or less
the same purpose.
The new name exists because unique_ptr is not an exact superset of the
auto_ptr syntax. If it were, , we could just fix auto_ptr instead of
deprecating it and introducing a new name.
Just curious, but why the new name?
Read the link. At the top of the read is the reason for deprecating
auto_ptr and substituting in unique_ptr as the replacement. If we could
simply reengineer auto_ptr without breaking existing code we would. But
we can't.
Are there any legal uses of
auto_ptr that won't work exactly the same with unique_ptr? And
if not, why not call it auto_ptr, assuming that that doesn't
break any working code?
From the paper:
However because unique_ptr does not move from lvalues with copy syntax, it is
not a 100% source-compatible drop in replacement for auto_ptr. If it were, we
could just fix auto_ptr instead of deprecating it and introducing a new class
template.

(I use auto_ptr a lot in multithreaded
programs, even when I'm also using the Boehm collector.)
And that is the reason auto_ptr has been deprecated, not removed, from
the standard. We understand that it is heavily used and must remain in
the standard for now. Deprecation doesn't mean non-standard. It merely
means that you are put on notice that it might be removed from a future
standard (say in 2019).

Within that decade ahead of us, I hope that most uses of auto_ptr will
be able to migrate to unique_ptr. But that migration will, in some
cases, require more than just renaming auto_ptr to unique_ptr. The link
points out the breakage under this migration:
However copy semantics is disabled with unique_ptr:

auto_ptr<intap1(new int);
auto_ptr<intap2 = ap1; // ok, but unsafe implicit move

unique_ptr<intup1(new int);
unique_ptr<intup2 = up1; // compile time error: illegal access to
// private copy constructor

If you really want to transfer ownership from the lvalue unique_ptr, you move
from it just as you would any other type:

unique_ptr<intup1(new int);
unique_ptr<intup2 = move(up1); // ok, explicit move
In the interim auto_ptr and unique_ptr will coexist in the standard.
unique_ptr will support a superset of the functionality of auto_ptr, but
with slightly different syntax when "copying" (actually moving) from
lvalues.

-Howard
May 25 '07 #10

P: n/a
mosfet wrote:
If it's not a good idea, how can I fix this ?
Use a garbage collected language.

--
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/product...ntists/?usenet
May 30 '07 #11

This discussion thread is closed

Replies have been disabled for this discussion.