> > Thanks Dave;'
> >
> > Acerbic comments below.
>
> >> Isn't that exactly what the
> compiler IS doing, as
> >> indicated by "candidates are ... "?
> >
> > I don't think so. [ ... ] A clear
> message that arg<n> is wrong I think
> > is a better approach.
>
> But maybe arg<n> is right and it's something
> else that is wrong?
>
> >> It's not always possible for the
> compiler to do
> >> that.
>
>
> Nonono; I didn't mean to impugn anything you're
> doing, just trying to point
> out that it's not easy.
Impugn away. I am terribly thin-skinned and the barbs wake me up.
>
> Should the compiler always assume the function prototypes
> are correct and the
> choice of argument in the function call is wrong? It
> occurs to me that that
> might be a good rule of thumb for system headers, but
> probably not for headers
> within the user's application.
In this case the compiler detected an error and provided the correct
answer, but the answer lacked clarity for (really) a non-compiler
writer. Before I say another word (let's see you deal with that one),
if we look at the statement you have made then, I think, we are left
nowhere. In particular your caveat on when my suggested reporting
algorithm is inapplicable. To tear into the statement and bring you to
a proper state of receptiveness, in absurdum you are saying that even
though the compiler has detected an error and reported (what it thinks)
is an error, the compiler is unable to determine that the error occurred
in arg<n> - the nub of the suggested diagnostic message. I would say
that given the existing compiler message, if the compiler can't draw this
conclusion then the message is wrong. I would then say if the compiler
is clever enough to provide a function template as a candidate for
correcting the fault, then the compiler has all of the information
needed to do a comparison, argument by argument, to determine which
argument(s) are at fault, and can do this recursively (or iteratively
if you're going to get picky) with all candidate function solutions.
I believe your caveat is then moot. The existing diagnostic message
should be sufficient to allow the compiler to perform the analysis
necessary to provide a more 'user friendly' (according to 'art') fault
indication.
I would go further by saying that (especially) any time the compiler
is able to provide a candidate solution then the compiler should be
able to analyze it's own solution against the fault to provide a more
meaningful message.
I assert that in those cases where compiler fault analysis fails, then
under the stated conditions above the compiler has provided a faulty
initial analysis of the problem and that is a 'bug'.
Conventional wisdom, in my youth when the Sun shone brighter, was
that error analysis was O(n**3), so I acknowledge that this is not
easy. My argument is that the compiler has already done the analysis
and just fails on the messaging.
I believe that it is possible to generalize the analysis tool and
avoid case-by-case special purpose code for each 'nasty'. If not
completely for all cases and forever, at least for enough cases to
make the effort worthwhile. My reasoning is that most semnatic errors
fall into broad categories, call it a 'failure in semantics', and
these broad categories can be leveraged into a generic toolset. The
pragmatic difficulty is that that existing diagnostic messages would
have to be reworked into a standardized framework, and I view this
as a hard problem. (Mind you, this is all without doing a lick of
work or seeing a line of code - obviously I'm an expert.)
Now, whew, I may be all wrong and if so, please be gentle.
art
