Re: CodeWarrior vs Xcode issues
Re: CodeWarrior vs Xcode issues
- Subject: Re: CodeWarrior vs Xcode issues
- From: Ben <email@hidden>
- Date: Tue, 7 Jun 2005 15:46:51 -0700 (PDT)
My point is that it's a bad way to write something. If you want 'foo' to
be the same as 'f', then you should write 'f'. Otherwise, the compiler is
going to ignore stuff you took the effort to type and make a guess as to
what it thinks you meant, and it wants you to know that. Personally, I
support that decision, and wish it to succeed. :)
But then, I have to admit I haven't read the specs for C or C++. I have no
idea what they say about how to treat multi-character character literals.
Obviously the "correct" thing to do is to follow spec. But if the spec is
silent, then, speaking for myself, would want to know when the compiler is
guessing or comes across common typo mistakes.
On Tue, 7 Jun 2005, Andy O'Meara wrote:
>
> Your example isn't appropriate. How about this: try to come up with *any*
> way that the multi-char warning I demonstrated would be useful in that it
> uncovered an unintended side effect.
>
>
> Andy
>
>
>
>
> On 6/7/05 5:40 PM, "Ben" <email@hidden> wrote:
>
> > You're right, these couldn't hurt anything. But then, neither can:
> >
> > if (x=y)
> >
> > ... which also throws warnings in gcc, and I'm glad that it does.
> >
> > On Tue, 7 Jun 2005, Andy O'Meara wrote:
> >
> >>
> >>
> >>> Even if you do manage to suppress specific warnings, how can you
> >>> differentiate between the "spam" warnings and legitimate warnings if
> >>> they are the same string? Would you do it on a per-file basis? The
> >>> real solution, which makes your code also far more portable to other
> >>> compilers/platforms, is to adhere to the standards. For example, lots
> >>> of warnings can be squashed using proper casts, comments are not
> >>> nestable, etc.
> >>>
> >>> Personally, if I can't get my code past -Wall (gcc all warnings on),
> >>> then I don't even bother running the binary- the warnings are a great
> >>> help to me- even they don't indicate an immediate bug, a proper cast
> >>> can also double as a supplement to documentation. If I could get a
> >>> bunch of compilers from different companies for free and compile with
> >>> all of them with maximum warnings on, I would do it.
> >>>
> >>
> >>
> >> I absolutely agree--only a fool would turn off warnings like cast
> >> warnings... As I described, I was strictly referring to two warnings that
> >> couldn't hurt a flea. Consider an example of one of them:
> >>
> >> int n = 'xy';
> >>
> >> Correct me if I'm wrong, but I don't see the danger. An ASCII char inline
> >> like that is equivalent to any other inline integer, so why should I get a
> >> warning for it? Is there any case that, say, ' ' wouldn't *always* be
> >> equivalent to 0x2020 or 32 * 256 + 32? Sure enough--try it for yourself:
> >>
> >> int n1 = ' '; // warning
> >> int n2 = 0x2020; // no warning
> >> int n3 = 8224; // no warning (of course)
> >>
> >> Heh, everyone seems to have it in for me just because I say the phrase
> >> "suppress warnings"--folks just need to see that I'm just proposing that
> >> Apple improve its warning control/suppression--and that's all....
> >>
> >>
> >> Andy
> >>
> >>
> >>
> >> _______________________________________________
> >> Do not post admin requests to the list. They will be ignored.
> >> Xcode-users mailing list (email@hidden)
> >> Help/Unsubscribe/Update your Subscription:
> >>
> >> This email sent to email@hidden
> >>
> >
> >
> >
>
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden