"Thorsten Ottosen" <[EMAIL PROTECTED]> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
