TITLE: STL to be exception safe [ This is an abbreviated version of Glen McCluskey's C++ newsletter. For the full text, see the subscription information in the trailer. -adc ] AUTHOR: Glen McCluskey Issue #029 November, 1997 Contents: Notes From ANSI/ISO - State of the C++ Standard - It's Done! Notes From ANSI/ISO - Exception Safety in Containers, Part 1 Introduction to Object-oriented Design Part 8 - A Book on C++ Design Introduction to C++ Libraries Part 2 - Book Review - Inner Loops NOTES FROM ANSI/ISO - STATE OF THE C++ STANDARD - IT'S DONE! Jonathan Schilling, jls@sco.com [snip] NOTES FROM ANSI/ISO - EXCEPTION SAFETY IN CONTAINERS, PART 1 Jonathan Schilling, jls@sco.com One of the best improvements made in the standard happened at the last two meetings in London and Morristown. This is the requirement that library containers (that is, the STL) behave in an "exception safe" manner if an exception is thrown during a container operation. (Typically such exceptions might come from a failed new or from a copy constructor for the contained object). Prior to these changes, if an exception was thrown, all bets were off, and as a consequence the library didn't work well with the language's recommended way of reporting error conditions. What does "exception safe" mean? Basically there are three levels of guarantees: 1. Certain operations will do nothing if an exception is thrown during the operation. 2. Other operations do not have that guarantee, but at least will not leak memory, fail to destruct constructed objects, or behave in an undefined manner upon destruction of the container. 3. Destructors in the library are guaranteed not to throw an exception. The first level of guarantee can be thought of as "commit or rollback" semantics. For example, if you insert an object into a list, you can know that if the insertion is successful the list will now contain that object, or if it is unsuccessful the list will remain unchanged. The second level of guarantee is weaker than that. It simply states that the contents of the container are undefined, but the program will still behave reasonably otherwise. Thus, for example, if an insertion into a vector is unsuccessful, you will still have a working, destructible vector, but its contents are unknown -- it might be unchanged from before the operation, or it might be empty, or anywhere in between. The third guarantee is simply to ensure sane behavior of the library. As a general rule, no destructor should ever throw an exception! The rationale for the difference between the two levels of guarantees is based on how the different STL containers are implemented and the difficulty of supporting the guarantees; this and other details of exception safety in containers will be discussed in more detail in the next issue. INTRODUCTION TO OBJECT-ORIENTED DESIGN PART 8 - A BOOK ON C++ DESIGN [snip] INTRODUCTION TO C++ LIBRARIES PART 2 - [snip] BOOK REVIEW - INNER LOOPS [snip] ACKNOWLEDGEMENTS Thanks to Nathan Myers, Eric Nagler, David Nelson, and Jonathan Schilling for help with proofreading. SUBSCRIPTION INFORMATION / BACK ISSUES To subscribe to the newsletter, send mail to majordomo@world.std.com with this line as its message body: subscribe c_plus_plus Back issues are available via FTP from: ftp.glenmccl.com /morespace1/glenmccl/newslett or on the Web at: http://www.glenmccl.com/~glenm There is also a Java newsletter. To subscribe to it, say: subscribe java_letter using the same majordomo@world.std.com address. ------------------------- Copyright (c) 1997 Glen McCluskey. All Rights Reserved. This newsletter may be further distributed provided that it is copied in its entirety, including the newsletter number at the top and the copyright and contact information at the bottom. Glen McCluskey & Associates Professional C++ Consulting Internet: glenm@glenmccl.com Phone: (800) 722-1613 or (970) 490-2462 Fax: (970) 490-2463 FTP: ftp.glenmccl.com /morespace1/glenmccl/newslett (for back issues) Web: http://www.glenmccl.com/~glenm