Hi,
I've found it very useful to be able to use C++ to extend Objective-C
using a little judicious operator overloading and I notice that gcc-4.2
now automatically "unboxes" wrapper classes with no warning when
they are messaged - provided an appropriate cast is available.
For example:
class AS
1], ios:in);
>ofstream y.open(argv[1], ios::in);
>
>return 0;
> };
>
> g++-4 messaging is:
>>> g++-4 x.cpp
> x.cpp: In function 'int main(int, char**)':
> x.cpp:8: error: expected primary-expression before ']' token
> x.cpp:10: error
On Fri, Apr 17, 2009 at 11:58:48AM -0600, Tom Tromey wrote:
> Chris> Clang just prints the include stack information when anything
> Chris> in the include stack differs between two consecutive
> Chris> diagnostics.
>
> We could easily do that too.
FWIW, I think this would be quite useful.
--
Da
> "Joe" == Joe Buck writes:
Joe> If, for definitions, the compiler keeps track of this detail, it
Joe> would be possible to reliably print
Joe> foo.h:11 error: redefinition of `a' (file was included more than once)
Joe> if the printable line number is the same but the internal line number
Joe
On Apr 16, 2009, at 8:44 PM, Joe Buck wrote:
On Thu, Apr 16, 2009 at 03:40:47PM -0700, Arthur Schwarz wrote:
The rock has dropped. The answer is quoted below:
"My best guess is that a header file is included twice, and lacks
guards, hence the message is correct: the function is being define
On Thu, Apr 16, 2009 at 03:40:47PM -0700, Arthur Schwarz wrote:
> The rock has dropped. The answer is quoted below:
>
> "My best guess is that a header file is included twice, and lacks guards,
> hence the message is correct: the function is being defined twice, from the
> same source location."
Thanks to everyone.
The rock has dropped. The answer is quoted below:
"My best guess is that a header file is included twice, and lacks guards, hence
the message is correct: the function is being defined twice, from the same
source location."
I had put my friends following my 'include guard'
e the original conflicting
declaration. Perhaps something like:
<>: error: redefinition of function at <> illegal.
note: istream& operator>> (bool& val );
istream& operator>> (short& val );
o o o
the note: stuff is fr
>
> Can you show code that reproduces the issue? My best
> guess is that a
> header file is included twice, and lacks guards, hence the
> message is
> correct: the function is being defined twice, from the same
> source
> location.
>
> -- James
>
Code (unadulterated and full of original
On Thu, Apr 16, 2009 at 12:06 PM, Arthur Schwarz
wrote:
>
>
>
> Suggested Messaging: Messaging seems redundant in indicating that function
> has been redifined twice. One of the messages should be removed. More to the
> point, I think the messaging may be erroneous - cod
Suggested Messaging: Messaging seems redundant in indicating that function has
been redifined twice. One of the messages should be removed. More to the point,
I think the messaging may be erroneous - code fragment follows.
g++-4 Diagnostic Messaging
In file included from partition.cpp:66
2009/4/14 Arthur Schwarz :
>
> And there are competitive compilers. Some with better messaging and better
> messaging resources at the very point where g++ is weakest. You might argue
> that they are 'better in what way?', but I think the real argument is in what
> ways
way possible.
2: The presentation should be a pointed as possible as to the detected
fault.
3: The user should be required to understand as little as possible in
order to understand the faulting message.
The details of specific messaging are not as important as the guidelines.
What I have seen
2009/4/14 Kai Henningsen:
> aschwarz1...@verizon.net schrieb:
>>
>> Thanks Kai. I do have what I hope is a more specific subjective reason for
>> saying that I think the existing diagnostics should be changed.
>> Fundamentally, what is provided in the messaging is not
On Tue, Apr 14, 2009 at 9:21 AM, wrote:
>
> Thanks Kai. I do have what I hope is a more specific subjective reason for
> saying that I think the existing diagnostics should be changed.
> Fundamentally, what is provided in the messaging is not an indication of what
> i
aschwarz1...@verizon.net schrieb:
Thanks Kai. I do have what I hope is a more specific subjective reason for
saying that I think the existing diagnostics should be changed. Fundamentally,
what is provided in the messaging is not an indication of what is wrong, but an
indication of what is
Thanks Kai. I do have what I hope is a more specific subjective reason for
saying that I think the existing diagnostics should be changed. Fundamentally,
what is provided in the messaging is not an indication of what is wrong, but an
indication of what is required to repair the fault. My
);
return 0;
};
g++-4 messaging is:
g++-4 x.cpp
x.cpp: In function 'int main(int, char**)':
x.cpp:8: error: expected primary-expression before ']' token
x.cpp:10: error: expected primary-expression before ':' token
A recommendation and reason for change is:
1: x.c
messaging is:
>> g++-4 x.cpp
x.cpp: In function 'int main(int, char**)':
x.cpp:8: error: expected primary-expression before ']' token
x.cpp:10: error: expected primary-expression before ':' token
A recommendation and reason for change is:
1: x.cpp:8 error: illega
e in #include "
Mainline gcc has the same message. I agree that "not found" seems
clearer. I'm not sure I agree about suggesting header files; that is
the kind of thing which will work well in some environments but fail
badly in others.
Suggesting "not defined&quo
Arthur Schwarz wrote:
> /*
> * m3.cpp
> */
>
> # include
> # include
>
> using namespace std;
>
> ifstream x;
> ifstream y();
> If 'std::ifstream' not found, why is 'std::ifstream y();' legal?
Ooh, I know this one. It's because it's not a definition of an ifstream
object constructed
In light of the foolhardy commitment I made, here are some reprehensible
diagnostic messages and the superb recanting of the obvious. As always, the
messaging and comments are gratuitously provided and I hope accepted in the
same manner.
Two notes (made before):
1: Some messages are
Arthur Schwarz wrote:
>
> (I've already provided an indication of a willingness to do something to
> Robert Dewar).
Does his wife know? :-O
cheers,
DaveK
(I'll get my coat)
Arthur Schwarz writes:
> I didn't mean to volunteer. I'm retired and therefor am both
> unhireable and hove no free time. But if you really (really) want
> ... I'd be glad to contribute in any way that I can. Provide what you
> need that I can do, and a means to give you feedback and I'm yours.
I didn't mean to volunteer. I'm retired and therefor am both unhireable and
hove no free time. But if you really (really) want ... I'd be glad to
contribute in any way that I can. Provide what you need that I can do, and a
means to give you feedback and I'm yours.
(I've already provided an ind
On Thu, Apr 09, 2009 at 11:03:20AM -0700, Ian Lance Taylor wrote:
> Arthur Schwarz writes:
> > 2: Stream errors are tortuous to decode to find the cause of
> >error..Any thought to simplification?
> >
> >In particular: 'stream << something_wrong;' can produce a
> >multiline message wit
Arthur Schwarz writes:
> 1: Any thought to including column numbers with line numbers on
> ERROR messages? Looking at a diagnostic message for a complex
> statement without a column number has lead to making an
> incorrect assumption as to what in the line is faulty. A
> column nu
Please take the comments as constructive and not adversarial. I use GCC
and have hopes of sending it a Valentine's Day gift.
1: Any thought to including column numbers with line numbers on
ERROR messages? Looking at a diagnostic message for a complex
statement without a column number has
28 matches
Mail list logo
