Walter Bright wrote:
> I have many years of experience with warnings, and none of it finds any use for warnings that do not stop the compiler. If someone believes there is a valid reason, they need to present a very convincing case.

How does one ignore just one specific warning or one type of warning while still compiling with -w?  It'd be nice if there was some way to tell the compiler that a specific line or area of code is indeed correct and to not spit out a warning (or, more importantly, halt on it).

~John Demme

"John Demme" <me@teqdruid.com> wrote in message news:ds6ioh$227b$1@digitaldaemon.com...
> Walter Bright wrote:
>> I have many years of experience with warnings, and none of it finds any use for warnings that do not stop the compiler. If someone believes there is a valid reason, they need to present a very convincing case.
>
> How does one ignore just one specific warning or one type of warning while still compiling with -w?  It'd be nice if there was some way to tell the compiler that a specific line or area of code is indeed correct and to not spit out a warning (or, more importantly, halt on it).

Each warning has an associated source code modification that will get rid of it.

I think the current treatment of warnings reduces the chances of writing invalid code in the future, and enforces correct use of the language specification. It may be annoying in some cases, but I think it's a good tradeoff. On the other hand, I think Bob had a good idea and "show warnings and treat them as errors" should be printed in DMD's help.

--Sebastián.

Matthew wrote:

> Walter's sentiments are agreeable when one is dealing with production
> builds, under which only a fool would not invoke "warnings as errors", but
> when experimenting, or working on something new, or inserting returns for
> debugging (something Walter strongly advocates, btw), or myriad other
> "messing around" purposes, it's going to be more hindrance than help.

Phobos doesn't use warnings, though ? (i.e. doesn't compile with -w)

I used to ship some of my libraries with a CFLAGS of "-Wall -Werror",
but it only seemed to trip on the *system* headers on the client end
and made the library less portable in the end. So I changed to -Wall.

--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:ds7mir$30tk$1@digitaldaemon.com...
> Matthew wrote:
>
> > Walter's sentiments are agreeable when one is dealing with production builds, under which only a fool would not invoke "warnings as errors",
but
> > when experimenting, or working on something new, or inserting returns
for
> > debugging (something Walter strongly advocates, btw), or myriad other "messing around" purposes, it's going to be more hindrance than help.
>
> Phobos doesn't use warnings, though ? (i.e. doesn't compile with -w)

LOL! I didn't know that.


I'm still waiting for Walter to explain the paradox between the bug-finding activities that he recommends to just about everyone that ever raises a compiler problem and not being able to generate code and link with something that emits a warning. (I may be waiting some time ...)

"Matthew" <matthew@hat.stlsoft.dot.org> wrote in message news:ds8jkh$qf8$1@digitaldaemon.com...
> I'm still waiting for Walter to explain the paradox between the
> bug-finding
> activities that he recommends to just about everyone that ever raises a
> compiler problem and not being able to generate code and link with
> something
> that emits a warning. (I may be waiting some time ...)

If you can show an example where being able to execute code that generates a warning will make the cause of the warning less mysterious, I'd be very interested.

"Walter Bright" <newshound@digitalmars.com> wrote in message news:ds8lvv$s2k$1@digitaldaemon.com...
>
> "Matthew" <matthew@hat.stlsoft.dot.org> wrote in message news:ds8jkh$qf8$1@digitaldaemon.com...
> > I'm still waiting for Walter to explain the paradox between the
> > bug-finding
> > activities that he recommends to just about everyone that ever raises a
> > compiler problem and not being able to generate code and link with
> > something
> > that emits a warning. (I may be waiting some time ...)
>
> If you can show an example where being able to execute code that generates
a
> warning will make the cause of the warning less mysterious, I'd be very interested.

