Re: [boost] Re: Constrained genericity at last? (any interest in an operator traits/concept traits library?)

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2004-09-21 17:36:47

>From: "Tobias Schwinger"

> Terje Slettebø wrote:
> >>From: "Terje Slettebø"
> >
> >>>From: "Tobias Schwinger"
> >>
> >>>I attached some experimental source code for the prefiltering of an
> >>>operator+ check to clearify the basic idea (compiles with GCC and MSVC
> >>>and CVS version of boost).
> >>
> >>It works indeed with GCC and MSVC, but Intel C++ 7.1 had some serious
> >>problems with it. The following is one of several of the same kind of
>
> first of all thanks for your time and for your corrections.
>
> However, I still think there is nothing wrong with the basic idea, just
> with my sloppy example implementation of it.

By all means, like I said in the posting before it, I find it an interesting
idea, and was just as "disappointed" as you to find out that it might not be
possible to do it that way, and if there's better way to do the
pre-filtering than the "metaprogramming boilerplate", then I'm all for it.

> Refinement of the example code:
> -------------------------------

<snip>

Great work! :) This actually works, also on Intel C++/Comeau C++. It's good
that you didn't give up on the first try (not that I expected you to. :) ).

> Problem discussion:
> -------------------
>
> > Another problem with this approach can be demonstrated by listing the
cases
> > that are checked by the operator+ detection:
> >
> > - Both types being arithmetic or enum, or
>
> I renamed the type category 'integral' to 'integral_or_enum' because of
> 7.2-8 (enum), 4.5-2 (integral promotion).

Good point. What we are looking for is things that could be used in a
certain context, e.g. "a + b". This means that not only e.g. arithmetic
types match, but also something convertible to them, as well as reference to
them.

> > - One is array and the other is integral or enum, or
>
> I renamed the type category 'pointer' to 'integral_or_array' because of
> 13.3.3.1.1 (overloading - standard conversion sequences) Tab. 9.

As long as it passes the tests... :) I'll study this more carefully. :) I
look (hopefully) forward to a complete code example for has_plus_op<> using
this technique, if you could have made something like that.

> If there is a need to distiguish between (object) pointer and array this
> needs extra care (see below), sure. However, has_plus_op applies these
> tests disjunctively.
>
> > - Either is class, and the other is anything but void
>
> A match defines an exclusion - no match means "pass the filter" - and
> this would correctly happen in this case.
>
> > Even if we found a way to give a numerical code or something to each
> > fundamental type (typical typeof-implementation), there's still enum, so
we
> > need some kind of is_enum-detection (which would likely require the
Boost
> > one). The same goes for detecting class or union. We also need a way to
> > express the above conditions. I haven't found a shorter way of
specifying
> > this, than the current has_plus_op<> definition
> > (operator_traits/has_plus_op.hpp).
>
> Can't see an "is_enum" - only "is_enum_or_integral" and this is much
easier.

True... Good thinking. :) (So it was useful to refactor those tests (like
enum-or-integral) into sub-components, after all - it made what being tested
for easier to see. :) It might otherwise have got lost in a sea of syntactic
noise).

> Can't see any distinction between class and union in has_plus_op.hpp,
> either.

True, again...

> The strenght of the overload approach lies in the natural way of
> grouping types - can't see what separation of integral types should help.
>
> I'm not sure I get your point.

I think you got it - that the previous example didn't compile on some
compilers, and that I wondered if it was possible to cover the same cases
better - and I think you have convincingly addressed it. :)

> Am I making any naive assumptions here ? Am I misreading anything ?
>
> Please, correct me if I'm wrong !

No, I think you're right on. :)

Thanks for your very thorough investigation into this. I'll consider your
following points carefully. In the mean time, as you suggested in an email,
if you could have made this into a polished boostified version, that would
have been great. As a proof-of-concept (no pun intended. :) ), as mentioned,
maybe you could have written a has_plus_op<> replacement using this
technique, which passes the tests, since has_plus_op<> contains a reasonable
amount of "boilerplate", so it could be useful to test with.

This is remniscent of when I worked on an improved version of lexical_cast a
while ago (to support different character types, etc.), and had long if-else
switch-on-type chains, and Kevlin Henney instead found a way to do it with
much simpler code (which is the current version of lexical_cast).

Regards,

Terje