Boost logo

Boost :

Subject: Re: [boost] [contract] concept error messages
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2012-10-08 08:57:31


> >> >> Lots of reasons, but mostly it clearly delineates what is required
> >> >> from what is returned.
> >> >>
> >> >
> >> > I agree with you that requires is important, particularly for
> >> concept-based
> >> > overloads where one overload has more refined concepts than another
> >>
> >> Can you guys give me an example of this?
> >
> >
> > std::advance, even in the C++98 standard library, is overloaded
> differently
> > for input iterators than it is from bidirectional and random access
> > iterators. With random access iterators, advance operates in constant
> time.
> > With input iterators, advance operates linearly.
>
> Sure, I understand:
>
> template< class I, class Distance >
> requries InputIterator<I>
> void advance( I& it, Distance n ) { /* linear complexity... */ }
>
> template< class I, class Distance >
> requries BidirectionalIterator<I>
> void advance( I& it, Distance n ) { /* ... */ }
>
> template< class I, class Distance >
> requries RandomAccessIterator<I>
> void advance( I& it, Distance n ) { /* constant complexity... */ }
>
> I agree, this type of overloading is a reason for having requires,
> enable_if will not suffice. Is there any other reason?
>

One (perhaps minor) reason is that enable_if is an ugly workaround rather
than a decent solution for the problem. enable_if is a class template. WHen
using it in declaring your function template you have to choose how you
want to "uglify" your declaration:
(1) Uglify the return type?
(2) Add a useless function argument?
(3) Add a useless template parameter?

"requires" on the other hand gives you another section in the declaration
that does not interfere with function arguments or return value. This is
only a problem of enable_if. If we have "mini-concepts" in form of
static-if, the argument above would not hold anymore.

Regards,
&rzej


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk