Quote:Original post by Amnesiac5
I am trying to use the constraint to limit the instantiation of the supports_XYZ template to [2] but, regardless of the type, [1] is always instantiated (both b1 and b2 are set to false).
The article does something clearly different from your code: template instantiation fails controllably thanks to an artificial dependence from a typedef that the "function enabler" can be made to contain or not.
Boolean constants like yours can be used to choose between the disabler and the enabler, but there are neither if statements nor boolean template parameters in your code.
Defining supports_XYZ<must_have_XYZ<T> > makes very little sense if you don't actually instantiate any must_have_XYZ<> (e.g. must_have_XYZ<Pt>).
The concern about not knowing the class name is, I'm afraid, absurd: if you don't know what classes posterity will try to use with the templates you are writing now, you cannot tell what template specializations will be needed (and you aren't even certain you'll need to mess with overloading).
In the specific case of your example, it's both hard to imagine how constraints() might be adapted to fundamentally different point representations and easy to see that it should really operate on a decently explicit point interface.
If the template function referred to accessor methods for the three coordinates you could make simple and efficient adapters for different point-like classes rather than unnecessarily assuming that point-like classes have public fields x,y and z.