Jump to page: 1 25  
Page
Thread overview
Why D doesn't have warnings
Jun 28, 2004
Walter
Jun 28, 2004
J C Calvarese
Jun 28, 2004
Daniel Horn
Jun 28, 2004
Walter
Jun 29, 2004
Arcane Jill
Jun 29, 2004
Sean Kelly
Jun 29, 2004
Walter
Jun 30, 2004
Rex Couture
Jun 30, 2004
Walter
Jun 30, 2004
Rex Couture
Jun 30, 2004
Rex Couture
Jun 30, 2004
Walter
Jun 29, 2004
Derek Parnell
Jun 29, 2004
Walter
Jun 29, 2004
Derek Parnell
Jun 29, 2004
Mike Swieton
Jun 29, 2004
Walter
Jun 29, 2004
Regan Heath
Jun 29, 2004
Sean Kelly
Jun 30, 2004
J C Calvarese
Jun 30, 2004
Rex Couture
Jun 30, 2004
Derek Parnell
Jun 30, 2004
Regan Heath
Jun 30, 2004
Rex Couture
Jun 30, 2004
Arcane Jill
Jun 30, 2004
Rex Couture
Jul 02, 2004
Russ Lewis
Jul 02, 2004
Regan Heath
Jul 02, 2004
Derek Parnell
Jul 02, 2004
Regan Heath
Jun 30, 2004
Rex Couture
Jun 30, 2004
Regan Heath
Jul 02, 2004
Russ Lewis
Jul 02, 2004
Derek Parnell
Jul 02, 2004
Sean Kelly
Jul 02, 2004
ANT
Jul 02, 2004
Russ Lewis
Jun 29, 2004
Bruno A. Costa
Jun 29, 2004
Sam McCall
Jun 29, 2004
Regan Heath
Jun 30, 2004
Walter
Jun 29, 2004
Sean Kelly
Jul 05, 2004
Stewart Gordon
Jul 05, 2004
Regan Heath
Jul 05, 2004
Arcane Jill
Jul 05, 2004
Regan Heath
June 28, 2004
Check out this exerpt from:

http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=160

"Of course, this has been tried before-most compilers generate various warnings when they encounter questionable code. Old-time Unix/C programmers will certainly recall lint(1), a code-checker that did cross-file error checking and parameter type matching. These tools have existed for years but are not popular. Why? Because they generate a lot of warnings, and, as countless software engineers have pointed out, it's time-consuming to sift through the spurious warnings looking for the ones that really matter. I've got news for them: there is no such thing as a warning that doesn't matter. That's why it warns you. Anyone who has worked with enough code will tell you that, generally, software that compiles without warnings crashes less often. As far as I'm concerned, warnings are for wimps. Tools such as lint(1) and DevStudio should not issue warnings: they should decide if they've found an error and stop the build process, or they should shut up and generate code."


June 28, 2004
Walter wrote:
> Check out this exerpt from:
> 
> http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=160
> 
> "Of course, this has been tried before-most compilers generate various
> warnings when they encounter questionable code. Old-time Unix/C programmers
> will certainly recall lint(1), a code-checker that did cross-file error
> checking and parameter type matching. These tools have existed for years but
> are not popular. Why? Because they generate a lot of warnings, and, as
> countless software engineers have pointed out, it's time-consuming to sift
> through the spurious warnings looking for the ones that really matter. I've
> got news for them: there is no such thing as a warning that doesn't matter.
> That's why it warns you. Anyone who has worked with enough code will tell
> you that, generally, software that compiles without warnings crashes less
> often. As far as I'm concerned, warnings are for wimps. Tools such as
> lint(1) and DevStudio should not issue warnings: they should decide if
> they've found an error and stop the build process, or they should shut up
> and generate code."

