25.6 Practical Considerations When Using the STL

I l @ ve RuBoard

The containers and related functions of the STL do a good job of making your life easier. However, because the STL is so flexible and powerful, it can sometimes be difficult to get things right. In this section we'll explore a few techniques that can make your life much easier.

25.6.1 Getting the Types Right

One of the big problems with using STL containers is remembering the types of the variables and parameters being used. It's very easy to use the wrong type. You'll encounter this problem with the STL more than with most other code in part due to the flexibility of the system coupled with the large number types used in the definition of containers and the functions that work on them.

One way to make things clearer is through the use of typedef statements. For example:

 typedef std::map<std::string, grades> class_roster; 

Definitions like this tend to cut down on the clutter because class_roster is much clearer (and a little shorter) than map<string, grades> . It also makes maintenance easier because the definition of your type is in one place.

We did not make extensive use of the typedef statement in this chapter because the purpose of the chapter is to teach you about the underlying STL templates. It would have been clearer (but not as instructive) if we had used them.

25.6.2 Error Messages

One of the problems with templates is that compiler parser technology is not yet up to speed when it comes to issuing error messages. The following example is one line of a multiline error message coming out of a broken program:

 classx.cpp:78: no matching function for call to `map< basic_string< char, string_ char_traits<  char>, __default_alloc_template< true, 0> >, vector< int, _  _default_ alloc_template< true, 0> >, less< basic_string< char, string_char_traits< char>, _  _ default_alloc_template< true, 0> > >, __default_alloc_template< true, 0> >::find (_  _ rb_tree_iterator< pair< const basic_string< char, string_char_traits< char>, _  _ default_alloc_template< true, 0> >, vector< int, _  _default_alloc_template< true, 0> >  >, pair< const basic_string< char, string_char_traits< char>, _  _default_alloc_ template< true, 0> >, vector< int, _  _default_alloc_template< true, 0> > > &, pair<  const basic_string< char, string_char_traits< char>, _  _default_alloc_template< true,  0> >, vector< int, __default_alloc_template< true, 0> > > *>,  _  _rb_tree_iterator<  pair< const basic_string< char, string_char_traits< char>, _  _default_alloc_template<  true, 0> >, vector< int, _  _default_alloc_template< true, 0> > >, pair< const basic_ string< char, string_char_traits< char>, _  _default_alloc_template< true, 0> >,  vector< int, _  _default_alloc_template< true, 0> > > &, pair< const basic_string<  char, string_char_traits< char>, _  _default_alloc_template< true, 0> >, vector< int, __ default_alloc_template< true, 0> > > *>,  map< basic_string< char, string_char_ traits< char>, __default_alloc_template< true, 0> >, vector< int, _  _default_alloc_ template< true, 0> >, less< basic_string< char, string_char_traits< char>, _  _default_ alloc_template< true, 0> > >, _  _default_alloc_template< true, 0> > &)' 

From this we can see that something went wrong on line 78, but it's difficult to tell what. (Turns out that this is a type-related problem.) Unfortunately, because of the clutter, it's next to impossible to tell what's wrong other than it's near line 78 and it has something to do with the STL.

The STL pushes the limits of C++ technology, and sometimes the limits push back.

I l @ ve RuBoard