Chapter 20: General Utilities

Chapter 20 deals with utility classes and functions, such as the oft-debated auto_ptr<>.


Contents


auto_ptr is not omnipotent

I'm not going to try and explain all of the fun and delicious things that can happen with misuse of the auto_ptr class template (called AP here), nor am I going to try and teach you how to use AP safely in the presence of copying. The AP class is a really nifty idea for a smart pointer, but it is one of the dumbest of all the smart pointers -- and that's fine.

AP is not meant to be a supersmart solution to all resource leaks everywhere. Neither is it meant to be an effective form of garbage collection (although it can help, a little bit). And it can not be used for arrays!

AP is meant to prevent nasty leaks in the presence of exceptions. That's all. This code is AP-friendly:

    // not a recommend naming scheme, but good for web-based FAQs
    typedef std::auto_ptr<MyClass>  APMC;

    extern function_taking_MyClass_pointer (MyClass*);
    extern some_throwable_function ();

    void func (int data)
    {
        APMC  ap (new MyClass(data));

        some_throwable_function();   // this will throw an exception

        function_taking_MyClass_pointer (ap.get());
    }
      
When an exception gets thrown, the instance of MyClass that's been created on the heap will be delete'd as the stack is unwound past func().

Changing that code as follows is not AP-friendly:

        APMC  ap (new MyClass[22]);
      
You will get the same problems as you would without the use of AP:
        char*  array = new char[10];       // array new...
        ...
        delete array;                      // ...but single-object delete
      

AP cannot tell whether the pointer you've passed at creation points to one or many things. If it points to many things, you are about to die. AP is trivial to write, however, so you could write your own auto_array_ptr for that situation (in fact, this has been done many times; check the newsgroups, Usenet, Boost, etc).

Return to top of page or to the FAQ.


Automatically-generated operators

Many programs (for that matter, many of the Standard algorithms and containers) require that you write comparison operators for your classes, like operator>=. As any mathmatician will tell you, once you have defined equality and ordering, all of the other comparisons are easily defined in terms of those two.

The Committee agrees. So, once you have written operator== and operator< for your class (whether they are global or member functions is up to you), you can have the compiler do the grunt-work of generating the rest:

    #include <header_with_my_op==_and_op<_defined>
    #include <utility>
    using std::rel_ops;     // note the nested namespace!

    ...
    if ((obj1 != obj2) || (obj3 >= obj4))  foo();
      

Return to top of page or to the FAQ.


Functors

If you don't know what functors are, you're not alone. Many people get slightly the wrong idea. In the interest of not reinventing the wheel, we will refer you to the introduction to the functor concept written by SGI as part of their STL, in their http://www.sgi.com/Technology/STL/functors.html.

Return to top of page or to the FAQ.


Pairs

The pair<T1,T2> is a simple and handy way to carry around a pair of objects. One is of type T1, and another of type T2; they may be the same type, but you don't get anything extra if they are. The two members can be accessed directly, as .first and .second.

Construction is simple. The default ctor initializes each member with its respective default ctor. The other simple ctor,

    pair (const T1& x, const T2& y);
      
does what you think it does, first getting x and second getting y.

There is a copy constructor, but it requires that your compiler handle member function templates:

    template <class U, class V> pain (const pair<U,V>& p);
      
The compiler will convert as necessary from U to T1 and from V to T2 in order to perform the respective initializations.

The comparison operators are done for you. Equality of two pair<T1,T2>s is defined as both first members comparing equal and both second members comparing equal; this simply delegates responsibility to the respective operator== functions (for types like MyClass) or builtin comparisons (for types like int, char, etc).

The less-than operator is a bit odd the first time you see it. It is defined as evaluating to:

    x.first  <  y.first  ||
        ( !(y.first  <  x.first)  &&  x.second  <  y.second )
      
The other operators are not defined using the rel_ops functions above, but their semantics are the same.

Finally, there is a template function called make_pair that takes two references-to-const objects and returns an instance of a pair instantiated on their respective types:

    pair<int,MyClass> p = make_pair(4,myobject);
      

Return to top of page or to the FAQ.


Comments and suggestions are welcome, and may be sent to Phil Edwards or Gabriel Dos Reis.
$Id: howto.html,v 1.5 2000/03/20 22:16:21 pme Exp $