Boost logo

Boost :

Subject: Re: [boost] [guidelines] why template errors suck
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2010-09-28 15:36:30


On Tue, Sep 28, 2010 at 1:48 PM, joel falcou <joel.falcou_at_[hidden]> wrote:
> On 28/09/10 19:37, David Abrahams wrote:
>>
>> This BehaveAsPair thing doesn't identify any real abstraction.  I
>> promise you're not going to come across any uses for BehaveAsPair
>> other than in solving the exact implementation problem you're
>> attacking.
>>
>
> I see
>>
>> In short, it lacks "truthiness." :-)
>>
>
> Agreed
>>
>> Was there something unsatisfying about the solution I posted in
>> http://permalink.gmane.org/gmane.comp.lib.boost.devel/209012 ?
>>
>
> Nope, I just missed it.

Oh wait! I think I have another example that's more truthy. :) I'll
use Boost.ConceptCheck to flesh it out. Let's define the concept of an
AdditivePair to represent the arguments to binary addition. To model
the concept a type needs to support first(x), second(x) and add(x) for
an object x where all three functions have integer values. So, the
(simplest) concept checking class would be:

template <class T>
struct AdditivePair {
    BOOST_CONCEPT_USAGE(AdditivePair)
    {
        int a = first(x);
        int b = second(x);
        int c = add(x);
    }
    T x;
};

We can now write Eric's function using concept requirements.

template<class T>
BOOST_CONCEPT_REQUIRES(
    ((AdditivePair<T>)),
    (int)
) sum_ints( T const & t )
{
    return add( t );
}

We can now adapt std::pair<int,int> to model the AdditivePair concept.

int first(std::pair<int,int> x) { return x.first; }
int second(std::pair<int,int> x) { return x.second; }
int add(std::pair<int,int> x) { return first(x) + second(x); }

And we can also adapt int to model the AdditivePair concept; i.e. int
is an additive pair where the second member is 0.

int first(int x) { return x; }
int second(int x) { return 0; }
int add(int x) { return x; }

That seems pretty natural to me.

Daniel Walker


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