Friday, February 24, 2006

Functions inside constructor should throw (if they fail)

This is a for constructors, which do non-trivial resource allocation
and initialization using helper member functions in the class. Exceptions
raised in such member functions should be propagated upto the constructor
and not eat them. In other words, such member functions should throw
exception if they can't satisfy their contract even though they provide
strong exception safety guarantee. Exception propagated upto
the constructor will be automatically propagated where the object is being
constructed indicating failure in object construction. Otherwise, silently
eating exceptions during object initialization will create an object in
an inconsistent state. The scope in which it is created will never know
that actually the object construction failed. If object construction can
be reasonably performed even in the face of exception, then it need not be
propagated out.

Example, LStack: A Stack implemented as a linked-list.

LStack::LStack (const LStack & s)
{
this->copy_all_nodes (s);
}

/// Following function provides strong exception safety guarantee
LStack::copy_all_nodes (const LStack &s)
{
try {
/// Copy nodes from the linked list of s into this's linked-list
/// copying of list elements may fail at arbitrary intermediate
/// position.

}
catch (...) {
this->delete_partially_initialized_list ();
/// throw; /// Should be done.
}
}

In the above case, copy_all_nodes is flowed because it failed to satisfy its
contract and still did not indicate its failure to the constructor.
Consequently, the client trying to use copy of LStack object will
be disappointed for sure.

This is important in case of constructor because it is difficult to tell
that object construction failed because there is no return value.

Tuesday, February 14, 2006

Why overloaded ++ operator signatures are different?

The canonical form of overloaded pre-increment and post-increment
operators for class Foo are declared in the following way in C++.

/// Preincrement operator
Foo & operator++ (void);

/// Postincrement operator
const Foo operator++ (int);

The int in the post-increment operator is obviously to disambiguate
between post and pre forms of the operator. Then, why is the return type
different? As many other C++ features, this one also has a subtle
meaning!

In C++, for ints, you can write

++i = k;

but not,

i++ = k;

This is because, i++ results in a Rvalue to which you can't assign.
Unlike i++, ++i results in a Lvalue to which you can assign which
is infact ( incremented ) i itself. Not that ++i = k; has a great
importance, but it is a fact that C++ has been designed that way.
I would be interested in knowing the reason. One reason is that
i++ = k; is not allowed is that it is just ambiguous.
but ++i = k; is not ambiguous.

A const in the return type is also required to disallow passing
the return value of i++ to a function taking non-const parameters
by reference. e.g. bar (Foo &); .... bar (f++); The return value of
f++ (which is f) is not supposed to last beyond the function call.

Therefore, in C++ these semantics of basic types should be followed by user-defined types.

Unless you declare pre-increment operator to return a reference to *this
it will not completely mimic the above basic type semantics. It is quite
important to preserve the basic type semantics when you overload these
opertors because the client and the compiler expect that you indeed preserved them.