[boost] Non-standard feature proposed in help text of operators library??

From: Daniel Spangenberg (dsp_at_[hidden])
Date: 2003-07-22 07:07:51

Hello Boosters,

after some experiences I got during a the developement of a BitMaskOps
class template (as an extension of operators for enums), which can be
found on

http://groups.google.de/groups?q=BitMaskOps&hl=de&lr=&ie=UTF-8&selm=3F165079.A0CE8BAE%40bdal.de&rnum=1

I assume now, that the section "Separate, Explicit Instantiation" as
presented
on the Boost operators help page

http://www.boost.org/libs/utility/operators.htm#explicit_instantiation

proposes a technique which (undocumentedly) bases on non-portable
behaviour
of several non-compliant compilers.

Please correct me, if I am wrong, but I assume, that the usual usage of
these very
useful template classes, like less_than_comparable and others, via
inheritance bases
on the Barton-Nackman trick combined with the Curiously Recurring
Template Pattern
(CRTP). Provided, that this is true, I assume, that the proposed
workaround for
compilers with expensive multiple inheritance implementations should not
work on
compliant compilers, because of a violation of 14.6.5/p. 2:

"As with nontemplate classes, the names of namespace scope friend
functions of a class template specialization are not visible during an
ordinary lookup unless explicitly declared at namespace scope (11.4).
Such names may be found under the rules for associated classes (3.4.2)."

In a first statement, Daveed Vandevoorde also seems to assume, that the
interpretation is
correct, that "[..]X<T> is not in general associated with T [..]" (My
truncated quote from
Daveeds answer).

Concretly said, the example:

class myclass{
   //
};

template struct less_than_comparable<myclass>;

should not work, because less_than_comparable<myclass> is not associated

with myclass.

Of course this association is provided in case of the canonical usage
via inheritance, but this seems not to apply here.

I hope, that I do not spread baseless rumors with this report and I
would be
pleased about any clarification concerning the real situation.

In case of correctness of this hypothese I would propose to add to the
corresponding text, that this technique bases on non-standard features
of
several compilers, thats it.

Btw: Does anyone have an idea to realize the same effect? As a said, I
stumbled
about this problem during my trials to realize on-demand available
operators
for enum and I did not find any solution. Barton-Nackman would do the
trick,
but I cannot inherit from my enums (Requirement is, that they are
**real** enums,
not classes simulating enums, because I want to take advantage of the
enum literals
and typesavity)

Greetings from Bremen,

Daniel