Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #14443 > unrolled thread

A question on "uncopyable" that disable copy constructor

Back to article view | Back to comp.lang.c++

Contents

  A question on "uncopyable" that disable copy constructor TH <python152@gmail.com> - 2012-02-22 20:45 -0800
    Re: A question on "uncopyable" that disable copy constructor Ian Collins <ian-news@hotmail.com> - 2012-02-23 18:33 +1300
      Re: A question on "uncopyable" that disable copy constructor Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-23 08:47 +0000
        Re: A question on "uncopyable" that disable copy constructor Ian Collins <ian-news@hotmail.com> - 2012-02-26 08:16 +1300
          Re: A question on "uncopyable" that disable copy constructor Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-25 19:49 +0000
            Re: A question on "uncopyable" that disable copy constructor yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2012-02-27 14:32 +0000
              Re: A question on "uncopyable" that disable copy constructor Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-27 15:54 +0000
                Re: A question on "uncopyable" that disable copy constructor yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2012-02-27 16:15 +0000
                  Re: A question on "uncopyable" that disable copy constructor Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-27 20:58 +0000
                    Re: A question on "uncopyable" that disable copy constructor Ian Collins <ian-news@hotmail.com> - 2012-02-28 17:18 +1300
                      Re: A question on "uncopyable" that disable copy constructor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-02-28 00:00 -0500
                        Re: A question on "uncopyable" that disable copy constructor Ian Collins <ian-news@hotmail.com> - 2012-02-28 20:09 +1300
                        Re: A question on "uncopyable" that disable copy constructor Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-28 21:19 +0000
                          Re: A question on "uncopyable" that disable copy constructor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-03-04 01:05 -0500
                            Re: A question on "uncopyable" that disable copy constructor 88888 Dihedral <dihedral88888@googlemail.com> - 2012-03-04 18:01 -0800
                      Re: A question on "uncopyable" that disable copy constructor Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-28 22:02 +0000
                        Re: A question on "uncopyable" that disable copy constructor Ian Collins <ian-news@hotmail.com> - 2012-02-29 11:15 +1300
    Re: A question on "uncopyable" that disable copy constructor Miles Bader <miles@gnu.org> - 2012-02-23 15:14 +0900
      Re: A question on "uncopyable" that disable copy constructor "T.H." <python152@gmail.com> - 2012-02-23 01:51 -0800
    Re: A question on "uncopyable" that disable copy constructor bartek szurgot <basz@no.spam> - 2012-02-24 17:18 +0100
      Re: A question on "uncopyable" that disable copy constructor Juha Nieminen <nospam@thanks.invalid> - 2012-02-25 19:10 +0000
        Re: A question on "uncopyable" that disable copy constructor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-02-25 17:45 -0500
          Re: A question on "uncopyable" that disable copy constructor Juha Nieminen <nospam@thanks.invalid> - 2012-02-26 09:38 +0000
            Re: A question on "uncopyable" that disable copy constructor Juha Nieminen <nospam@thanks.invalid> - 2012-02-26 09:42 +0000
            Re: A question on "uncopyable" that disable copy constructor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-02-27 23:23 -0500
        Re: A question on "uncopyable" that disable copy constructor 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-28 17:01 -0800

Page 1 of 2  [1] 2  Next page →

#14443 — A question on "uncopyable" that disable copy constructor

Meyer's Effective C++ book talks about the case where you may want to disallow compiler generated copy constructor. The example is:

class HomeForSale {...}

It doesn't make sense to do:

HomeForSale h1(h2); or h1 = h2.

No problem. However,  Does disallowing the copy constructor effectively prohibit it from putting such object into a container type, as 

std::vector<HomeForSale> home_vec;
home_vec.push_back(h1); // need copy constructor??

It sounds like a severe constraints on the possible use of such object, am I missing anything? 

Thanks

T.H.

[toc] | [next] | [standalone]

#14444

On 02/23/12 05:45 PM, TH wrote:
> Meyer's Effective C++ book talks about the case where you may want to disallow compiler generated copy constructor. The example is:
>
> class HomeForSale {...}
>
> It doesn't make sense to do:
>
> HomeForSale h1(h2); or h1 = h2.
>
> No problem. However,  Does disallowing the copy constructor effectively prohibit it from putting such object into a container type, as
>
> std::vector<HomeForSale>  home_vec;
> home_vec.push_back(h1); // need copy constructor??

Yes.

> It sounds like a severe constraints on the possible use of such object, am I missing anything?

The reason not to allow copying?  If it is inappropriate or too 
expensive to copy a T, use a container of (smart) pointers to T.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#14446

On Thu, 2012-02-23, Ian Collins wrote:
> On 02/23/12 05:45 PM, TH wrote:
>> Meyer's Effective C++ book talks about the case where you may ...
>>
>> class HomeForSale {...}
>>
>> It doesn't make sense to do:
>>
>> HomeForSale h1(h2); or h1 = h2.
>>
>> No problem. However,  Does disallowing the copy constructor...
>>
>> std::vector<HomeForSale>  home_vec;
>> home_vec.push_back(h1); // need copy constructor??
>
> Yes.
>
>> It sounds like a severe constraints on the possible use of such object,
>> am I missing anything?
>
> The reason not to allow copying?  If it is inappropriate or too 
> expensive to copy a T, use a container of (smart) pointers to T.

It should be added though, that the uniqueness of a HomeForSale is not
enough reason to go crazy with smart pointers. If I saw a need to
place such a thing in a std::vector, I wouldn't hesitate to make it
copyable. I would also (reluctantly) add a default constructor if
needed, even though it means introducing "the nil home for sale".

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#14499

