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

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2004-09-30 14:55:12

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

> 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.

I see.

> 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
the
> > name alludes to, and what code that refers to? Also, regarding this
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