This is the mail archive of the libstdc++@sourceware.cygnus.com mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: C++ err msgs


Nathan Myers <ncm@cantrip.org> writes:

| On Thu, May 11, 2000 at 12:56:11AM +0200, Gabriel Dos Reis wrote:
| > Under what
| > circumstances default template arguments should be displayed isn't
| > that obvious.  Any suggestion is welcome.
| 
| This seems very easy to me.  *Never* display default template arguments.  

Well, I think I tried (or proposed) something like that the first time
I worked on the diagnostics; IIRC I encountered some resistance.  I'll
try again, now that I'm hearing an echo :-)

| The type is uniquely determined by the non-default arguments, so those 
| are the only ones to display.  The default bindings are part of the 
| definition, and may easily be looked up in the header file by anyone 
| interested.  I can't even imagine a plausible counter-argument.  
| 
| However, to implement this for linker messages probably requires some 
| compiler help, such as an asm equate of the longer actual symbol to
| the squangled shortened form (the latter perhaps prefixed to identify 
| it as such).

For the time being I'll concentrate on the compiler itself (linker and
gdb issues will be addressed later).

| Namespace qualifiers on argument types should also be omitted where 
| they match the namespace of the function itself.  Thus:
| 
| ring.tcc:54: multiple definition of `std::basic_string<char>::basic_string(
|   unsigned, char, allocator<char> const&)

This sounds reasonable to me.  Other opinions?

| Note that I have changed "unsigned int" to "unsigned"; only pedantry 
| insists on "unsigned int".  The "(" is directly adjacent to the function 
| name, according to universal industry convention.  

IIRC, there was a discussion about when and where departure from the
GNU standard coding is possible.  At the time, some us argued that
parts of the GNU standard coding as currently defined are not suitable
for C++.  Unless I'm mistaken the conclusion was the statu quo :-)
Perhaps should I add an option such as:

    -fdiagnostics-formating-rules=<your-standard>

where  <your-standard> may be one of
     gnu        (GNU Standard Coding)
     standard   (the style used in ISO 14882)

But I suspect that might not a good idea for the long time.

| ... The indentation
| doesn't try to line up the "unsigned" with the "(" because that is 
| rarely practical for C++.
| 
| I don't think there's any point in putting in code to insert a space 
| into ``>>'' in template-argument-list terminator sequences. 

Some people might find it helpful to be able to cut-and-paste without
any extra editorial changes.  Should we care?  Should we penalize
them? 

| ...  ``>>''
| appearing in a type name emitted in an error message can mean the 
| operator lexeme only if it appears after the keyword ``operator'', 
| so there can be no ambiguity.
| 
| Making the format depend on environment variables strikes me as 
| wishy-washy.  Make the messages as short, clear, and readable as
| you can make them.  Please don't worry about Gnuical-correctness
| where it conflicts with that, except to the extent that Emacs needs 
| in order to find the correct line in the source file.

OK.

| I will join Benjamin by sending you a bottle of fine Pinot Noir if 
| you implement something even vaguely like this; two bottles if you 
| can shorten linker messages too.

Point taken :-).

-- Gaby
CodeSourcery, LLC		http://www.codesourcery.com

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]