From: ian-news@hotmail.com   
      
   On 10/ 5/11 11:41 AM, nmm1@cam.ac.uk wrote:   
   > In article<98f5459d-c0f9-4d90-8310-47888a1519cf@q13g2000vby.go   
   glegroups.com>,   
   > Mathias Gaunard  wrote:   
   >>   
   >>> It is unclear about exactly which constructors etc. container and   
   >>> other operations are allowed to use.  In particular, when may they   
   >>> create a temporary copy?  That is particularly important when the   
   >>> location of an object is constrained or carries information (e.g.   
   >>> it is commonly used as an equality breaker in sorting).   
   >>>   
   >>> But it is also important when the object includes certain types of   
   >>> data, such as locks and memory-mapped arrays.  How much extra   
   >>> complexity does the programmer have to add to defend himself against   
   >>> what the STL code may do?   
   >>   
   >> If the address of the objects are themselves important, clearly you   
   >> want a container of pointers to those objects, not a container of the   
   >> objects themselves.   
   >   
   > No, that is NOT true!  You may want copying to create a fresh copy,   
   > not an alias.  Yes, you can manage such objects by using pointers   
   > and fancy constructors, but that's not relevant to my point - for   
   > heaven's sake, I have been doing this for decades in many languages!   
      
   What exactly is your point?  You appear to be saying generic containers   
   muse support specific copy requirements which doesn't make a lot of sense.   
      
   > Furthermore, with locks and RDMA and a competently designed program,   
   > you should never be copying such an object when it is active; a   
   > good copy constructor would throw an exception if that occurs.   
      
   If an object has specific copy requirements, it should (must) provide a   
   copy constructor.  This isn't specific to library containers, it's a   
   general rule.   
      
   > My point was and is that the standard does not specify when copy   
   > and move constructors etc. may be called, and when a conforming   
   > implementation must provide an operation without calling them.   
   > Without that information, you can't use the STL on such objects,   
   > no matter HOW you implement their copy constructors!   
      
   How do you use any form of (generic) container on such objects?  Copy   
   semantics are the responsibility of the object, not the container.   
      
   --   
   Ian Collins   
      
      
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)