Arthur Schwarz wrote:
> Thanks Dave;'
>
> Acerbic comments below.
G'wan, I can take it!
>> 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.
> Even accepting your statements as accurate some of the time I think it
> a good diagnostic tool for the user for the compiler to do what it can
> when it can. If the judicious answer is that the cases where such a
> tool could be provided is an edge condition where there is small chance
> of occurrence, why then (to be forceful - ahem - needlessly vehement)
> let the user suffer.
But then we agree; the compiler should do everything it can. I'm just not
sure it /can/ do what you're asking here.
> And I agree. My analysis is faulty in that the member function is seen,
> but the diagnostic message doesn't say what's wrong. The determination
> of what the error is is left to the casual observer.
>
>> BTW, have you ever tried STLfilt? It's highly
>> relevant to your interests:
>
> No I haven't but now that I know something exists I probably will.
>
> Before I toodle off, let me put some kinder words around what I'm doing.
> I'm
> not pointing fingers or poking fun. As a result of my own lacks it was
> suggested that I volunteer to provide alternatives to diagnostic messaging for
> the gcc to consider. They are apparently directly addressing the issues
> involved with constructing user oriented diagnostic messages and asked me to
> volunteer to send what I thought could be changed for their consideration. The
> examples given are designed only to illustrate messaging and alternative
> wording for consideration. Each day I address my 'skills' in software and find
> they are more modest than first thought. There is no thought to impose myself
> on the organization or criticize anything in this product. Anything at all.
> Nada. Nothing.
> In brief, the examples are not meant to display what I don't know or seek
resolution of my lack of skill.
Nonono; I didn't mean to impugn anything you're doing, just trying to point
out that it's not easy. Your suggestions are all valid and good ideas, but
before they can be usefully incorporated into the compiler, they need to be
expressed in clearer language. It's easy for us as humans to try and infer
the original author's intent, but much more difficult for a parser.
What would help is, as well as suggesting a new clearer message, you could
suggest under what conditions the compiler should use this new message.
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.
cheers,
DaveK
