auto_ptr and copy ctr question

[Soumen]

If I've class with one of data members of auto_ptr type, how should I
write copy ctr or copy assignment operator if I don't intend to allow
transfer of ownership happen? Declaring that member const could be one
option I guess. Clarify me if this understanding is wrong. Do I need
to disable these (copy ctr and assignment operator) in such cases?
What happens when I don't write one and use the compiler generated
one? Does transfer of ownership still happens or it's same as
declaring member as const? Looks like disabling these two are best
design decision.

Regards,
~ Soumen

[Victor Bazarov]

Soumen wrote:

If I've class with one of data members of auto_ptr type, how should I
write copy ctr or copy assignment operator if I don't intend to allow
transfer of ownership happen? Declaring that member const could be one
option I guess. Clarify me if this understanding is wrong. Do I need
to disable these (copy ctr and assignment operator) in such cases?
What happens when I don't write one and use the compiler generated
one? Does transfer of ownership still happens or it's same as
declaring member as const? Looks like disabling these two are best
design decision.

If you don't provide the "move semantics" offered by the auto_ptr
itself, you could do two things. One, as you mentioned, is to prohibit
the copying altogether. That's a bit harsh to me, but if your design
can endure that, it's the simplest of the two. The other is to provide
copying of the owned object by copy-creating a new one in case of the
constructor and copy-assigning the pointed-to item in case of the
assignment:

class Has_auto_ptr {
std::auto_ptr<sometypemyPtr;
public:
...
Has_auto_ptr(Has_auto_ptr const& other) :
myPtr(new sometype(*other.myPtr)) {}
Has_auto_ptr& operator =(Has_auto_ptr const& other) {
*myPtr = *other.myPtr;
return *this;
}
};

Disclaimer: the code is unchecked, provided for illustration purposes only.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Soumen]

On May 29, 6:24 pm, Victor Bazarov <[e-mail]:

Soumen wrote:

If I've class with one of data members of auto_ptr type, how should I
write copy ctr or copy assignment operator if I don't intend to allow
transfer of ownership happen? Declaring that member const could be one
option I guess. Clarify me if this understanding is wrong. Do I need
to disable these (copy ctr and assignment operator) in such cases?
What happens when I don't write one and use the compiler generated
one? Does transfer of ownership still happens or it's same as
declaring member as const? Looks like disabling these two are best
design decision.

If you don't provide the "move semantics" offered by the auto_ptr
itself, you could do two things. One, as you mentioned, is to prohibit
the copying altogether. That's a bit harsh to me, but if your design
can endure that, it's the simplest of the two. The other is to provide
copying of the owned object by copy-creating a new one in case of the
constructor and copy-assigning the pointed-to item in case of the
assignment:

class Has_auto_ptr {
std::auto_ptr<sometypemyPtr;
public:
...
Has_auto_ptr(Has_auto_ptr const& other) :
myPtr(new sometype(*other.myPtr)) {}
Has_auto_ptr& operator =(Has_auto_ptr const& other) {
*myPtr = *other.myPtr;
return *this;
}
};

Disclaimer: the code is unchecked, provided for illustration purposes only.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Thanks. Yes, deep copy is always an option.

The reason for not allowing transfer of ownership is original
object's data can potentially become invalid if copied object
goes out of scope.

Is there any better standard smart pointer which does some sort
of ref counting such that I can allow copy of pointed address
and still not bother of freeing the resource or pointer becoming
invalid?

Regards,
~ Soumen

[James Kanze]

On May 29, 3:16 pm, Soumen <[e-mail]:

If I've class with one of data members of auto_ptr type, how
should I write copy ctr or copy assignment operator if I don't
intend to allow transfer of ownership happen? Declaring that
member const could be one option I guess. Clarify me if this
understanding is wrong. Do I need to disable these (copy ctr
and assignment operator) in such cases? What happens when I
don't write one and use the compiler generated one? Does
transfer of ownership still happens or it's same as declaring
member as const? Looks like disabling these two are best
design decision.