On 02/23/12 09:47 PM, Jorgen Grahn wrote:
> On Thu, 2012-02-23, Ian Collins wrote:
>> On 02/23/12 05:45 PM, TH wrote:
>>> Meyer's Effective C++ book talks about the case where you may ...
>>>
>>> class HomeForSale {...}
>>>
>>> It doesn't make sense to do:
>>>
>>> HomeForSale h1(h2); or h1 = h2.
>>>
>>> No problem. However,  Does disallowing the copy constructor...
>>>
>>> std::vector<HomeForSale>   home_vec;
>>> home_vec.push_back(h1); // need copy constructor??
>>
>> Yes.
>>
>>> It sounds like a severe constraints on the possible use of such object,
>>> am I missing anything?
>>
>> The reason not to allow copying?  If it is inappropriate or too
>> expensive to copy a T, use a container of (smart) pointers to T.
>
> It should be added though, that the uniqueness of a HomeForSale is not
> enough reason to go crazy with smart pointers. If I saw a need to
> place such a thing in a std::vector, I wouldn't hesitate to make it
> copyable. I would also (reluctantly) add a default constructor if
> needed, even though it means introducing "the nil home for sale".

That's why I clearly said "If it is inappropriate or too expensive to 
copy a T".  Some things shouldn't, or simply can't be copied.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#14500

On Sat, 2012-02-25, Ian Collins wrote:
> On 02/23/12 09:47 PM, Jorgen Grahn wrote:
>> On Thu, 2012-02-23, Ian Collins wrote:
>>> On 02/23/12 05:45 PM, TH wrote:
>>>> Meyer's Effective C++ book talks about the case where you may ...
>>>>
>>>> class HomeForSale {...}
>>>>
>>>> It doesn't make sense to do:
>>>>
>>>> HomeForSale h1(h2); or h1 = h2.
>>>>
>>>> No problem. However,  Does disallowing the copy constructor...
>>>>
>>>> std::vector<HomeForSale>   home_vec;
>>>> home_vec.push_back(h1); // need copy constructor??
>>>
>>> Yes.
>>>
>>>> It sounds like a severe constraints on the possible use of such object,
>>>> am I missing anything?
>>>
>>> The reason not to allow copying?  If it is inappropriate or too
>>> expensive to copy a T, use a container of (smart) pointers to T.
>>
>> It should be added though, that the uniqueness of a HomeForSale is not
>> enough reason to go crazy with smart pointers. If I saw a need to
>> place such a thing in a std::vector, I wouldn't hesitate to make it
>> copyable. I would also (reluctantly) add a default constructor if
>> needed, even though it means introducing "the nil home for sale".
>
> That's why I clearly said "If it is inappropriate or too expensive to 
> copy a T".  Some things shouldn't, or simply can't be copied.

I know you did; I just added my view that conceptual uniqueness of
things like a HomeForSale does not make copying "inappropriate"
enough.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#14543

In article <slrnjkieqh.1ls.grahn+nntp@frailea.sa.invalid>,
Jorgen Grahn  <grahn+nntp@snipabacken.se> wrote:
>On Sat, 2012-02-25, Ian Collins wrote:
>> On 02/23/12 09:47 PM, Jorgen Grahn wrote:
>>> On Thu, 2012-02-23, Ian Collins wrote:
>>>> On 02/23/12 05:45 PM, TH wrote:
>>>>> Meyer's Effective C++ book talks about the case where you may ...
>>>>>
>>>>> class HomeForSale {...}
>>>>>
>>>>> It doesn't make sense to do:
>>>>>
>>>>> HomeForSale h1(h2); or h1 = h2.
>>>>>
>>>>> No problem. However,  Does disallowing the copy constructor...
>>>>>
>>>>> std::vector<HomeForSale>   home_vec;
>>>>> home_vec.push_back(h1); // need copy constructor??
>>>>
>>>> Yes.
>>>>
>>>>> It sounds like a severe constraints on the possible use of such object,
>>>>> am I missing anything?
>>>>
>>>> The reason not to allow copying?  If it is inappropriate or too
>>>> expensive to copy a T, use a container of (smart) pointers to T.
>>>
>>> It should be added though, that the uniqueness of a HomeForSale is not
>>> enough reason to go crazy with smart pointers. If I saw a need to
>>> place such a thing in a std::vector, I wouldn't hesitate to make it
>>> copyable. I would also (reluctantly) add a default constructor if
>>> needed, even though it means introducing "the nil home for sale".
>>
>> That's why I clearly said "If it is inappropriate or too expensive to 
>> copy a T".  Some things shouldn't, or simply can't be copied.
>
>I know you did; I just added my view that conceptual uniqueness of
>things like a HomeForSale does not make copying "inappropriate"
>enough.

I am quite willing to agree with the idea that conceptual uniqueness
may not necessarily require to actually make the object non-copyable.
If there's really a need for the object to be copied, then by all
mean, go for it and figure out a different way to preserve uniqueness.

I am however concerned with the statement "go crazy with smart
pointer".  Are you suggesting that:

std::vector< std::shared_ptr<HomeForSale> > home_vec; 

is going crazy?

Yannick

[toc] | [prev] | [next] | [standalone]

#14547