Are you affecting obtuseness as a means of stimulating debate for the people reading but not participating? (Not rhetoric. I'm genuinely confused.)

Anway, here's the situation as I see it, as I can most plainly express it:

1. You recommend that people chop down code in order to isolate bugs. Such bugs can include compile-time and runtime bugs.

2. You offer a compiler that does not allow a user to generate code while observing warnings.

These two are in obvious conflict. Anyone with any problem compiling any compiled-language will, in following your stipulation to the chop-and-test approach, have to remove code. Those with a version control system, a huge Undo buffer and perfect faith in their IDDE not to crash may genuinely _remove_ code. Those more careful/careworn might instead put in an early return statement here and there. Since the last thing one wants to do when debugging is to introduce new bugs, such users might sensibly wish to continue to be informed of potential problems by having their compiler emit as many warnings as it can.

This is so obvious to anyone that's ever even touched the hem of a debugger that no example should be necessary. I'm left grasping for a credible explanation as to why you suggest one is necessary, other than perhaps to try and wear me down in fatuous effort.

Please point out the flaw in my reasoning of your paradox, and, further,
explain to me how, in following this technique in many circumstances where
debugging has been necessitated in C/C++/D/Ruby/Java/.NET, I have gone so
astray in my practice. What should I have been doing instead? This is not
rhetoric for the sake of it: please do elucidate. If you cannot, please
explain how DMD's current contradiction of 1 and 2 is not an
arbitrary shackle to its users, one based solely on your own work practices
and
prejudices that, I hope, you would have to concede may not map to those of
all
other developers.

I'm not sure I see the problem.  Since the warnings mode is optional, what's to stop you from building with warnings until you fix everything it flags that you care about then turn the option off and build to test?

My only issue is that with "warnings as errors" as the only warnings-enabled option, there must be a code-level way to fix anything the compiler warns about.  Otherwise, shops that build with warnings enabled as the release mode would be SOL if the compiler warns about something intended.

This is typically how I do things with VC++: require no messages at WL:4 and preprocessor directives to situationally disable any warnings about utterly stupid things (like the "standard function is deprecated" business in VC 2005).  Things like implicit narrowing conversions are flagged by the compiler and casts are added where appropriate, etc.  To me, fixing warnings is mostly a matter of either fixing the bug or telling the compiler "yes, I meant to do that."  I can't think of a situation where I'd want to ship with some warning messages still displaying, assuming I cared enough to enable them.


Sean

On Tue, 7 Feb 2006 13:32:40 +1100, Matthew <matthew@hat.stlsoft.dot.org> wrote:
> "Walter Bright" <newshound@digitalmars.com> wrote in message
> news:ds8lvv$s2k$1@digitaldaemon.com...
>>
>> "Matthew" <matthew@hat.stlsoft.dot.org> wrote in message
>> news:ds8jkh$qf8$1@digitaldaemon.com...
>> > I'm still waiting for Walter to explain the paradox between the
>> > bug-finding
>> > activities that he recommends to just about everyone that ever raises  
>> a
>> > compiler problem and not being able to generate code and link with
>> > something
>> > that emits a warning. (I may be waiting some time ...)
>>
>> If you can show an example where being able to execute code that generates a warning will make the cause of the warning less mysterious, I'd be very
>> interested.
>
> Are you affecting obtuseness as a means of stimulating debate for the people reading but not participating? (Not rhetoric. I'm genuinely confused.)
>
> Anway, here's the situation as I see it, as I can most plainly express it:
>
> 1. You recommend that people chop down code in order to isolate bugs. Such bugs can include compile-time and runtime bugs.
>
> 2. You offer a compiler that does not allow a user to generate code while
> observing warnings.
>
> These two are in obvious conflict. Anyone with any problem compiling any
> compiled-language will, in following your stipulation to the chop-and-test
> approach, have to remove code. Those with a version control system, a huge Undo buffer and perfect faith in their IDDE not to crash may genuinely
> _remove_ code.

Or copy the file(s) involved and chop the cop(y|ies).

> Those more careful/careworn might instead put in an early
> return statement here and there. Since the last thing one wants to do when
> debugging is to introduce new bugs, such users might sensibly wish to
> continue to be informed of potential problems by having their compiler emit as many warnings as it can.

True, but not strictly required to produce a test case.

Regan

"Matthew" <matthew@hat.stlsoft.dot.org> wrote in message news:ds90n7$1411$1@digitaldaemon.com...
> "Walter Bright" <newshound@digitalmars.com> wrote in message news:ds8lvv$s2k$1@digitaldaemon.com...
>> "Matthew" <matthew@hat.stlsoft.dot.org> wrote in message news:ds8jkh$qf8$1@digitaldaemon.com...
>> > I'm still waiting for Walter to explain the paradox between the
>> > bug-finding
>> > activities that he recommends to just about everyone that ever raises a
>> > compiler problem and not being able to generate code and link with
>> > something
>> > that emits a warning. (I may be waiting some time ...)
>> If you can show an example where being able to execute code that
>> generates a
>> warning will make the cause of the warning less mysterious, I'd be very
>> interested.
> Are you affecting obtuseness as a means of stimulating debate for the
> people
> reading but not participating? (Not rhetoric. I'm genuinely confused.)

I genuinely have no idea what the problem is you're talking about.


> Anway, here's the situation as I see it, as I can most plainly express it:
> 1. You recommend that people chop down code in order to isolate bugs. Such
> bugs can include compile-time and runtime bugs.
> 2. You offer a compiler that does not allow a user to generate code while
> observing warnings.
>
> These two are in obvious conflict.

No, they aren't. If the person doesn't understand why the warning is being generated, executing the code won't help in the slightest. If it isn't about the warning, just turn off warnings. Turning off the warnings isn't any more work than turning on "warn but keep going".

> Anyone with any problem compiling any
> compiled-language will, in following your stipulation to the chop-and-test
> approach, have to remove code.

You write as if there's something wrong with the chop and test approach, or that it's something unique. It's not unique (it's taught at better universities). It's a generally and widely used problem solving technique, also known as divide-and-conquer. And it's the only one that has a reasonable chance of success with a complex system. I've spent 30 years in engineering, and those people who do not know how to reduce the problem domain spent hours, days, *months* futzing about chasing phantoms, wasting time, trying things essentially at random, and never figuring out what's going wrong.

> Those with a version control system, a huge
> Undo buffer and perfect faith in their IDDE not to crash may genuinely
> _remove_ code. Those more careful/careworn might instead put in an early
> return statement here and there. Since the last thing one wants to do when
> debugging is to introduce new bugs, such users might sensibly wish to
> continue to be informed of potential problems by having their compiler
> emit
> as many warnings as it can.

The way to do chop-and-test is to make a copy of your project, and work from the copy. Or at least make a full backup first. If you do not make a copy first, you are nearly guaranteed to screw up your source code, whether or not you are using CVS or have undo buffers. Warnings aren't going to help in the slightest.

There's no reason whatsoever to worry about introducing new bugs doing this.

If you are in a position where you are somehow unable to back up your project or work from a copy of it, then for whatever reason you've completely lost control over the project and have much bigger problems than warnings.


> Please point out the flaw in my reasoning of your paradox, and, further, explain to me how, in following this technique in many circumstances where debugging has been necessitated in C/C++/D/Ruby/Java/.NET, I have gone so astray in my practice. What should I have been doing instead?

Make a full copy of your project, and work from that.

> This is not
> rhetoric for the sake of it: please do elucidate. If you cannot, please
> explain how DMD's current contradiction of 1 and 2 is not an
> arbitrary shackle to its users,

You're worried about screwing up your project by applying divide-and-conquer, so you want warnings to continue. That is a misunderstanding of how to go about it. Make a copy of your project. Then hack and slash the copy until you've isolated the problem. Turn off the warnings. Stop worrying about introducing a bug - it's a sacrificial copy, not the original.

> one based solely on your own work practices and prejudices that,
> I hope, you would have to concede may not map to those of all other
> developers.

Trying to use warnings as a substitute for making a backup is like a carpenter trying to hammer a nail with a screwdriver. It's the wrong answer, and trying to make a screwdriver that can be used as a hammer is also the wrong answer.