Re: [boost] [guidelines] why template errors suck

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

On Tue, Sep 28, 2010 at 12:44 PM, joel falcou <joel.falcou_at_[hidden]> wrote:
> On 28/09/10 17:10, Stewart, Robert wrote:
>>
>> '...one can write a sum_int_impl using this Concept...'
>>
>>    "Yes and"
>>
>> '...is it too hacky?'
>>
>>    "yes"
>>
>
> Guess I embarassed myself then *blushes*
> Why is it hacky ? The fact that second(int) return 0 ?
> Then can't we say that second(int) is ill-formed and have
> HasFirstComponent and HasSecondComponent and thus making the
> std::pair sum require AND relation ?
>
> (or am I still guessing it wrong ?)

Actually, I don't think it's a bad hack. Formally, summation in the
integers is a _binary_ relation; i.e. a relation from the cartesian
product Z^2 into Z. I would write Eric's functions using something
like...

int sum_int(int x, int y = 0) { return x + y; }

int sum_int(pair<int,int> p) { return sum(first(p), second(p)); }

To "conceptually" describe the argument(s) of sum_int, you need an
abstraction to represent members of Z^2. But in this case I'm not sure
there's a satisfying way to do that, because an ordered pair from Z^2
can be encoded in C++ as a single function parameter (a pair) or by
two function parameters... To me this seems related to a persistent
kink in mathematical notation. Let f : Z^2 -> Z. But we write f(x, y)
for <x,y> in Z^2, instead of the more formal f(<x,y>).

Also, for those who haven't read it, I would recommend chapter 2 of
Jeremy Siek's book The Boost Graph Library as an introduction to
concepts. It's a great piece of expository writing and helped me a
lot.

Daniel Walker