Re: [boost] Interested? Simplify usage of std::rel_ops

From: Alberto Ganesh Barbati (abarbati_at_[hidden])
Date: 2006-07-16 09:39:07

Christopher Eltschka ha scritto:
> 
> Ah, sorry, although I looked into boost before writing the mail, I
> somehow missed that, despite its obvious name. However I see that the
> boost version forces you to explicitly repeat the class name, i.e. you
> have to write
> 
> class X: boost::operators<X> { ... };
> 
> instead of just
> 
> class X: boost::operators { ... };
> 
> Is there any specific reason to do so? After all, it seems to work well
> without that extra burden. Any specific example where I could get
> problems with my version?

The template parameter is needed because boost::operator actually
provides an in-class implementation of the required operators, instead
of just making them visible through ADL as in your approach (which is
indeed quite clever, if I can say so). I can see the following
differences between the two approaches:

1) granularity: well, that's not really an issue, because you could
easily elaborate your approach to avoid defining unwanted operators (for
example: dont' define operator> if it's not needed)

2) with your approach you can't define operators which must be member
functions, that is operator[] and operator-> (that's not too bad, anyway)

3) type deduction rules are different, because boost operators are
regular functions, while your operators are function templates. Consider
this:

struct base
  : /* EITHER boost::equality_comparable<base> OR rel::ops HERE */
{
  // ...
  friend bool operator==(const base&, const base&);
};

struct derived : base
{
};

void test()
{
  base b1, b2;
  derived d1, d2;
  b1 != b2; // ok in both approaches
  d1 != d2; // ok in both approaches
  b1 != d1; // ok with boost: d1 is implicitly converted to const base&
            // illegal with rel::ops: can't deduce template argument
}

This is not terribly bad, but it's enough to make me accept the
annoyance of duplicating the class name. But that's just my opinion ;)

Also you have to consider there are still a lot of compilers around that
don't support ADL correctly, so, despite the formal correctness, there
might be some hidden portability problems.

Ganesh