291caeb3   
   From: daniel.kruegler@googlemail.com   
      
   On 2011-06-17 00:58, kelvSYC wrote:   
   >   
   > I'm not sure how to design this "the C++ way" (and I'm getting weird   
   > runtime errors relating to object destruction), so I'll ask here:   
      
   Let me start with the remark, that a short programmatic description   
   would have simplified your explanations a lot. I try to fill the holes   
   iteratively.   
      
   > Suppose I have a class called Function which currently stores an   
   > instance of a class Group.   
      
   I assume you mean the following kind of model code ignoring aspects of   
   access:   
      
   struct Group {};   
      
   struct Function {   
     Group g;   
      
     Function(Group g) : g(g) {}   
     virtual ~Function(){}   
     virtual void evaluate() = 0;   
   };   
      
   > This instance is not modified in any way   
   > throughout the lifetime of the object.  This class has a polymorphic   
   > function evaluate(), where the Group instance is used (evaluate() is   
   > pure virtual, and Function itself is an incomplete type).  Function is   
   > not default-constructible (a function MUST be tied to a Group), but   
   > must be assignable and copy-constructible as it must be put into a   
   > list.   
      
   Does that mean that Group is also assignable and copy-constructible?   
   What shall happen during a copy/assign of Function with the Group   
   sub-object? Cloning? Flat copy of the address?   
      
   > In the interest of saving space (say, if Group takes up a lot of   
   > space), then, I'd change have replace the copy of Group with something   
   > like a const Group&, but retaining the ability to assign.   
      
   OK, this gives me:   
      
   struct Group {};   
      
   struct Function {   
     const Group* g;   
      
     Function(const Group& g) : g(&g) {}   
     virtual ~Function(){}   
     virtual void evaluate() = 0;   
   };   
      
   But we have to keep in mind that this approach means that copies of   
   Function are not completely independent, because they share the same   
   Group object.   
      
   > Being   
   > paranoid about raw pointer members (though the input Group is always   
   > stack-allocated in my application, there might be the case it won't be   
   > in the future), I had been thinking about using some kind of smart   
   > pointer object.  Is there something that I can use in the C++ standard   
   > library or boost (which my project uses) for this?   
      
   A smart pointer makes sense. If you need to write against C++03   
   compatible compiler and library I suggest to use boost::shared_ptr,   
   because you can assign a custom deleter. This can also be a noop deleter   
   which works fine for your stack-allocated objects of type Group.   
      
   If you have a C++0x compatible compiler and library, std::shared_ptr   
   (which is more or less equivalent to boost::shared_ptr) seems suitable.   
      
   Usually I would also recommend std::unique_ptr in this case, but this   
   type is move-only, thus Function would be move-only as well and you need   
   to move around these objects. The advantage is, that you don't create   
   multiple copies that work on the same Group object. Whether this   
   approach works for you, depends on the use cases for Function.   
   std::unique_ptr also allows the provision of a custom deleter, but the   
   difference compared to std::/boost::shared_ptr is, that the deleter is   
   part of the unique_ptr type (as second template parameter).   
      
   > As an aside, if alternately a const reference is probably for the   
   > best, is there a standard exception that can be thrown on an   
   > incompatible assignment (in the case that a Function object is being   
   > assigned to one where the associated Group is different)?   
      
   I would not say that the reference is the "best" (my first assumption   
   was that you wanted a pointer) and I'm missing the criteria for a proper   
   measurement. In regard to your question of a standard exception for   
   incompatible assignment, there is nothing special coming into my mind.   
      
   HTH & Greetings from Bremen,   
      
   Daniel Krügler   
      
      
   --   
         [ 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)