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

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

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

From 88888 Dihedral <dihedral88888@googlemail.com>
Newsgroups comp.lang.c++
Subject Re: A question on "uncopyable" that disable copy constructor
Date 2012-03-04 18:01 -0800
Organization http://groups.google.com
Message-ID <25443241.3446.1330912897539.JavaMail.geo-discussion-forums@pbbms5> (permalink)
References (5 earlier) <slrnjknrit.1ls.grahn+nntp@frailea.sa.invalid> <9r32s9Fcg8U1@mid.individual.net> <4f4c5f61$0$2332$c3e8da3$88b277c5@news.astraweb.com> <slrnjkqh7v.1ls.grahn+nntp@frailea.sa.invalid> <4f530638$0$1678$c3e8da3$92d0a893@news.astraweb.com>

Show all headers | View raw

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.

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