From: "Tobias Schwinger" <tschwinger@neoscientists.org>
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