I much prefer how D makes me fix irregularities in my code by using only errors and no warnings. During the little bit of time that I've worked with C, I didn't often have the self-discipline to start fixing the warnings until they started to scroll off the screen. (tsk! tsk!)

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
June 28, 2004
I agree for the most part... There's one exception to your steadfast rule if the following two conditions apply:
a) the warning may be turned off (and probably is off by default)
b) the compiler errors on said warning.

Then it's just the compiler helping out the user who WANTS to be helped.

Case in point of course is boolean logic.

We should have an optional warning flag passed into the compiler when the user uses a boolean expression as an int or vice versa... the warning may be off for most devels, and for those who deign to turn it on, it would error on said warning.  Of course libs that shipped with the compiler would have it enabled for compatability...

the flag could look like
-Wstrong-boolean -Werror
;-)

J C Calvarese wrote:
> Walter wrote:
> 
>> Check out this exerpt from:
>>
>> http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=160
>>
>> "Of course, this has been tried before-most compilers generate various
>> warnings when they encounter questionable code. Old-time Unix/C programmers
>> will certainly recall lint(1), a code-checker that did cross-file error
>> checking and parameter type matching. These tools have existed for years but
>> are not popular. Why? Because they generate a lot of warnings, and, as
>> countless software engineers have pointed out, it's time-consuming to sift
>> through the spurious warnings looking for the ones that really matter. I've
>> got news for them: there is no such thing as a warning that doesn't matter.
>> That's why it warns you. Anyone who has worked with enough code will tell
>> you that, generally, software that compiles without warnings crashes less
>> often. As far as I'm concerned, warnings are for wimps. Tools such as
>> lint(1) and DevStudio should not issue warnings: they should decide if
>> they've found an error and stop the build process, or they should shut up
>> and generate code."
> 
> 
> I much prefer how D makes me fix irregularities in my code by using only errors and no warnings. During the little bit of time that I've worked with C, I didn't often have the self-discipline to start fixing the warnings until they started to scroll off the screen. (tsk! tsk!)
> 
June 28, 2004
The difficulty with your approach is that when you pass on the code to someone else, they are faced with "is it a bug or is it ok". Compilation should be a binary pass/fail, not something that sort of seems to compile, but who knows if it really did <g>.


"Daniel Horn" <hellcatv@hotmail.com> wrote in message news:cbq6rb$2ckl$1@digitaldaemon.com...
> I agree for the most part... There's one exception to your steadfast
> rule if the following two conditions apply:
> a) the warning may be turned off (and probably is off by default)
> b) the compiler errors on said warning.
>
> Then it's just the compiler helping out the user who WANTS to be helped.
>
> Case in point of course is boolean logic.
>
> We should have an optional warning flag passed into the compiler when the user uses a boolean expression as an int or vice versa... the warning may be off for most devels, and for those who deign to turn it on, it would error on said warning.  Of course libs that shipped with the compiler would have it enabled for compatability...
>
> the flag could look like
> -Wstrong-boolean -Werror
> ;-)


June 29, 2004
On Mon, 28 Jun 2004 12:49:56 -0700, Walter wrote:

> Check out this exerpt from:
> 
> http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=160
> 
> "Of course, this has been tried before-most compilers generate various warnings when they encounter questionable code. Old-time Unix/C programmers will certainly recall lint(1), a code-checker that did cross-file error checking and parameter type matching. These tools have existed for years but are not popular. Why? Because they generate a lot of warnings, and, as countless software engineers have pointed out, it's time-consuming to sift through the spurious warnings looking for the ones that really matter. I've got news for them: there is no such thing as a warning that doesn't matter. That's why it warns you. Anyone who has worked with enough code will tell you that, generally, software that compiles without warnings crashes less often. As far as I'm concerned, warnings are for wimps. Tools such as lint(1) and DevStudio should not issue warnings: they should decide if they've found an error and stop the build process, or they should shut up and generate code."

In the code below, is the non-use of the function argument 'a' an error or not? If its an error then why does D allow it?

