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

Groups > comp.lang.c++ > #14574

Re: A question on "uncopyable" that disable copy constructor

Show all headers | View raw

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

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web