Styczeń 2009

http://januszjankowiak.bblog.pl/wpis,dlaczego;zloty;jest;niepopularny,18412.html

http://www.youtube.com/watch?v=EvuLyRiFdFs

http://terminatorsalvation.warnerbros.com/

http://www.imdb.com/title/tt0438488/

Resource Acquisition Is Initialization, w skrócie RAII - popularny wzorzec projektowy w C++ i D. Technika łączy przejęcie i zwolnienie zasobu z inicjalizacją i deinicjalizacją zmiennych.

Przejęcie zasobu jest połączone z konstrukcją, a zwolnienie z automatyczną destrukcją zmiennej. Ponieważ wywołanie destruktora jest automatyczne gdy zmienna wyjdzie poza swój zasięg, jest zagwarantowane, że zasób zostanie zwolniony od razu gdy skończy się czas życia zmiennej. Jest to także prawdą przy wystąpieniu wyjątku. RAII jest kluczową koncepcją przy pisaniu kodu odpornego na wyjątki.

Technika RAII jest używana na przykład przy zakładaniu blokad wątków albo obsłudze plików.

Własność pamięci przydzielanej dynamicznie (za pomocą new) może być również kontrolowana za pomocą RAII. Do tego celu biblioteka standardowa C++ definiuje auto ptr. Czas życia dzielonych obiektów może być zarządzany przez smart pointer z semantyką dzielonej własności taki jak boost::shared_ptr definiowany przez bibliotekę Boost i oznaczony do włączenia do nowego standardu C++0x, lub Loki::SmartPtr z biblioteki Loki.

http://en.wikipedia.org/wiki/Resource_acquisition_is_initialization
http://pl.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
 

The approach of gaining exception safety through ordering and the ‘‘resource acquisition is
initialization’’ technique (§14.4) tends to be more elegant and more efficient than explicitly handling
errors using try-blocks. More problems with exception safety arise from a programmer ordering
code in unfortunate ways than from lack of specific exception-handling code. The basic rule of
ordering is not to destroy information before its replacement has been constructed and can be
assigned without the possibility of an exception.

http://www.research.att.com/~bs/3rd_safe.pdf

 Update:

From http://www.research.att.com/~bs/3rd_safe.pdf (E.6)

How can I define my types so that they don’t cause undefined behavior or leak resources?
The basic rules are:
[1] When updating an object, don’t destroy its old representation before a new representation
is completely constructed and can replace the old one without risk of exceptions.
For example, see the implementations of v e c t o r :: o p e r a t o r =(), s a f e _ a s s i g n (), and
v e c t o r :: p u s h _ b a c k () in §E.3.
[2] Before throwing an exception, release every resource acquired that is not owned by
some (other) object.
[2a] The ‘‘resource acquisition is initialization’’ technique (§14.4) and the language rule
that partially constructed objects are destroyed to the extent that they were constructed
(§14.4.1) can be most helpful here. For example, see l e a k () in §E.2.
[2b] The u n i n i t i a l i z e d _ c o p y () algorithm and its cousins provide automatic release of
resources in case of failure to complete construction of a set of objects (§E.4.4).
[3] Before throwing an exception, make sure that every operand is in a valid state. That is,
leave each object in a state that allows it to be accessed and destroyed without causing
undefined behavior or an exception to be thrown from a destructor. For example, see
v e c t o r ’s assignment in §E.3.2.
[3a] Note that constructors are special in that when an exception is thrown from a constructor,
no object is left behind to be destroyed later. This implies that we don’t
have to establish an invariant and that we must be sure to release all resources
acquired during a failed construction before throwing an exception.
[3b] Note that destructors are special in that an exception thrown from a destructor
almost certainly leads to violation of invariants and/or calls to t e r m i n a t e ().

In practice, it can be surprisingly difficult to follow these rules. The primary reason is that
exceptions can be thrown from places where people don’t expect them. A good example is
s t d :: b a d _ a l l o c . Every function that directly or indirectly uses n e w or an a l l o c a t o r to acquire
memory can throw b a d _ a l l o c . In some programs, we can solve this particular problem by not
running out of memory. However, for programs that are meant to run for a long time or to
accept arbitrary amounts of input, we must expect to handle various failures to acquire
resources. Thus, we must assume every function capable of throwing an exception until we
have proved otherwise.

Całkiem ciekawa dyskusja. Polecam jeśli komuś się nudzi:

http://forum.gazeta.pl/forum/72,2.html?f=17007&w=89868671&a=89868671

http://blogs.msdn.com/cbrumme/archive/2003/08/20/51504.aspx

http://wojciechbialek.blox.pl/2009/01/10-lat-za-Azjatami.html