Bruno A. Costa wrote:

> 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.
Hmm, in my code, unused member variables and local variables are usually bugs, and unused parameters are usually not bugs, there are exceptions to both.
However I don't see why searching for these should happen at compile time, the two processes interfere with each other. Perhaps we need a lint and a compiler, likely sharing some code?
Sam

> 
> 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."
> 
> 

In article <cbqmu9$2e7$1@digitaldaemon.com>, Walter says...
>
>
>"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 had thought that D treated unused variables as errors.  Is this not the case for unused arguments?  Not that I'm complaining--I agree that there are legitimate uses for this technique.


Sean

In article <cbr37b$l31$1@digitaldaemon.com>, Arcane Jill says...
>
>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?

I tend to think of Walter's compiler as a reference implementation.  Your example is a completely legitimate extension for a third-party compiler, provided it defaults to off.  The problem in my mind is when third-party compilers display different behavior from one another.  This is the case with current C++ compilers, and as someone who treats all warnings as errors this drives me crazy :)


Sean

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cbr37b$l31$1@digitaldaemon.com...
> 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)

We obviously disagree, because I don't consider that an error. There's no way any of us will agree 100% on the feature set of D.

> 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"?

I'll go with my experience implementing the C and C++ standards - it's better to conform to the standards. Fixing what I consider to be suboptimal decisions in those standards has turned out to be a failure. Changing semantics from one compiler to the next will cause no end of grief and will impede the adoption of D - look at what happened with the varying interpretations of template rules in C++.

That said, having an optional 'lint mode' offered by a particular D implementation can be an appealing feature for that implementation, as long as it is both optional and compiles a strict subset of D.

> 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?

"Mike Swieton" <mike@swieton.net> wrote in message news:pan.2004.06.29.04.31.05.718520@swieton.net...
> 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've run into that, too <g>.

Walter wrote:
> "...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 think it is a matter of when and how you want to spend that time.

> "...As far as I'm concerned, warnings are for wimps..."

I can't take this seriously enough. I won't hire a programmer who ignores or disables compiler warnings if they are there.

> 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."

There are many warnings that are real life-savers. I usually compile my own programs with gcc's -Wall -Werror (enable all common warnings and turn them into erros). They were countless times those warnings saved me. I know that D aims to fix the syntax where it may lead to bugs (like not allowing assignment expressions where a boolean result is expected), but this is still far away from "safe".

There is an ancient programmer wisdom that says that if you manage to create an idiot-proof application, an enhanced type of idiot will be born on the day after.

BTW, both dmd and lastest version of gcc with `-W -Wall´ compiles this without any warning (nested functions are a gcc extension):

int main() {
    int a, b;
    void f(int a) {
        if (a) {
            int a = a+1;
            b == a++;
        }
    }
    f(a);
    return 0;
}

<fun> how much time for someone poping up with a www.iodcc.org? :-D </fun>

-- 
Juliano

In article <cbspu4$427$1@digitaldaemon.com>, Juliano Ravasi Ferraz says...
>
>There are many warnings that are real life-savers. I usually compile my own programs with gcc's -Wall -Werror (enable all common warnings and turn them into erros). They were countless times those warnings saved me. I know that D aims to fix the syntax where it may lead to bugs (like not allowing assignment expressions where a boolean result is expected), but this is still far away from "safe".

It sounds like you agree, but the D compiler always runs as if you had -Wall -Werror set.  I think this is fantastic.  Working with third-party libraries in C++ is a headache for folks like me who compile with these options set in C++. It's often not feasible to fix errors in third-party code, and wrapping everything in a million pragmas is not a fun way to code :)

>There is an ancient programmer wisdom that says that if you manage to create an idiot-proof application, an enhanced type of idiot will be born on the day after.

I'm in the "safety through documentation" camp.  If the user compiles without DBC enabled and didn't read the docs then it's not my problem if he's being an idiot.

>BTW, both dmd and lastest version of gcc with `-W -Wall´ compiles this without any warning (nested functions are a gcc extension):
>
>int main() {
>     int a, b;
>     void f(int a) {
>         if (a) {
>             int a = a+1;
>             b == a++;
>         }
>     }
>     f(a);
>     return 0;
>}

Kind of an odd construct, but I don't see anything wrong with an expression as a statement.  And this one has a side-effect so a compiler might not consider it unnecessary code anyway.


Sean

On Tue, 29 Jun 2004 00:31:06 -0400, Mike Swieton <mike@swieton.net> wrote:

> 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.

From what you've said I think the best soln is that the compiler doesn't ever throw warnings, just errors.

If you think it is and want to be 'extra safe' you run a lint-like program after it compiles.

To me they are seperate and distinct things, one is compiling a program from instructions, either it will go, or it won't.

The other is double checking potential mistakes in those instructions. A lint-like program, or your development ide or whatever can do this step.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Wed, 30 Jun 2004 03:52:48 +1200, Sam McCall <tunah.d@tunah.net> wrote:

> Bruno A. Costa wrote:
>
>> 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.
> Hmm, in my code, unused member variables and local variables are usually bugs, and unused parameters are usually not bugs, there are exceptions to both.
> However I don't see why searching for these should happen at compile time, the two processes interfere with each other. Perhaps we need a lint and a compiler, likely sharing some code?

I agree, they are 2 different processes, they are only linked in that they look at the same imput. I think the best soln is to seperate them.

It paves the way for a competitive market for good lint-like applications.

Regan

>> 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."
>>
>>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Good point.  You convinced me about warnings.  But see Daniel Horn's point below.

What about a compromise?  A standard compiler directive (or metacode, or whatever you wish to call it), which can turn strict booleans off and on for those who need that feature.  If you put it right in the code before and after the line(s) in question, it's right in the code, and they will not be in doubt.


In article <cbqmu9$2e7$1@digitaldaemon.com>, Walter says...
>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?

>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.

==============================
On Monday, June 28, Daniel Horn wrote:
"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."