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-19 09:03:01

>From: "Tobias Schwinger" <tschwinger_at_[hidden]>

By the way, nice idea with the member function pointer traits proposal (in
the "[type_traits] "member_function_pointer_traits"" thread). The
operator/concept traits library contains a similar, but orthogonal
component, has_member_function<> (in
type_traits_ext/has_member_function.hpp). E.g., to detect a member function
with the signature "void A::swap(A &)", one can use:

has_member_function<A, has_member_swap, void, A &>::value

The parameters are: Class (A), class template for member detection
("has_member_swap", defined using macro in has_member.hpp header), return
type (void), any parameters (A &).

I think the components are orthogonal, because the above concerns member
function _detection_, while your traits are concerned with whether or not a
type T is a member function pointer, and if it is, what are the properties
of the member function. In other words, if you do
is_member_function_pointer<&A::swap>, and A doesn't have a swap() member,
you'll get an error, rather than false.

I think your proposal would nicely complement the existing Boost type
traits.

> I had a look at your library proposal today.
> Looks like a very valuable tool for everyone into generic programming.

Thanks. :)

> It seems quite easy to add new concepts, which I think is one of the
> most important things (the has_member family looks very promising).

I'll expand the docs for that section, as well, as mentioned in a recent
posting. I agree that this issue is one of the most important ones.

> I was able to build the operator_traits test with GCC 3.2.3 mingw (about
> 20 minutes PIII,600MHz,512MB RAM - 100% passed - guess I just had to see
> it with my own eyes ;+).

Ah. :)

The std_concept_traits_test.cpp and boost_mpl_concept_traits_test.cpp
doesn't work fully on g++ 3.2, yet, but I intend to work on that.

> It failed to build on MSVC 13.10.3077 and Borland 5.4.6 (I kept the
> output, in case you are interested).

Strange, as it works on MSVC 12.00.8804, which is the one I've tested it on
(in addition to Intel C++ 7.1 and g++ 3.2).

I don't think I have any hope of getting it to work on Borland 5.x (or 6.x,
for that matter). I haven't tested it there, and my aim has been Intel C++
7.1 (maybe 6.0 and up, but I've used 7.1 for testing, so far), MSVC 7.1 and
g++ 3.2 (and later for all). Of course, it would be nice if it was possible
to get it to work on other compilers, as well.

Sure, I'd appreciate it if you could send the compiler output to me.

> It might be possible to put the prefiltering stage of the operator
> traits into sort of table based form, making it easier to maintain,
> eliminating a lot of inclusion dependencies and template instantiations
> and covering tests for builtin operators (if they should be detected,
> that is) as well.

Interesting idea... Something to remove that pre-filtering "boiler plate"
code with something less taylor-made for each trait could certainly be
useful, and potentially speed up the compilation, as well as removing a lot
of inclusion dependencies, yes. However, I haven't been able to come up with
anything like that, so far.

> This can probably be done with a technique in some way similar to the
> one applied to the operator checking itself - defining a rule set of
> overloaded functions to match the exclusions. Classes with a converting
> copy constructor can be used to categorize the types matched by the
> rules. The rule sets for different operator categories could be put into
> nested namespaces so inner categories could 'inherit' the rules of the
> outter ones.
> 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).

Great. :) I'll check it out.

Regards,

Terje