On Mon, 2012-02-27, yatremblay@bel1lin202.(none) (Yannick Tremblay) wrote:
> In article <slrnjkieqh.1ls.grahn+nntp@frailea.sa.invalid>,
> Jorgen Grahn  <grahn+nntp@snipabacken.se> wrote:
>>On Sat, 2012-02-25, Ian Collins wrote:
>>> On 02/23/12 09:47 PM, Jorgen Grahn wrote:
...
>>>> It should be added though, that the uniqueness of a HomeForSale is not
>>>> enough reason to go crazy with smart pointers. If I saw a need to
>>>> place such a thing in a std::vector, I wouldn't hesitate to make it
>>>> copyable. I would also (reluctantly) add a default constructor if
>>>> needed, even though it means introducing "the nil home for sale".
>>>
>>> That's why I clearly said "If it is inappropriate or too expensive to 
>>> copy a T".  Some things shouldn't, or simply can't be copied.
>>
>>I know you did; I just added my view that conceptual uniqueness of
>>things like a HomeForSale does not make copying "inappropriate"
>>enough.
>
> I am quite willing to agree with the idea that conceptual uniqueness
> may not necessarily require to actually make the object non-copyable.
> If there's really a need for the object to be copied, then by all
> mean, go for it and figure out a different way to preserve uniqueness.
>
> I am however concerned with the statement "go crazy with smart
> pointer".  Are you suggesting that:
>
> std::vector< std::shared_ptr<HomeForSale> > home_vec; 
>
> is going crazy?

How could I tell without context?

I'm just saying that if std::vector is the only reason to add a
default constructor and copy constructor to HomeForSale, then I curse
under my breath, and then find a way to implement and document them.
I wouldn't want to see any kind of pointer used /just to avoid that/.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#14548

In article <slrnjkn9pb.1ls.grahn+nntp@frailea.sa.invalid>,
Jorgen Grahn  <grahn+nntp@snipabacken.se> wrote:
>On Mon, 2012-02-27, yatremblay@bel1lin202.(none) (Yannick Tremblay) wrote:
>> In article <slrnjkieqh.1ls.grahn+nntp@frailea.sa.invalid>,
>> Jorgen Grahn  <grahn+nntp@snipabacken.se> wrote:
>>>On Sat, 2012-02-25, Ian Collins wrote:
>>>> On 02/23/12 09:47 PM, Jorgen Grahn wrote:
>...
>>>>> It should be added though, that the uniqueness of a HomeForSale is not
>>>>> enough reason to go crazy with smart pointers. If I saw a need to
>>>>> place such a thing in a std::vector, I wouldn't hesitate to make it
>>>>> copyable. I would also (reluctantly) add a default constructor if
>>>>> needed, even though it means introducing "the nil home for sale".
>>>>
>>>> That's why I clearly said "If it is inappropriate or too expensive to 
>>>> copy a T".  Some things shouldn't, or simply can't be copied.
>>>
>>>I know you did; I just added my view that conceptual uniqueness of
>>>things like a HomeForSale does not make copying "inappropriate"
>>>enough.
>>
>> I am quite willing to agree with the idea that conceptual uniqueness
>> may not necessarily require to actually make the object non-copyable.
>> If there's really a need for the object to be copied, then by all
>> mean, go for it and figure out a different way to preserve uniqueness.
>>
>> I am however concerned with the statement "go crazy with smart
>> pointer".  Are you suggesting that:
>>
>> std::vector< std::shared_ptr<HomeForSale> > home_vec; 
>>
>> is going crazy?
>
>How could I tell without context?
>
>I'm just saying that if std::vector is the only reason to add a
>default constructor and copy constructor to HomeForSale, then I curse
>under my breath, and then find a way to implement and document them.
>I wouldn't want to see any kind of pointer used /just to avoid that/.

I still don't follow you.  

