Re: messages

[Arthur Schwarz <aschwarz1309 at verizon dot net>]

Thanks Dave;'

Acerbic comments below.

--- On Mon, 4/13/09, Dave Korn <dave.korn.cygwin@googlemail.com> wrote:

> > using namespace std;
> > void CommandLine(int argc, char** argv);
> > int main(int argc, char** argv) {
> >? ? string? a = "output.txt";
> >? ? string* b = &a;
> >? ? ofstream y;
> >? ?
> y.open("output.txt",???ios::in);
> >? ? y.open( a,? ? ? ?
> ? ???ios::in);
> >? ? y.open( a.c_str(),?
> ???ios::in);
> >? ?
> y.open((*b).c_str(),???ios::in);
> >? ? y.open( a.c_str,? ?
> ???ios::in);
> >? ? return 0;
> > };
> 
> > 1: error: open(arg1, ...) must be a C-string.
> >? ? The existing message is indecisive in
> it's resolution. It might be 
> >? ? an acceptable idea to analyze expected
> input arguments and compare
> >? ? them with actual arguments and then state
> a reason for failure based
> >? ? on the actual argument(s) that failed. 
> 
> ? Isn't that exactly what the compiler IS doing, as
> indicated by "candidates
> are ... "?

  I don't think so. The compiler is directing the user to a given solution 
  and specifying what the problem is, the compiler is essentially saying
  that it found something it couldn't resolve and for the user to find out
  where and what is wrong. A clear message that arg<n> is wrong I think
  is a better approach. The compiler provides candidate solutions, without
  guidance, and the user must search the candidates (and arguments) to
  determine where the fault lies.
> 
> >? ? overhead at diagnostic generation time.
> My argument is that one 
> >? ? function of a compiler is show the cause
> of failure in unambiguous
> >? ? and clear terms.
> 
> ? It's not always possible for the compiler to do
> that.? How can it know if
> the problem is that you gave the wrong argument type in the
> function call,
> rather than that you got the type wrong in the definition
> of the overloaded
> function that was supposed to match?

  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. 

> 
> > x.cpp:15: error: no matching function for call to
> > 'std::basic_ofstream<char,
> std::char_traits<char> >::open(<unresolved
> overloaded function type>, const
> std::_I
> > os_Openmode&)'
> /usr/lib/gcc/i686-pc-cygwin/4.3.2/include/c++/fstream:626:
> > note: candidates
> are: void std::basic_ofstream<_CharT,
> _Traits>::open(const char*,
> std::_Ios_Openmode
> > ) [with _CharT = char, _Traits =
> std::char_traits<char>]
> 
> > 2: error: open(arg1, ...) must be a C-string, and
> >? ? error: a.c_str not a member of 'a'
> >? ? The first failure is the inability to
> find a valid member of 'a'. 
> 
> ? Err,? are you sure?? I think 'c_str'
> absolutely is a member of a, see two
> lines earlier.? The actual problem is that without the
> brackets, that's a
> function pointer that you're trying to pass when y.open()
> expects a string.

  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.
> 
> http://www.bdsoft.com/tools/stlfilt.html
> 
> ? ? cheers,
> ? ? ? DaveK
> 

Thanks again. 

art


> 
>