4b0897bd   
   From: dave@boostpro.com   
      
   on Fri Jun 29 2012, Rani Sharoni  wrote:   
      
   > On Jun 28, 11:37 pm, Dave Abrahams  wrote:   
   >> on Tue Jun 26 2012, Rani Sharoni  wrote:   
   >> > It's seems easy to apply such principle to operations like   
   >> > container::pop() but it's less clear how to apply it to   
   >> > operations like container::clear(). should the exception abort   
   >> > the cleanup of the rest of the operations?   
   >>   
   >> Unspecified.  clear() would be a basic guarantee operation.   
   >   
   > This seems inconsistent with the "object must die" principle   
      
   Could you please spell out that principle?  I don't think I'm familiar   
   with it.   
      
   > hence hard to program with (e.g. what should a caller do if it can't   
   > unregister its callback before unloading its module).   
      
   Err... I don't know.  Maybe you should spell out what you mean.   
      
   > Should there be another "full_clear()" operations that loops around   
   > clear() in order to guarantee full cleanup? Unlike basic guarantee   
   > assign(range), I don't see any gain by leaving such operations as   
   > unspecified.   
      
   Oh, I think I see what you're getting at.  If you want to use clear()   
   to close things down, you should at *least* have a guarantee that you   
   make progress towards emptiness.   
      
   Well, clear() could give the guarantee that the container is empty   
   even upon exiting via an exception.  I don't see any point in a   
   separate full_clear() unless this guarantee poses some kind of   
   efficiency problem.   
      
   >> > Maybe this should be tackled using the built-in array destruction   
   >> > rules.   
   >>   
   >> The rules should be the same.   
   >   
   > I will see if I can at least find the current array rules (Daniel?).   
      
   Awww, man, that's just lazy.  We shouldn't use Daniel as our   
   voice-recognition-enabled intelligent copy of the standard...  Scratch   
   that; I just spent 20 minutes looking for the text on this and   
   couldn't find it.  Daniel?   
      
   -)   
      
   >> > The "object must die" principle is also problematic for functions   
   >> > like POSIX close(). AFAIR there are some cases in which the   
   >> > file-handle is still alive after close() failure (e.g. POSIX   
   >> > cancellation might abort close()).   
   >>   
   >> If it's problematic, you don't have to throw.   
   >   
   > But in the close() case the underlying object (file-handle) is still   
   > alive hence retry is required to assure cleanup.   
      
   But you can't "assure cleanup" if the cleanup operations can fail.   
      
   > POSIX close doc: "If close() is interrupted by a signal that is to   
   > be caught, it shall return -1 with errno set to [EINTR] and the   
   > state of fildes is unspecified." (i.e. basic guarantee single object   
   > destruction).   
      
   I don't think I'd want to handle cases like this with an exception.   
   Maybe a tight loop around close().   
      
   >> > In other cases, like networking breakdown when closing the   
   >> > file-handle, close() might return error but nevertheless   
   >> > guarantee that the object lifetime ended (i.e. local resources   
   >> > freed). In that sense "remote cleanup" is such problem in   
   >> > general.  C++ destruction is obviously not hospitable for such   
   >> > behaviors.   
   >>   
   >> I don't see why not.  What else can be done?   
   >   
   > close() can fail to destruct the object   
      
   close() doesn't destruct/destroy any objects.  It just does what the   
   POSIX doc says.   
      
   > and IMHO this can't be supported by the C++ destruction model that   
   > doesn't allow the object to stay alive even after the dtor   
   > throws. One can try to handle the close() case by deferring the   
   > cleanup of the underlying file-handle but the classic dtor calling   
   > close() will not work here (and I see no way the language can tackle   
   > such).   
      
   It depends what you think "working" means.  For many applications,   
   failure to close is benign.  If it isn't benign and you need to take   
   more drastic measures, well, take them.   
      
   >> > It can simply break to much cleanup code that assumes that dtors   
   >> > do NOT throw and might force new dtos code to be written in some   
   >> > ugly fashion to assure that all of its explicit code is being   
   >> > executed regardless of exceptions.   
   >>   
   >> I disagree that this is an issue.  The "ugly" rewrite could consist   
   >> of refactoring cleanups into subobjects, which is usually a pretty   
   >> attractive solution.   
   >   
   > IMHO allowing non empty dtors bodies (i.e. allow explicit   
   > destruction)   
      
   non-empty dtor body:   
      
              ~foo::foo() { non_empty(); }   
      
   explicit destruction:   
      
             p->~foo();   
      
   I don't see the relationship here.   
      
   > is more important than allowing dtors to throw hence the tradeoff in   
   > which throwing dtor will always be something to be avoided.   
      
   Having non-empty dtor bodies is not in conflict with allowing throwing   
   dtors, any more than having non-empty ctor bodies is in conflict with   
   allowing throwing ctors, is it?   
      
   > FWIW, many of the bugs I find using fault-injection is related to   
   > dtor no being called when ctor throws...   
      
   Certainly that must be a common error for people who don't follow "The   
   Dimov Rule" http://lists.boost.org/boost-users/2003/07/4662.php   
      
   --   
   Dave Abrahams   
   BoostPro Computing   
   http://www.boostpro.com   
      
      
         [ 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)