C++ Truths

There can be levels of exception safety requirements from a class/component/method: * The basic exception guarantee: The invariants of the component are preserved, and no resources are leaked in the face of an exception. * The strong exception guarantee: The operation has either completed successfully or thrown an exception, leaving the program state exactly as it was before the operation started. ( commit-or-rollback semantics.) * The no-throw exception guarantee: The operation will not throw an exception. * The exception-neutrality: In a generic component, we usually have an additional expectation of exception-neutrality, which means that exceptions thrown by a component's type parameters (template parameter) should be propagated, unchanged, to the component's caller. ---- SRC: http://www.boost.org/more/generic_exception_safety.html

This is a small part of the discussion going on writing exception safe code in C++ especially for large C++ programs such as ACE/TAO library/frameworks. This snippet is extracted from tens of emails on the topic on the devo-group mailing list of DOC (Distributed Object Computing) group. A major part of this reply was given by Carlos O'Ryan, former student of Dr. Doug Schmidt, a famous CORBA expert. >> Either use C++ exceptions to propagate errors from constructors I agree with that. >> or don't do anything in constructors that can fail and put all such >> activities in an open() method. Unfortunately that does not jive well with RAII, a very important C++ idiom. >> "Swallow errors in destructors". >> This is something I always feel queasy about. Yes, I understand why destructors should not fail (which is a stronger requirement than not raising exceptions.) However, destructors can and will fail when dealing with OS resources (or...

This time I am trying to define my understanding of some non-GOF patterns in as few words as possible. You can read <===> mapping as "more or less similar to" Wrapper Facade <===> Data abstraction and encapsulation Leader/Follower pattern <===> Thread pool Evictor pattern <===> Object pool (object cache with a replacement strategy) Component Configurator pattern <===> dlopen/dlsym dynamic link library API

C++0x standard will expand the C++ standard library in various ways. The C++ Standardization Committee has identified 14 new sets of library functionality almost certain to be included in the next standard for C++. (C++0x could be as far as 2009 in the future) Soon after these are formally included in standard C++, we shall see a slew of (good) books published by several big names in C++ community. * Reference Wrappers * Smart Pointers * Function Return Types * Member Pointer Adapters * Function Object Binders * Polymorphic Function Wrappers * Metaprogramming and Type Traits * Random Number Generation * Mathematical Special Functions * Tuple Types * Fixed Size Array * Unordered Associative Containers (Hash Tables) * Regular expressions * C Compatibility Detailed description can be found here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1647.pdf ---- SRC: Scott Meyer

In general when a factory method returns an instance of the created object, in C++, it is a pointer to a dynamically created memory or a resource. Resource* factory(); // allocates dynamically Factory method pattern does not talk about the lifetime of the object it creates. It depends upon the caller of the factory to release the resource. It can do better here. A factory method can act smarter by returing the dynamically allocated pointer by wrapping it in an automatic pointer (auto_ptr). auto_ptr <Resource> factory(); // allocates dynamically Returning an automatic pointer strongly indicates ownership transfer as well as takes care of releasing the resource. { auto_ptr <Resource> rtemp; rtemp = factory(); . . . } // rtemp freed here automatically even in the face of exceptions!! ----- SRC: Scott Meyers