From: "Tobias Schwinger" <tschwinger@neoscientists.org>
Terje Slettebø wrote:
I've dropped your has_plus_op version into the operator traits unit test, and it compiles and runs flawlessly on Intel C++ 7.1, MSVC 7.1 and g++ 3.2. As you said in an earlier posting: I guess I had to see it with my own eyes. ;)
Beware! It might be Intel (or EDG) is not 100% supported out of the box.
However it's a matter of seconds to find out and likely to be a matter of minutes to adjust it, if necessary.
See the "how to port" part in the "readme.txt".
The basic_test.cpp doesn't work fully on Intel C++ (only 10 of 2500 tests fail, though), and I'll see if I can fix it, using the instructions there.
I refined the 'is_enum' hack I posted (somewhere in this thread) until its behaviour was aequivalent to the Type Traits library as one of the first tests. It turned out to be 20 (msvc, 10 gcc, 4 bcc) times faster, so I expected some speedup.
Wow, nice. :)
But what I saw yesterday was exceeding all my expectations.
Mine, too. :)
I also see you use inheritance to guide implicit conversions. Clever. :)
Just saying 'integral' means "match whatever integral type" and is a weaker match than 'lvalue<integral>' or 'rvalue<integral>'. Using 'integral_or_enum' is an even weaker match than 'integral' but still stronger than 'object_lvalue', which matches stronger than 'object_lvalue' which in turn is a stronger match than 'object'....
Using multiple inheritance only, would make rule set development very hard and error-prone. This way it's possible to emphasize quite complex rules without running into ambiguity problems.
Right.
Using an extra argument for disambiguation should _only_ be required when things get extremely tricky, that is the rules _are_ in fact (sematically, that is) ambigous and need prioritization.
This check doesn't cost much - so it was reasonable to have it...
I'm wondering about the "two_way" part of the code, could you say what
name alludes to, and what code that refers to? Also, regarding this
I see. the part:
The namespace 'two_way' defines the result type for a rule set of a 'two way filter', having two result states 'filter' and 'pass'.
Ah, two outcomes. I was thinking two-way, as in testing that a == b and b == a, that sort of thing. :)
There could be a 'three way filter' with three states like "filter and return true", "filter and return false" and "let the delegate decide" for example or an 'n way filter' with a result type template to carry an integral value...
In some "macro-ized" form these could be made interchangable...
I understand.
Or, if we let ::boost::has_plus_op_local::has_plus_op_prefilter<T,U> act as mpl::bool_<>, itself (letting state_pass=true and state_filt=false):
I don't think it's a good idea (see below).
Nearly all dependecies are gone - I kept 'mpl::and_' (just because I was too lazy to change things which are likely to change again ;+) - actually we can get rid of this, too. ( For that matter it's probably a good idea to use these "bool_trait_(un)def" headers [boost/type_traits/detail], which seem much more portable than just inheriting from a "bool holder type").
I guess I have to be more precise:
The problem is that some compilers do not properly inherit type/template/static-const members. In this case the carrier classes need special care to interoperate nicely with mpl placeholders.
The Type Traits library addresses this problem with these def/undef multi-#include headers that define and undefine a set of macros to create the frontend class with all "workaround decorations" needed for the compiler in use. The '_impl' classes do not have to care about it and just publish a 'value' or 'type' member.
Ok.
That may be an idea. We could go through any remaining dependencies, and see if we can do any reasonable changes to reduce their dependencies, again (and possibly compilation time), and/or improve portability.
There are not too many dependencies left, are there ;+) ?
Nope. :) It's only mpl::and_, actually.
I'll contact you off-list for the way forward, but I'd be interested in using this technique in all of the operator/concept traits library (where it makes sense), or some other form of library for operator/concept checking.
Great !
It will need some refinement in terms of wrapping this into a fine modular design supportive to library development. Any suggestions are welcome, of course !
Indeed. We have a job to do. :) Regards, Terje