Re: [boost] container algorithms almost complete

From: Gabriel Dos Reis (gdr_at_[hidden])
Date: 2003-03-02 05:36:14

"Thorsten Ottosen" <nesotto_at_[hidden]> writes:

| 4. The code implement poor mans partial specialization to enable the
| container_traits to work with buggy compilers; so far so good; however,
|     many compilers cannot even do partial ordering of function templates
| which is a real pain in the ****. I know the workaround might be
|     to  say
| 
|     template< typename C >
|     inline typename
|     container_traits<C>::iterator
|     begin( C c )
|     {
|         return container_traits<C>::function_t::begin( c );
|     }
| 
| instead of
| 
|     template< typename C >
|     inline typename
|     container_traits<C>::iterator
|     begin( C& c )
|     {
|         return container_traits<C>::function_t::begin( c );
|     }
| 
|     template< typename C >
|     inline typename
|     container_traits<C>::const_iterator
|     begin( const C& c )
|     {
|         return container_traits<C>::function_t::begin( c );
|     }
| 
| but C can be a huge STL container. Can we assume compilers will inline code
| and not copy anything?

I don't think that assumption may be valid for major compilers out there.
 

Irrespective of pessimization issues, there is a definitve semantics
avantage of the latter over the former:  It works with native "C"
arrays while the former does not.  That is a decisive argument to have
begin/end non-member functions.

-- Gaby