Re: [boost] is_single_element?

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2002-05-17 04:37:39

Thomas Witt wrote:
> 
> On Friday 17 May 2002 10:08, Daniel Frey wrote:
> > I have to read this book. :-( If this is true, you are absolutely right
> > to use 'boost::next()'. But why doesn't it work? The only thing I could
> > think of is, that 'begin()' returns a 'const iterator&' or something
> > like that. Is this allowed? Or is there any other reason?
> 
> The basic problem is, that you are not allowed to modify temporaries of
> built-in types. So if iterator is just a typedef for int*, ++cont.begin()
> will not compile.

Thanks for the clarification. The next question is, whether we want to
enhance is_single_element() for UDT's, probably something like this:

template< typename Container >
bool is_single_element( const Container& container )
{
   // Resolved at compile-time:
   if( ::boost::is_pointer< Container::iterator >::value )
     return !container.empty() &&
       boost::next( container.begin() ) == container.end();
   else
     return !container.empty() &&
       ++container.begin() == container.end();
}

But I doubt it would make a significant difference that makes it worth
to write such a "complicate" version.

While writing the above, I wonder if it would make sense to have
convenience-functions for is_pointer, etc.? Like

namespace boost
{
   // The name of the function is ugly... :)
   template< typename T >
   bool is_pointer_( const T& )
   {
      return is_pointer< T >::value;
   }
}

Comments?

Regards, Daniel

--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de