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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
