Re: STL non virtual DTOR

Francis Glassborow wrote:


I beg to differ. Although it is true that implicit conversions can cause
problems, it is not quite clear whether public inheritance is to blame. One
can at least equally well argue that the function is ill-designed. Which of
those attitudes is more appropriate might just depend on the particular use
case.

The following makes some sense in the context of math programming. In the
example below, inheritance is used instead of a typedef to allow for
function signatures to differentiate between different kinds of vectors.
This is about the only case, where I use public inheritance from standard
containers. Note that it does _not_ introduce new data-fields. It just
acknowledges that not all vectors are equal, because they may have
different meanings: E.g., in the context of linear algebra it would be very
natural to add vectors element wise by using operator+. In the context of
languages over some alphabet, operator+ might naturally denote
concatenation. Thus, a math library might contain (presumably in different
headers):

  // [warning: code has not been touched by a compiler]

  template < typename T >
  struct lin_alg_vector : public std::vector<T> {
    // some constructors
  };

  template < typename T >
  lin_alg_vector<T> operator+ ( lin_alg_vector<T> const & lhs,
                                lin_alg_vector<T> const & rhs ) {
    assert( lhs.size() == rhs.size() );
    lin_alg_vector<T> result;
    result.reserve( lhs.size() );
    std::transform( lhs.begin(), lhs.end(),
                    rhs.begin(), rhs.end(),
                    std::back_inserter( result ),
                    std::plus<T>() );
    return ( result );
  }

  // some more

  template < typename T >
  struct word : public std::vector<T> {
    // some constructors
  };

  template < typename T >
  word<T> operator+ ( word<T> const & lhs,
                      word<T> const & rhs ) {
    word<T> result ( lhs );
    result.insert( result.end(), rhs.begin(), rhs.end() );
    return ( result );
  }

This way, two meanings of operator+ can peacefully coexist. The right one is
chosen depending on the meaning of the operands.

Now suppose we had functions like this:

  template < typename T >
  std::ostream & print_vector( std::ostream & ostr,
                               std::vector<T> const & the_vector ) {
    ostr << "[ ";
    std::copy( the_vector.begin(), the_vector.end(),
               std::ostream_iterator<T>( osrt, " " ) );
    ostr << "]";
    return ( ostr );
  }

or

  template < typename T >
  void reverse_in_place ( std::vector<T> & the_vector ) {
    typename std::vector<T>::size_type low_index = 0;
    typename std::vector<T>::size_type high_index = the_vector.size();
    while ( low_index < high_index ) {
      -- high_index;
      swap( the_vector[low_index], the_vector[high_index] );
      ++ low_index;
    }
  }

Then, there is no problem. Those functions will work with lin_alg_vector and
word just as expected.

However, a function like

  template < typename T >
  vector<T> reverse_order ( std::vector<T> const & the_vector ) {
    std::vector<T> result ( the_vector.rbegin(), the_vector.rend() );
    return ( result );
  }

would be slightly off the mark: if we feed in a word, we don't get a word
back. However, it is not clear who is at fault, the designer of word<T> or
the designer of reverse_order().

As far as I can see, there are at least three possible reactions to this
mismatch phenomenon:

a) Put a constructor from vector<T> into the class word<T>. Then the
function reverse_order can be used with words via

  word<T> reversed_word ( reverse_order( the_word ) );

and similar constructions. This will work in almost all cases where public
inheritance is used instead of a typedef as illustrated above.

b) Shun public inheritance.

c) Redesign the function reverse_order to something like this:

   template < typename Container >
   Container reverse_order ( Container const & the_cont,
                             enable_if< is_sequence<Container>::value >::...
     Container result ( the_cont.rbegin(), the_cont.rend() );
   }

This way, the function will work with word and lin_alg_vector just fine.

I think, it is far from clear, that (b) is the appropriate reaction in all
cases. Whether using tricks like above creates problems, I think, depends
very much on the code-base, the local coding style, and the problem domain.

Best

Kai-Uwe Bux

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]