If its not an error, wouldn't it be 'nice' to inform the coder of a POTENTIAL error or not?

# int foo(int a)
# {
#     return 1;
# }
#
# void main( )
# {
#     printf("%d\n", foo(200));
# }

I work with a language that, by default, informs me about this type of
coding. I have the option to turn the warning off (on a per function basis
if required).

# without warning
# function foo(integer a)
#   return 1
# end function
# with warning
#
# procedure main()
#   printf(1, "%d\n", foo(200) )
# end procedure

-- 
Derek
Melbourne, Australia
29/Jun/04 10:50:48 AM
June 29, 2004
"Derek Parnell" <derek@psych.ward> wrote in message news:cbqep2$2nut$1@digitaldaemon.com...
> In the code below, is the non-use of the function argument 'a' an error or not? If its an error then why does D allow it?

It is not an error. There are many legitimate cases where one would have unused arguments.

> If its not an error, wouldn't it be 'nice' to inform the coder of a POTENTIAL error or not?

Let's say you know it is not an error in a particular case, and turn off or ignore the warning messages. Now you pass the code on to the maintainers, post it on the internet, sell it to a customer. They try to compile the code, and get the warning. What do they do now? From personal experience, I've found it leaves a bad impression, coupled with confusion and uncertainty, when users of the code compile it and it generates warnings.

