From: kaba@nowhere.com   
      
   14.7.2012 20:42, Wil Evers wrote:   
   > If I understand you correctly, the idea is to first build the   
   > grammar object, which is then moved to an immutable instance of   
   > itself living on the heap.   
      
   A an object of type Grammar is move-constructed to an object of type   
   Grammar. The latter object lives in the heap, managed by   
   shared_ptr (which is contained in ReadOnly).   
      
   > Because it is now immutable, it can safely be reference-counted   
   > without risking either unexpected modifications or premature   
   > destruction; the key is to first 'constipate' the object before it   
   > becomes shared.   
      
   The object in the heap can not be modified because ReadOnly only   
   provides a const reference to the contained Grammar. There can be no   
   existing mutable references to the Grammar object in the heap, because   
   it was just created.   
      
   > I think it was Andrew Koenig who first said that for immutable   
   > objects, there is little difference between pass-by-value and   
   > pass-by-reference.   
   >   
   > One thing that puzzles me though is the last line of your example.   
   > Is it meant to reopen the grammar for further modifications after   
   > all parsers are done with it?   
      
   Yes. When there are no objects referring to the grammar object, it can   
   again be modified at will.   
      
   > shared_ptr has a reset(), but it doesn't have a release().  The   
   > transfer of ownership to a shared_ptr is irreversible, because it is   
   > impossible to provide a general compile-time guarantee that the   
   > number of references to the shared object is exactly one.   
      
   A release() for the shared_ptr is not needed. The object living in the   
   heap is moved (std::move sense) back to the object living in the stack   
   ('grammar'). This operation is only allowed if the reference count is   
   one.   
      
   > IMHO, this restriction prevents an important source of run-time   
   > errors.  Without it, it seems to me your solution fails to provide   
   > the object lifetime guarantees you're asking for.   
      
   Not sure what this is referring to.   
      
   --   
   http://kaba.hilvi.org   
      
      
      
         [ 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)