We have the HomeForSale class.  It is non-sensical to copy a
HomeForSale and the concept a a default HomeForSale is also
non-sensical (we don't live in dark utopia of default homes :-) 

But /just to avoid using any kind of pointers/, you find a way to
implement copying and default construction that you then need to
document to explain to future generation that they should never be
used per se and that they are only a hack to fullfill the std::vector
requirements...

Why is using "any kind of pointer" such a bad thing that it is worth
jumping through hoop to avoid doing it?

Yannick

[toc] | [prev] | [next] | [standalone]

#14566

On Mon, 2012-02-27, yatremblay@bel1lin202.(none) (Yannick Tremblay) wrote:
> In article <slrnjkn9pb.1ls.grahn+nntp@frailea.sa.invalid>,
> Jorgen Grahn  <grahn+nntp@snipabacken.se> wrote:
>>On Mon, 2012-02-27, yatremblay@bel1lin202.(none) (Yannick Tremblay) wrote:
>>> In article <slrnjkieqh.1ls.grahn+nntp@frailea.sa.invalid>,
>>> Jorgen Grahn  <grahn+nntp@snipabacken.se> wrote:
>>>>On Sat, 2012-02-25, Ian Collins wrote:
>>>>> On 02/23/12 09:47 PM, Jorgen Grahn wrote:
>>...
>>>>>> It should be added though, that the uniqueness of a HomeForSale is not
>>>>>> enough reason to go crazy with smart pointers. If I saw a need to
>>>>>> place such a thing in a std::vector, I wouldn't hesitate to make it
>>>>>> copyable. I would also (reluctantly) add a default constructor if
>>>>>> needed, even though it means introducing "the nil home for sale".
>>>>>
>>>>> That's why I clearly said "If it is inappropriate or too expensive to 
>>>>> copy a T".  Some things shouldn't, or simply can't be copied.
>>>>
>>>>I know you did; I just added my view that conceptual uniqueness of
>>>>things like a HomeForSale does not make copying "inappropriate"
>>>>enough.
>>>
>>> I am quite willing to agree with the idea that conceptual uniqueness
>>> may not necessarily require to actually make the object non-copyable.
>>> If there's really a need for the object to be copied, then by all
>>> mean, go for it and figure out a different way to preserve uniqueness.
>>>
>>> I am however concerned with the statement "go crazy with smart
>>> pointer".  Are you suggesting that:
>>>
>>> std::vector< std::shared_ptr<HomeForSale> > home_vec; 
>>>
>>> is going crazy?
>>
>>How could I tell without context?
>>
>>I'm just saying that if std::vector is the only reason to add a
>>default constructor and copy constructor to HomeForSale, then I curse
>>under my breath, and then find a way to implement and document them.
>>I wouldn't want to see any kind of pointer used /just to avoid that/.
>
> I still don't follow you.  
>
> We have the HomeForSale class.  It is non-sensical to copy a
> HomeForSale and the concept a a default HomeForSale is also
> non-sensical (we don't live in dark utopia of default homes :-) 
>
> But /just to avoid using any kind of pointers/, you find a way to
> implement copying and default construction that you then need to
> document to explain to future generation that they should never be
> used per se and that they are only a hack to fullfill the std::vector
> requirements...

That's right. I assume most people do it that way.
(If most people here don't, I'd like to hear about it!)

> Why is using "any kind of pointer" such a bad thing that it is worth
> jumping through hoop to avoid doing it?

I don't enjoy doing it, but "jumping through hoops" is overstating the
problem.

Performance, convoluted syntax, manual memory management. Probably
many other reasons too which I haven't thought of because I haven't
encountered those problems.

I'm also not sure that I'd prefer finding a null pointer in my array,
compared to finding a nil HomeForSale.

/Jorgen

PS. I'm talking C++98 here.  If any new C++11 features help here, I
haven't checked them out yet.

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#14570

On 02/28/12 09:58 AM, Jorgen Grahn wrote:
> On Mon, 2012-02-27, yatremblay@bel1lin202.(none) (Yannick Tremblay) wrote:
>>
>> We have the HomeForSale class.  It is non-sensical to copy a
>> HomeForSale and the concept a a default HomeForSale is also
>> non-sensical (we don't live in dark utopia of default homes :-)
>>
>> But /just to avoid using any kind of pointers/, you find a way to
>> implement copying and default construction that you then need to
>> document to explain to future generation that they should never be
>> used per se and that they are only a hack to fullfill the std::vector
>> requirements...
>
> That's right. I assume most people do it that way.
> (If most people here don't, I'd like to hear about it!)

Well I wouldn't.  I hardly ever store Ts in a vector.  More often than 
not I use a container of shared_ptr<T>.  Adding a copy constructor when 
your class design doesn't warrant one is poor form.  Consider what will 
happen if you later need to add a reference member or a managed resource 
to your class.

>> Why is using "any kind of pointer" such a bad thing that it is worth
>> jumping through hoop to avoid doing it?
>
> I don't enjoy doing it, but "jumping through hoops" is overstating the
> problem.
>
> Performance, convoluted syntax, manual memory management. Probably
> many other reasons too which I haven't thought of because I haven't
> encountered those problems.
>
> I'm also not sure that I'd prefer finding a null pointer in my array,
> compared to finding a nil HomeForSale.

Using shared_ptr<T> removes most of those issues.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#14572

Ian Collins wrote:
> On 02/28/12 09:58 AM, Jorgen Grahn wrote:
>> On Mon, 2012-02-27, yatremblay@bel1lin202.(none) (Yannick Tremblay) wrote:
>>>
>>> We have the HomeForSale class. It is non-sensical to copy a
>>> HomeForSale and the concept a a default HomeForSale is also
>>> non-sensical (we don't live in dark utopia of default homes :-)
>>>
>>> But /just to avoid using any kind of pointers/, you find a way to
>>> implement copying and default construction that you then need to
>>> document to explain to future generation that they should never be
>>> used per se and that they are only a hack to fullfill the std::vector
>>> requirements...
>>
>> That's right. I assume most people do it that way.
>> (If most people here don't, I'd like to hear about it!)
>
> Well I wouldn't. I hardly ever store Ts in a vector. More often than not I use a
> container of shared_ptr<T>. Adding a copy constructor when your class design
> doesn't warrant one is poor form. Consider what will happen if you later need to
> add a reference member or a managed resource to your class.

I think this conversation would win from agreeing on some context, namely a 
particular reason why you do not need copy constructor. As an example, if all 
one needs from an object (in terms of creation/destruction) is to keep a 
collection of them in an array and a standalone object is of no value (it's an 
often situation in my practice when you need to dispatch messages to processors 
and the processors are relatively rarely created/removed so you want to dispatch 
in amortized constant time), std::vector comes to mind. Now it's up to you to 
decide whether you introduce copy constructor or create a vector of pointers. If 
objects are very small (say, these are some stateless policies or policies 
thousands of which may share the state) but there are tons of them, vector of 
pointers may create a significant waste, even if you use some pool allocator 
(because in addition to an object, which is, say 4-8 bytes, you would have to 
keep, say, 4-byte pointers in a vector -- this is a meaningful overhead). There 
is also an additional indirection cost (which may, in some patterns, almost half 
the effective CPU cache size).

Thus, you are facing a tradeoff: add a copy constructor (unnecessary copying in 
this case is the only price; and does not seem significant because the objects 
are relatively long-living; not much ideology/design purity considerations are 
involved either IMHO) vs vector-of-pointers (with its meaningful additional 
space and time costs).

Before C++11, I would probably add a copy constructor (in this particular 
context). In C++11, emplace() gives you best of two worlds.

There can certainly be other considerations. For example, add some extra 
reference to the message-dispatching processors described above ("extra" in a 
sense that it is in addition to those kept by message sources (or logical 
connections to them)) and you would be happy if you originally chose shared 
pointer design.

IMHO, programming is all about applying abstract ideas to a concrete problem; 
and the "concrete problem" part of the equation is at least as important as are 
the abstract ideas. It often puzzles me when someone starts an argument on which 
abstract idea is "better" without first agreeing on a meaningful context to 
apply it.

....

-Pavel

[toc] | [prev] | [next] | [standalone]

#14574

On 02/28/12 06:00 PM, Pavel wrote:
> Ian Collins wrote:
>> On 02/28/12 09:58 AM, Jorgen Grahn wrote:
>>> On Mon, 2012-02-27, yatremblay@bel1lin202.(none) (Yannick Tremblay) wrote:
>>>>
>>>> We have the HomeForSale class. It is non-sensical to copy a
>>>> HomeForSale and the concept a a default HomeForSale is also
>>>> non-sensical (we don't live in dark utopia of default homes :-)
>>>>
>>>> But /just to avoid using any kind of pointers/, you find a way to
>>>> implement copying and default construction that you then need to
>>>> document to explain to future generation that they should never be
>>>> used per se and that they are only a hack to fullfill the std::vector
>>>> requirements...
>>>
>>> That's right. I assume most people do it that way.
>>> (If most people here don't, I'd like to hear about it!)
>>
>> Well I wouldn't. I hardly ever store Ts in a vector. More often than not I use a
>> container of shared_ptr<T>. Adding a copy constructor when your class design
>> doesn't warrant one is poor form. Consider what will happen if you later need to
>> add a reference member or a managed resource to your class.
>
> I think this conversation would win from agreeing on some context, namely a
> particular reason why you do not need copy constructor. As an example, if all
> one needs from an object (in terms of creation/destruction) is to keep a
> collection of them in an array and a standalone object is of no value (it's an
> often situation in my practice when you need to dispatch messages to processors
> and the processors are relatively rarely created/removed so you want to dispatch
> in amortized constant time), std::vector comes to mind. Now it's up to you to
> decide whether you introduce copy constructor or create a vector of pointers. If
> objects are very small (say, these are some stateless policies or policies
> thousands of which may share the state) but there are tons of them, vector of
> pointers may create a significant waste, even if you use some pool allocator
> (because in addition to an object, which is, say 4-8 bytes, you would have to
> keep, say, 4-byte pointers in a vector -- this is a meaningful overhead). There
> is also an additional indirection cost (which may, in some patterns, almost half
> the effective CPU cache size).

I agree with all of the above.

Most of the programming I do these days is either XML document 
processing or systems work.  Both of these usually involve searching, 
sorting and manipulating trees of objects.  Thus each "Node", even in 
its most basic form contains a vector of children and a vector of 
attributes.  So even though the objects are fairly small, copying them 
can be very expensive.

In the case of XML DOM, the interface requires a pointer based solution. 
  All access and search functions return references to or lists of nodes 
with the document.

With filesystem data and meta-data, I often have to present several 
different views of the data, which more often than not is some form of 
tree.  Here containers of T* or shared_ptr<T> are the logical choice.

So I frequently use the PIMPL idiom, where the "Node" class extends 
shared_ptr with the member functions required by the object.

> Thus, you are facing a tradeoff: add a copy constructor (unnecessary copying in
> this case is the only price; and does not seem significant because the objects
> are relatively long-living; not much ideology/design purity considerations are
> involved either IMHO) vs vector-of-pointers (with its meaningful additional
> space and time costs).

Don't forget there are often simple objects (say wrapper round a file 
handle) that are simply inappropriate to copy.

> Before C++11, I would probably add a copy constructor (in this particular
> context). In C++11, emplace() gives you best of two worlds.

I don't think id would be appropriate for object were copying is 
inappropriate, or objects that hold containers to other objects.

> There can certainly be other considerations. For example, add some extra
> reference to the message-dispatching processors described above ("extra" in a
> sense that it is in addition to those kept by message sources (or logical
> connections to them)) and you would be happy if you originally chose shared
> pointer design.
>
> IMHO, programming is all about applying abstract ideas to a concrete problem;
> and the "concrete problem" part of the equation is at least as important as are
> the abstract ideas. It often puzzles me when someone starts an argument on which
> abstract idea is "better" without first agreeing on a meaningful context to
> apply it.

Very true.  When dealing with physical entities, copying them often 
isn't appropriate

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#14599

On Tue, 2012-02-28, Pavel wrote:
> Ian Collins wrote:
>> On 02/28/12 09:58 AM, Jorgen Grahn wrote:
>>> On Mon, 2012-02-27, yatremblay@bel1lin202.(none) (Yannick Tremblay) wrote:
>>>>
>>>> We have the HomeForSale class. It is non-sensical to copy a
>>>> HomeForSale and the concept a a default HomeForSale is also
>>>> non-sensical (we don't live in dark utopia of default homes :-)
>>>>
>>>> But /just to avoid using any kind of pointers/, you find a way to
>>>> implement copying and default construction that you then need to
>>>> document to explain to future generation that they should never be
>>>> used per se and that they are only a hack to fullfill the std::vector
>>>> requirements...
>>>
>>> That's right. I assume most people do it that way.
>>> (If most people here don't, I'd like to hear about it!)
>>
>> Well I wouldn't. I hardly ever store Ts in a vector. More often than not I use a
>> container of shared_ptr<T>. Adding a copy constructor when your class design
>> doesn't warrant one is poor form. Consider what will happen if you later need to
>> add a reference member or a managed resource to your class.
>
> I think this conversation would win from agreeing on some context, namely a 
> particular reason why you do not need copy constructor.

I think the discussion shifted subtly and because of that became less
understandable. I don't mind keeping the default copy constructor for
things which are naturally copyable. The default constructor was, to me,
the real issue here.

...
> IMHO, programming is all about applying abstract ideas to a concrete problem; 
> and the "concrete problem" part of the equation is at least as important as are 
> the abstract ideas. It often puzzles me when someone starts an argument on which 
> abstract idea is "better" without first agreeing on a meaningful context to 
> apply it.

I don't think that was the case here. The HomeForSale example was
concrete enough -- and I don't think anyone suggested you should
/always/ or /never/ use containers of pointers, no matter what the
actual problem is.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#14735

Jorgen Grahn wrote:
> On Tue, 2012-02-28, Pavel wrote:
>> Ian Collins wrote:
>>> On 02/28/12 09:58 AM, Jorgen Grahn wrote:
>>>> On Mon, 2012-02-27, yatremblay@bel1lin202.(none) (Yannick Tremblay) wrote:
>>>>>
>>>>> We have the HomeForSale class. It is non-sensical to copy a
>>>>> HomeForSale and the concept a a default HomeForSale is also
>>>>> non-sensical (we don't live in dark utopia of default homes :-)
>>>>>
>>>>> But /just to avoid using any kind of pointers/, you find a way to
>>>>> implement copying and default construction that you then need to
>>>>> document to explain to future generation that they should never be
>>>>> used per se and that they are only a hack to fullfill the std::vector
>>>>> requirements...
>>>>
>>>> That's right. I assume most people do it that way.
>>>> (If most people here don't, I'd like to hear about it!)
>>>
>>> Well I wouldn't. I hardly ever store Ts in a vector. More often than not I use a
>>> container of shared_ptr<T>. Adding a copy constructor when your class design
>>> doesn't warrant one is poor form. Consider what will happen if you later need to
>>> add a reference member or a managed resource to your class.
>>
>> I think this conversation would win from agreeing on some context, namely a
>> particular reason why you do not need copy constructor.
>
> I think the discussion shifted subtly and because of that became less
> understandable. I don't mind keeping the default copy constructor for
> things which are naturally copyable. The default constructor was, to me,
> the real issue here.
>
> ...
>> IMHO, programming is all about applying abstract ideas to a concrete problem;
>> and the "concrete problem" part of the equation is at least as important as are
>> the abstract ideas. It often puzzles me when someone starts an argument on which
>> abstract idea is "better" without first agreeing on a meaningful context to
>> apply it.
>
> I don't think that was the case here. The HomeForSale example was
> concrete enough -- and I don't think anyone suggested you should
> /always/ or /never/ use containers of pointers, no matter what the
> actual problem is.
Maybe I am wrong but it seemed to me that Ian defended that "never" position.

His example with file descriptor as a simple object is very close to valid case 
for this position (in theory, file handle wrappers can be copied if file 
descriptor is dup()ed in copy constructor and dup()-ing is relatively 
inexpensive on *NIX but I am not sure about other systems (Windows 
DublicateHandle and WSADuplicateSocket in particular; also, that "relative" is 
also relative..).

If in a context of a particular problem both correct and practical definition of 
copying is *impossible* (as opposed to being just non-sensical for anything but 
storing an object in a vector), "never" position can be justified. I think Ian 
had that *practically impossible* problem in mind whereas your HomeForSale was 
to illustrate a "nonsensical for anything but" case but please correct me if I 
am wrong.

-Pavel

[toc] | [prev] | [next] | [standalone]

#14749

On Sunday, March 4, 2012 2:05:37 PM UTC+8, Pavel wrote:
> Jorgen Grahn wrote:
> > On Tue, 2012-02-28, Pavel wrote:
> >> Ian Collins wrote:
> >>> On 02/28/12 09:58 AM, Jorgen Grahn wrote:
> >>>> On Mon, 2012-02-27, yatremblay@bel1lin202.(none) (Yannick Tremblay) wrote:
> >>>>>
> >>>>> We have the HomeForSale class. It is non-sensical to copy a
> >>>>> HomeForSale and the concept a a default HomeForSale is also
> >>>>> non-sensical (we don't live in dark utopia of default homes :-)
> >>>>>
> >>>>> But /just to avoid using any kind of pointers/, you find a way to
> >>>>> implement copying and default construction that you then need to
> >>>>> document to explain to future generation that they should never be
> >>>>> used per se and that they are only a hack to fullfill the std::vector
> >>>>> requirements...
> >>>>
> >>>> That's right. I assume most people do it that way.
> >>>> (If most people here don't, I'd like to hear about it!)
> >>>
> >>> Well I wouldn't. I hardly ever store Ts in a vector. More often than not I use a
> >>> container of shared_ptr<T>. Adding a copy constructor when your class design
> >>> doesn't warrant one is poor form. Consider what will happen if you later need to
> >>> add a reference member or a managed resource to your class.
> >>
> >> I think this conversation would win from agreeing on some context, namely a
> >> particular reason why you do not need copy constructor.
> >
> > I think the discussion shifted subtly and because of that became less
> > understandable. I don't mind keeping the default copy constructor for
> > things which are naturally copyable. The default constructor was, to me,
> > the real issue here.
> >
> > ...
> >> IMHO, programming is all about applying abstract ideas to a concrete problem;
> >> and the "concrete problem" part of the equation is at least as important as are
> >> the abstract ideas. It often puzzles me when someone starts an argument on which
> >> abstract idea is "better" without first agreeing on a meaningful context to
> >> apply it.
> >
> > I don't think that was the case here. The HomeForSale example was
> > concrete enough -- and I don't think anyone suggested you should
> > /always/ or /never/ use containers of pointers, no matter what the
> > actual problem is.
> Maybe I am wrong but it seemed to me that Ian defended that "never" position.
> 
> His example with file descriptor as a simple object is very close to valid case 
> for this position (in theory, file handle wrappers can be copied if file 
> descriptor is dup()ed in copy constructor and dup()-ing is relatively 
> inexpensive on *NIX but I am not sure about other systems (Windows 
> DublicateHandle and WSADuplicateSocket in particular; also, that "relative" is 
> also relative..).
> 
> If in a context of a particular problem both correct and practical definition of 
> copying is *impossible* (as opposed to being just non-sensical for anything but 
> storing an object in a vector), "never" position can be justified. I think Ian 
> had that *practically impossible* problem in mind whereas your HomeForSale was 
> to illustrate a "nonsensical for anything but" case but please correct me if I 
> am wrong.
> 
> -Pavel



On Sunday, March 4, 2012 2:05:37 PM UTC+8, Pavel wrote:
> Jorgen Grahn wrote:
> > On Tue, 2012-02-28, Pavel wrote:
> >> Ian Collins wrote:
> >>> On 02/28/12 09:58 AM, Jorgen Grahn wrote:
> >>>> On Mon, 2012-02-27, yatremblay@bel1lin202.(none) (Yannick Tremblay) wrote:
> >>>>>
> >>>>> We have the HomeForSale class. It is non-sensical to copy a
> >>>>> HomeForSale and the concept a a default HomeForSale is also
> >>>>> non-sensical (we don't live in dark utopia of default homes :-)
> >>>>>
> >>>>> But /just to avoid using any kind of pointers/, you find a way to
> >>>>> implement copying and default construction that you then need to
> >>>>> document to explain to future generation that they should never be
> >>>>> used per se and that they are only a hack to fullfill the std::vector
> >>>>> requirements...
> >>>>
> >>>> That's right. I assume most people do it that way.
> >>>> (If most people here don't, I'd like to hear about it!)
> >>>
> >>> Well I wouldn't. I hardly ever store Ts in a vector. More often than not I use a
> >>> container of shared_ptr<T>. Adding a copy constructor when your class design
> >>> doesn't warrant one is poor form. Consider what will happen if you later need to
> >>> add a reference member or a managed resource to your class.
> >>
> >> I think this conversation would win from agreeing on some context, namely a
> >> particular reason why you do not need copy constructor.
> >
> > I think the discussion shifted subtly and because of that became less
> > understandable. I don't mind keeping the default copy constructor for
> > things which are naturally copyable. The default constructor was, to me,
> > the real issue here.
> >
> > ...
> >> IMHO, programming is all about applying abstract ideas to a concrete problem;
> >> and the "concrete problem" part of the equation is at least as important as are
> >> the abstract ideas. It often puzzles me when someone starts an argument on which
> >> abstract idea is "better" without first agreeing on a meaningful context to
> >> apply it.
> >
> > I don't think that was the case here. The HomeForSale example was
> > concrete enough -- and I don't think anyone suggested you should
> > /always/ or /never/ use containers of pointers, no matter what the
> > actual problem is.
> Maybe I am wrong but it seemed to me that Ian defended that "never" position.
> 
> His example with file descriptor as a simple object is very close to valid case 
> for this position (in theory, file handle wrappers can be copied if file 
> descriptor is dup()ed in copy constructor and dup()-ing is relatively 
> inexpensive on *NIX but I am not sure about other systems (Windows 
> DublicateHandle and WSADuplicateSocket in particular; also, that "relative" is 
> also relative..).
> 
> If in a context of a particular problem both correct and practical definition of 
> copying is *impossible* (as opposed to being just non-sensical for anything but 
> storing an object in a vector), "never" position can be justified. I think Ian 
> had that *practically impossible* problem in mind whereas your HomeForSale was 
> to illustrate a "nonsensical for anything but" case but please correct me if I 
> am wrong.
> 
> -Pavel

Well, C and C++ are both imperative. But for those objects frozen, 
a pointer or reference is enough to read the frozen object.

Thus, I distingush objects that could be modified by some methods in the run-time from those frozen ones that could be referenced by a pointer or a reference.

[toc] | [prev] | [next] | [standalone]

#14602

On Tue, 2012-02-28, Ian Collins wrote:
> On 02/28/12 09:58 AM, Jorgen Grahn wrote:
>> On Mon, 2012-02-27, yatremblay@bel1lin202.(none) (Yannick Tremblay) wrote:
>>>
>>> We have the HomeForSale class.  It is non-sensical to copy a
>>> HomeForSale and the concept a a default HomeForSale is also
>>> non-sensical (we don't live in dark utopia of default homes :-)
>>>
>>> But /just to avoid using any kind of pointers/, you find a way to
>>> implement copying and default construction that you then need to
>>> document to explain to future generation that they should never be
>>> used per se and that they are only a hack to fullfill the std::vector
>>> requirements...
>>
>> That's right. I assume most people do it that way.
>> (If most people here don't, I'd like to hear about it!)
>
> Well I wouldn't.  I hardly ever store Ts in a vector.  More often than 
> not I use a container of shared_ptr<T>.  Adding a copy constructor when 
> your class design doesn't warrant one is poor form. 

I see now that the rest of the posters in the thread focused on the
copy constructor. I got stuck on the default constructor, because
that's where I have problems.

Most of my classes are small, concrete classes and are naturally
copyable. Default copying is enough -- and come to think of it, if the
default wasn't enough, then it would probably not be one of those
classes I'd consider placing in a container!

> Consider what will 
> happen if you later need to add a reference member or a managed resource 
> to your class.

I consciously try /not/ to think of such things. A future drastic
redesign will simply have to have repercussions. Hopefully it never
has to happen -- the copyability was part of the larger design, not
accidental.

>>> Why is using "any kind of pointer" such a bad thing that it is worth
>>> jumping through hoop to avoid doing it?
>>
>> I don't enjoy doing it, but "jumping through hoops" is overstating the
>> problem.
>>
>> Performance, convoluted syntax, manual memory management. Probably
>> many other reasons too which I haven't thought of because I haven't
>> encountered those problems.
>>
>> I'm also not sure that I'd prefer finding a null pointer in my array,
>> compared to finding a nil HomeForSale.
>
> Using shared_ptr<T> removes most of those issues.

I think that last issue is enough for me.

  std::Vector<HomeForSale> homes = lots_of_homes();
  assert(!homes.empty());
  const HomeForSale& home = homes[0];
  assert(home.valid());

is not much worse compared to

  std::Vector<shared_ptr<HomeForSale> > homes = lots_of_homes();
  assert(!homes.empty());
  shared_ptr<HomeForSale> home = homes[0];
  assert(home.get());

In both cases I cannot statically know that I can pull a valid home
from the non-empty vector.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#14603

On 02/29/12 11:02 AM, Jorgen Grahn wrote:
> On Tue, 2012-02-28, Ian Collins wrote:
>> On 02/28/12 09:58 AM, Jorgen Grahn wrote:
>>>
>>> I'm also not sure that I'd prefer finding a null pointer in my array,
>>> compared to finding a nil HomeForSale.
>>
>> Using shared_ptr<T>  removes most of those issues.
>
> I think that last issue is enough for me.
>
>    std::Vector<HomeForSale>  homes = lots_of_homes();
>    assert(!homes.empty());
>    const HomeForSale&  home = homes[0];
>    assert(home.valid());
>
> is not much worse compared to
>
>    std::Vector<shared_ptr<HomeForSale>  >  homes = lots_of_homes();
>    assert(!homes.empty());
>    shared_ptr<HomeForSale>  home = homes[0];
>    assert(home.get());
>
> In both cases I cannot statically know that I can pull a valid home
> from the non-empty vector.

You could prevent default initialisation of the pointer:

#include <vector>
#include <tr1/memory>

struct X {};

struct Ptr : std::tr1::shared_ptr<X>
{
   explicit Ptr( X* x ) : std::tr1::shared_ptr<X>(x) {}

private:
   Ptr() {}
};

int main() {
   std::vector<Ptr> v(10);
}

Which is quite handy.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#14445

TH <python152@gmail.com> writes:
> Meyer's Effective C++ book talks about the case where you may want to
> disallow compiler generated copy constructor. The example is:
>
> class HomeForSale {...}
>
> It doesn't make sense to do:
>
> HomeForSale h1(h2); or h1 = h2.
>
> No problem. However, Does disallowing the copy constructor effectively
> prohibit it from putting such object into a container type, as
>
> std::vector<HomeForSale> home_vec;
> home_vec.push_back(h1); // need copy constructor??
>
> It sounds like a severe constraints on the possible use of such object,
> am I missing anything?

A typical example of a class where you don't want an automatically
generated copy-constructor is one that has pointer member which is
deallocated by the destructor; simply copying the pointer member into
a new object would cause obvious problems (as soon as the first of the
two object is destroyed, the pointer would be dangling).

The key point is that _any_ use of a default copy-constructor for such
classes -- _including_ copying by std::vector or whatever -- will
violate the invariants the class relies on, and cause problems.  So
suppressing it for all uses is a feature.  :)

Of course, often one then provides a user copy-constructor instead,
which does the right thing for copying (e.g. making a copy of the
pointed-to object in the above example).

However in some cases that's hard or maybe just annoying to implement
(maybe you'd need to add reference counting for shared resources, etc,
and for the class in question, such complexity would be unjustified by
the expect use).  Then you just disable the auto-generated constructor
and write in the documentation "don't copy this."

Yeah that means you can't put it in std::vector, etc...

However as the decision to make the object uncopyable is usually done
with an eye towards expected usage, presumably such a class is one
where "putting it in a vector" is not expected.  If you _really_ need
a vector of such objects, you can use a vector of pointers or
something instead (obviously you need to be careful and manage the
lifetimes of the pointed-to objects, but oh well).

-miles

-- 
Scriptures, n. The sacred books of our holy religion, as distinguished from
the false and profane writings on which all other faiths are based.

[toc] | [prev] | [next] | [standalone]

#14448

> A typical example of a class where you don't want an automatically
> generated copy-constructor is one that has pointer member which is
> deallocated by the destructor; simply copying the pointer member into
> a new object would cause obvious problems (as soon as the first of the
> two object is destroyed, the pointer would be dangling).
>
> The key point is that _any_ use of a default copy-constructor for such
> classes -- _including_ copying by std::vector or whatever -- will
> violate the invariants the class relies on, and cause problems.  So
> suppressing it for all uses is a feature.  :)

this "typical example" is very helpful to me as to when to consider
uncopyable object.

Thanks

T.H.

[toc] | [prev] | [next] | [standalone]

#14486

On 02/23/2012 05:45 AM, TH wrote:
> std::vector<HomeForSale> home_vec;
> home_vec.push_back(h1); // need copy constructor??
> 
> It sounds like a severe constraints on the possible use of such object, am I missing anything? 

in C++11 (new standard of C++) you can also move objects, instead of
copying them:

std::vector<Movable> v;
Movable m;
v.push_back(m);	// error - cannot copy
v.push_back( std::move(m) ); // ok - moves object

to learn more read about "rvalue references".

-- 
pozdrawiam serdecznie / best regards,
bartek szurgot
/* http://www.baszerr.org */

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web