That leaves one's best option as "compile with warnings flagged as errors" so the customer doesn't see them, which is essentially what D does. (Another thing D does is adjust the syntax in a few cases so that many typical C warnings can't happen.)

> I work with a language that, by default, informs me about this type of coding. I have the option to turn the warning off (on a per function basis if required).

I've shipped a lot of code with funky pragmas that turn off specific warnings in specific parts of the code. It's a kludge at best. I'm trying to do better with D.


June 29, 2004
On Mon, 28 Jun 2004 19:01:52 -0700, Walter wrote:

> "Derek Parnell" <derek@psych.ward> wrote in message news:cbqep2$2nut$1@digitaldaemon.com...
>> In the code below, is the non-use of the function argument 'a' an error or not? If its an error then why does D allow it?
> 
> It is not an error. There are many legitimate cases where one would have unused arguments.

I think at best one could say that is not necessarily an error. Yes there are many legit cases, and many non-legit cases too.

>> If its not an error, wouldn't it be 'nice' to inform the coder of a POTENTIAL error or not?
> 
> Let's say you know it is not an error in a particular case, and turn off or ignore the warning messages. Now you pass the code on to the maintainers, post it on the internet, sell it to a customer. They try to compile the code, and get the warning. What do they do now? From personal experience, I've found it leaves a bad impression, coupled with confusion and uncertainty, when users of the code compile it and it generates warnings.
> 
> That leaves one's best option as "compile with warnings flagged as errors" so the customer doesn't see them, which is essentially what D does. (Another thing D does is adjust the syntax in a few cases so that many typical C warnings can't happen.)
> 
>> I work with a language that, by default, informs me about this type of coding. I have the option to turn the warning off (on a per function basis if required).
> 
> I've shipped a lot of code with funky pragmas that turn off specific warnings in specific parts of the code. It's a kludge at best. I'm trying to do better with D.

I would prefer that by default 'D', or any language for that matter, behaves like D does now. That is, allow coders to do this sort of thing. However, I'd also like to be able to turn on such a checking process once in a while, to make sure I didn't *accidentally* forget a piece of poor coding. So maybe a lint-like application is not such a silly idea. It is an additional review of my code; one that has better "eyes" than me or my colleagues.

-- 
Derek
Melbourne, Australia
29/Jun/04 2:07:46 PM
June 29, 2004
On Tue, 29 Jun 2004 14:16:00 +1000, Derek Parnell wrote:
> I would prefer that by default 'D', or any language for that matter, behaves like D does now. That is, allow coders to do this sort of thing. However, I'd also like to be able to turn on such a checking process once in a while, to make sure I didn't *accidentally* forget a piece of poor coding. So maybe a lint-like application is not such a silly idea. It is an additional review of my code; one that has better "eyes" than me or my colleagues.

I'll throw in my opinion here, because I know you're all dying to hear it ;)

My problem with warnings in most languages is that they are not all the same. That is, if I have a product which needs to build on several GCC versions along with VC6 (this is the case right now, actually), there are several places where, due to differences in the warnings/errors of the compiler, certain C++ code simply cannot be done the same way on both compilers, and that's ridiculous.

I don't mind the concept of warnings, because it really can tell you when you've done something that may be wrong. After all, a compiler shouldn't be so pedantic as to croak on *every* little thing.

One consideration is this: the D standard could specify 'official' warnings, which are the only ones competing implementations may throw. Optionally, I feel a lint program could be valuable. Just as long as my different compilers work the same.

Note: even some Java compilers/VMs can be bitchy, even with the same language version. Just some brain food for yah.

Mike Swieton
__
Things won are done, joy's soul lies in the doing.
	- William Shakespeare

June 29, 2004
In article <cbqauv$2ilu$1@digitaldaemon.com>, Walter says...
>
>The difficulty with your approach is that when you pass on the code to someone else, they are faced with "is it a bug or is it ok". Compilation should be a binary pass/fail, not something that sort of seems to compile, but who knows if it really did <g>.

The problem, Walter, is that we don't all agree what is or is not an error. I believe that the following SHOULD be an error:

#    // given int a, b;
#    if (a+b)

Now, we all know that a strong boolean type would render that an error, but even /that/ wouldn't catch ALL boolean type errors. I wrote a line of code the other which contained a subtle bug. I wrote:

#    if (a == b) a == c;

Now, the second == should have read =, obviously, but it compiled fine. And EVEN IF we'd have had a strong boolean type, it would STILL have compiled fine. But it /was/ a bug, and I think that it COULD have been spotted by a sufficiently intelligent compiler.

Now, suppose, along comes a second, rival, D-compiler, which is intelligent enough to spot this circumstance and point it out to the user. Should it do so? Should it say "warning - using an equality test as a statement is a really dumb idea"? Or should it go with the idea that DMD's behavior is definitive, because "conflicting standards are bad"?

So long as there exists only one D compiler, there is no use for warnings. But, enter Jill's imagined, hypothetical super-strict compiler designed to catch as many bugs as possible at compile-time - it would be quite reasonable for that hypothetical compiler to offer a "allow anything that DMD allows" option, in which case, that would be a good time to issue warnings. No?

Jill



June 29, 2004
In part I agree with you, but I think there are some special cases where warnings are wellcome. A simple example: In big projects, unused variables may happen and they tend to obfuscate the code, IMHO. In that cases we could have an option like "-Wall" from gcc to instruct the compiler to generate warnings.

And of course, bugs in the library should not be treated by the compiler.

Greetings,

Bruno.


Walter wrote:

> Check out this exerpt from:
> 
> http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=160
> 
> "Of course, this has been tried before-most compilers generate various warnings when they encounter questionable code. Old-time Unix/C programmers will certainly recall lint(1), a code-checker that did cross-file error checking and parameter type matching. These tools have existed for years but are not popular. Why? Because they generate a lot of warnings, and, as countless software engineers have pointed out, it's time-consuming to sift through the spurious warnings looking for the ones that really matter. I've got news for them: there is no such thing as a warning that doesn't matter. That's why it warns you. Anyone who has worked with enough code will tell you that, generally, software that compiles without warnings crashes less often. As far as I'm concerned, warnings are for wimps. Tools such as lint(1) and DevStudio should not issue warnings: they should decide if they've found an error and stop the build process, or they should shut up and generate code."

« First   ‹ Prev
1 2 3 4 5