On 09/03/2013 11:01 AM, Andrew Sutton wrote:
Attached is a patch for constrained class templates. It's the 3rd time I've sent it.
Please feel free to ping me if you're waiting for a patch review; once a week is not too much.
1. Type constraints are checked on lookup rather than instantiation.
How is this different from function template constraints? Is this just a difference in internal function name (instantiate_template vs lookup_template_class)?
+// Returns the type of a template specialization only if that +// specializaiton needs to defined. Otherwise (e.g., if the type has
specialization
+ // Do the constraints match the most general template? Note that + // the absence of constraints will also match. + if (equivalent_constraints (cur_constr, DECL_CONSTRAINTS (tmpl)))
If absence matches, I think the name "equivalent" is misleading. But the implementation seems to require subsumes in both directions. What's up here?
+ // Find the template parameter list at the a depth appropriate to + // the scope we're trying to enter. + tree parms = current_template_parms; + int depth = template_class_depth (type); + for (int n = processing_template_decl; n > depth && parms; --n) + parms = TREE_CHAIN (parms);
If you're going to use this function from lookup_template_class_1, it can't use current_template_*, since those are parser state which might be something completely unrelated when we get here during instantiation.
+ return resolve_template_scope(gen_tmpl, template_type);
Space before (.
+ // Diaagnose constraints here since they are not diagnosed
Extra 'a'.
+ // If not, it is equivalent to have failed to compute the binding.
"to having failed" Jason
