------- Additional Comments From adah at netstd dot com 2005-08-12 08:52
-------
I am glad it is again normal discussions.
(In reply to comment #93)
> Subject: Re: can't compile self defined void distance(std::vector<T>,
std::vector<T>)
> "adah at netstd dot com" <[EMAIL PROTECTED]> writes:
> | Herb Sutter's opinion (N1792) is a little different. He thinks that
> | ADL should not work in the OP's example, because distance is simply
> | not an `interface' of std::vector (technically, instead of from
> | human eyes). But it is also self-consistent.
> All those are assertions, little evidence. Notice that what is
> considered an "interface" varies from one individual to another
> individual. And we just don't have a definition for it, so you're
> still using your "human eyes" definition, i.e. projection of your own
> wishes.
By `technical' I meant algorithmically recognizable.
> I was in the room when ADL was discussed at the last meeting in Norway
> -- and indeed, I was part of the people who fiercely encouraged Herb
> to bring forward "his modest proposal" (and that does not mean I agree
> with every word contained in the proposal, but my interest in getting
> the issue addressed). At that time, I was presenting possible ways
> the concept proposal may reduce the uncontrolled power of ADL. I have
> suggested that you give a try to the exercise of "name lookup". That
> suggestion still holds. Untill, you have done so it is almost certain
> then you will completely miss its the depth and ramifications. It is
> no Herb's opinion against mine. It is a matter of precisely and
> consistently defining the rules so that the most common cases are
> gotten right. No, it is not GCC's job. Furthermore, if you want to
> eliminate ADL effects; you have to break existing codes and ban ADL.
> Herb's suggestion already breaks some existing reasonable codes -- and he
> acknowledges that. You can argue from your notion of engineering and
> intuition, but that is all. And you have to have everbody else's
> notion of engineering and intuition intersect with your before moving.
> Once, the rules get written and ADL isstill supported, one will always
> find cases that is considered either "intuitively and obviously
> correct" or "intuitively and obviously wrong". The reason is very
> simple: ADL was *designed on purpose* to make overload set across separate
> scopes -- something which did not exist before. Once you're given
> that, all bets are off. The only thing you can do is to work to get
> what you consider to be the most common cases "intuitively and
> obviously right". And live with the rest.
These statements I agree. You enlightened me that there are more than one way
to go to make the OP's code work, and Wolfgang showed that my opinion might be
practically difficult to implement. Thanks for that.
Please note I mentioned Herb's proposal only to reply to Wolfgang. I never
said, not even hinted, that it should be implemented in GCC now.
> [...]
> | it is safer to have a better diagnostice message *now*.
> you get a better diagnostic when you can precisely spell out what
> alternate rules can be or give a precise consistent algorithms. You
> haven't so far. Just arguing.
Has a user to be a compiler writer to give enhancement suggestions, I wonder?
Though you may still think it is not an algorithm, I am trying again (in Gene
Bushuyev's way):
Function overload_resolution(function_name, arguments,
current_namespace, function_namespace)
{
set<Function> overload_set;
set<Function> failed_set;
for (Function function = parse_tree.functions.begin();
function != parse_tree.functions.end(); ++function)
if (function->name == function_name
&& function->check_lookup_rules(current_namespace, function_namespace))
{
if (function->is_a_template())
{
try
{
if (!function->is_explicitly_specialized())
template_arguments = function
->deduce_template_arguments(arguments); // 14.8.2
instance = function->instantiate(template_arguments) // 14.7.1
overload_set.insert(instance); // 14.8.3/1
}
catch (const SubstitutionFailure&)
{
failed_set.insert(*function); // only for reporting purposes
// do nothing with this candidate according to 14.8.3/1
}
catch (InstantiationFailure& e)
{
e.add_instantiation_failure_point(*function);
if (is_unqualified(function_namespace)
&& current_namespace != namespace_of(*function))
e.add_diagnositics(
"Instantiation failed on a result from"
" argument-dependent lookup: Use a scope"
" modifier like `::' if it is not what you"
" want");
throw e;
}
}
else
overload_set.insert(*function);
}
set<Function> matched_set = overload_set.find_best_viable_function();
if (matched_set.empty())
throw no_match_error(failed_set); // just a hint for user - not required
if (matched_set.size() > 1)
throw many_match_error(matched_set);
// don't instantiate templates unless necessary 14.7.1/9
if (matched_function.is_a_templÂate_instance())
compiler.instantiated_functionÂ_set.insert(matched_function);
return matched_function;
}
> -- Gaby
Yongwei
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
