20.3. Logical Shims

Definition: Logical Shims Logical shims are a refinement of attribute shims in that they report on the state of an instance to which they are applied. The names of logical shims take the form of an interrogative coupled with the particular attribute or state being queried. Examples would be is_open, has_element, is_null.

An obvious, and widely compatible, logical shim is is_empty(), which generalizes the accessing of state on any container type (for which it has been defined).

In my opinion, the authors of the standard library made a mistake in selecting empty() for the name of methods on various types which answer the question, "Is this instance empty?" as opposed to those effecting the imperative "Make this instance empty!" Not only is this not natural, it is inconsistent, both with other elements of the standard library—erase() is an imperative—but also with extant libraries, where it is more common to see IsEmpty() or is_empty().

Not one to sit on a problem, I quickly gave life to the is_empty()logical shim. Some definitions:

Listing 20.3.

template <typename C>


bool is_empty(C const &c)


{


  return c.empty();


}


bool is_empty(CString const &s)


{


  return s.IsEmpty();


}


bool is_empty(comstl::interface_ptr const &p)


{


  return NULL == p.get_interface_ptr();


}

Note that because of the standardized nature, and the large and increasingly established role of the standard library, the is_empty() shim general case—the second one in the list above—is defined in anticipation of its being applied to the standard library containers. While this borders on the presumptuous, and makes me a little nervous, the argument to the shim function is const, so unless you have encountered a class with an empty() method that is const but yet has modifying semantics, applying the general case should be safe. Bear it in mind though, there is no limit to the perversity of the code that people will dream up (see Appendix B).