It depends on the desired semantics. If transfer of ownership
is not desired, you have two choices: don't support copy (by
declaring the copy constructor private, and not providing an
implementation), or write a copy constructor which does a deep
copy.

--
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, [phone]

[Triple-DES]

On 29 Mai, 15:52, Soumen <[e-mail]:

Is there any better standard smart pointer which does some sort
of ref counting such that I can allow copy of pointed address
and still not bother of freeing the resource or pointer becoming
invalid?

Regards,
~ Soumen

boost/tr1 :: shared_ptr is widely used, however it is not standard
yet.

DP

[Soumen]

On May 30, 10:33 am, Triple-DES <[e-mail]:

On 29 Mai, 15:52, Soumen <[e-mail]:

Is there any better standard smart pointer which does some sort
of ref counting such that I can allow copy of pointed address
and still not bother of freeing the resource or pointer becoming
invalid?

Regards,
~ Soumen

boost/tr1 :: shared_ptr is widely used, however it is not standard
yet.

DP

Thanks. Though not part of standard, if I use boost::shared_ptr,
boost::shared_array,
boost::weak_ptr etc. properly, will the code be portable to other
platform?

Regards,
~ Soumen

[dizzy]

Soumen wrote:

On May 30, 10:33 am, Triple-DES <[e-mail]:

>On 29 Mai, 15:52, Soumen <[e-mail]:

Is there any better standard smart pointer which does some sort
of ref counting such that I can allow copy of pointed address
and still not bother of freeing the resource or pointer becoming
invalid?

Regards,
~ Soumen

boost/tr1 :: shared_ptr is widely used, however it is not standard
yet.

DP

Thanks. Though not part of standard, if I use boost::shared_ptr,
boost::shared_array,
boost::weak_ptr etc. properly, will the code be portable to other
platform?

It will work on all the platforms that boost supports, which are plenty. It
will work on some others too if we assume shared_ptr is using just a small
part of the C++ features that boost requires in general.

--
Dizzy

[Soumen]

On May 30, 1:54 pm, dizzy <[e-mail]:

Soumen wrote:

On May 30, 10:33 am, Triple-DES <[e-mail]:

On 29 Mai, 15:52, Soumen <[e-mail]:

Is there any better standard smart pointer which does some sort
of ref counting such that I can allow copy of pointed address
and still not bother of freeing the resource or pointer becoming
invalid?

Regards,
~ Soumen

boost/tr1 :: shared_ptr is widely used, however it is not standard
yet.

DP

Thanks. Though not part of standard, if I use boost::shared_ptr,
boost::shared_array,
boost::weak_ptr etc. properly, will the code be portable to other
platform?

It will work on all the platforms that boost supports, which are plenty. It
will work on some others too if we assume shared_ptr is using just a small
part of the C++ features that boost requires in general.

--
Dizzy

Thanks. Also, could you please give an idea about the overhead of this
additional
book-keeping on efficiency?

Regards,
~ Soumen

[Victor Bazarov]

Soumen wrote:

[..]
Thanks. Also, could you please give an idea about the overhead of this
additional
book-keeping on efficiency?

Additional bookkeeping lowers the performance.

Oh... Did you want numbers? Sorry, no numbers. Put it in, profile,
and if you find it to be the bottleneck, deal with it then and there,
not before even attempting to use it.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Soumen]

On Jun 2, 6:01 pm, Victor Bazarov <[e-mail]:

Soumen wrote:

[..]
Thanks. Also, could you please give an idea about the overhead of this
additional
book-keeping on efficiency?

Additional bookkeeping lowers the performance.

Oh... Did you want numbers? Sorry, no numbers. Put it in, profile,
and if you find it to be the bottleneck, deal with it then and there,
not before even attempting to use it.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Thanks for reminding "Don't do pre-mature optimization".