2009/4/9 Mattias G?rtner :

This is another important problem. Easily unnoticed hints are just useless. There are two related causes here:
1) The message window interface of Lazarus is currently very weak. (And it hides most of the hints by default, which I consider a bug in design). This interface is one thing I think is worth borrowing from Visual Studio.
2) The compiler produces _many_ extraneous hints, which is very harmful -- it is impossible to produce hints-free code, so new hints has much more chances
to go unnoticed.

First point is IMO of "patches welcome" category (and perhaps I will provide some,
but don't count on that), but the second one is more fundamental. There are two main sources of harmful hints now:

1) "Parameter unused".
This is by far the main culprit. There are many cases when parameters are unused deliberately -- e.g. basic implementations of virtual functions, most events etc.
OTOH, the hint is not _entirely_ useless and can in some rare cases point to a real bugs.
The solution is to enable per-variable hint suppression. It is done in C/C++ by omitting variable name, but I think a better way would be a compiler directive.

I see two variants:
a) procedure TMyForm.Button1Click(ASender {$UNUSED}: TObject); b) procedure TMyForm.Button1Click(ASender: TObject); {$UNUSED ASender}

The first one is slightly messy in case of many unused arguments, while the second one avoids duplicating their names, so I am not sure which is better.
Implementing either of them will fix the problem.

2) "Uninitialized variable" for auto-initialized strings. See http://bugs.freepascal.org/view.php?id=0013341 and http://bugs.freepascal.org/view.php?id=13370.
Both issues were resolved as "won't fix" which IMHO was done without considering full picture.
Here is my argument:
There are two possible approaches to "non-initialized" warning: a) Do not guarantee anything about non-initialized variables, complain on their usage.
This is C/C++ route. It is not entirely consistent there as well (global variables of simple types
are still auto-initialized to zero), but that is their problem. b) Makes some guarantees about variable initialization and complain only for the variables which are not initialized automatically. This is Object Pascal/Delphi route.
It does not warn about global variables, object fields, strings and interfaces since they are guaranteed
to be auto-initialized in a consistent way (and programmers rely on that).

FPC seems to take the third route -- it inconsistently warns[1] about globals, strings and interfaces but
not object fields. This is the worst of both worlds and should be fixed one way or another.
Compatibility and language tradition dictate retaining auto-initialization, but I am not principle
opposed to removing it -- this, however, should be a loudly declared lack of feature/incompatibility
and have a good reason.

[1] FPC issues this warning even in Delphi mode, which is an outright bug.

Zitat von Alexander Klenin :

What hints are hidden?

This interface is one thing I think is worth borrowing from Visual Studio.

Can you give more details for the people who don't know VS?

2) The compiler produces _many_ extraneous hints, which is very harmful -- it is impossible to produce hints-free code, so new hints has much more chances to go unnoticed.

True.

That's pretty much what I purposed a long time ago. I even implemented it once via IDE directives.
But the code gets ugly and it worked only in lazarus. A compiler solution with some synedit sugar might improve this.

... or because they considered an even bigger picture than you.

Wrong list. Lazarus will not change the compiler.

[1] FPC issues this warning even in Delphi mode, which is an outright bug.

Mattias

Alexander Klenin wrote

[...] 2) The compiler produces _many_ extraneous hints, which is very harmful -- it is impossible to produce hints-free code, so new hints has much more chances to go unnoticed.

While I agree in principle that extra verbosity is a source of bugs, the "hint" severity is for messages that cannot positively be determined to be potentially dangerous.

It goes like this:

Fatal error: Something so bad that compilation cannot possibly continue

Error: Something that is certainly wrong, but compilation can continue, even though it wont overall succeeed.

Warning: Something that is definitely /possibly/ dangerous, but might be safe in the specific circumstance. It's always possible to quench warnings by changing the code. Warnings should always be a sign of some problem in your code (that may or may not make your program behave incorrectly)

Hint: Something that can't be ruled out as dangerous, but might just be. For practical reasons, this category can't be merged with "warnings", because that would then produce so many warnings that the only useful error category would be "error". That would be bad.

Hello Christian,

Thursday, April 9, 2009, 7:13:06 PM, you wrote:

CI> Hint: Something that can't be ruled out as dangerous, but might just be. CI> For practical reasons, this category can't be merged with "warnings", CI> because that would then produce so many warnings that the only useful CI> error category would be "error". That would be bad.

Yes but an easy way to tell the compiler that the hint or warning is expected must exists and I think that {$HINTS OFF} is a too radical path.

In my case for the "Parameter not used" I'm using a heavily overloaded procedure "UseParameter" which does nothing and my code is clear of this kind of hints. The problem is that I must updated the "UseParameter" each time I use a new parameter type.

That's really 2 statements:

A) There should be a way to tell the compiler that the hint is expected

Well, I can't see why this is a given. By definition, hints are things that _can_ be potentially dangerous, but it's impossible to determine for sure. Warnings point out things which are always potentially dangerous.

Therefore, for hints, you'll just end up with code that's entirely plastered in specifications to disable hints. This will make the code ugly, and remove time that could be spent better.

For warnings, it should always be considered a problem with the code if it generates a warning. If the code is fine, then the compiler is wrong for issuing a warning rather than a hint. This is somewhat rare, however. I think it's a bit of time since a warning was reclassified (but I have seen it happen).

B) Saying {$HINTS OFF} is too radical

Well, I agree it can be bit radical. Perhaps a switch to disable certains hints only would work better. Typically, certain hints give you more trouble than others, depending on coding style.

In my case for the "Parameter not used" I'm using a heavily overloaded procedure "UseParameter" which does nothing and my code is clear of this kind of hints. The problem is that I must updated the "UseParameter" each time I use a new parameter type.

I'm not sure what you mean? Can you give a small example?

Hello Christian,

Friday, April 10, 2009, 1:20:43 AM, you wrote:

CI> That's really 2 statements:
CI> A) There should be a way to tell the compiler that the hint is expected CI> Well, I can't see why this is a given. By definition, hints are things CI> that _can_ be potentially dangerous, but it's impossible to determine CI> for sure. Warnings point out things which are always potentially dangerous.

As warnings are usually bad practice maybe they can be isolated with a simple {$WANINGS OFF}{$WARNINGS ON} and they are quite rare in a program.

But now hints are being too verbose, almost anybody initializes a string because by definition is is being initialized to '' (nil) and it is garanteed, so why add some code to reset it to the expected value :-?

In other words MY (capital, as it is my problem, maybe not the problem of other people) is that the amount of expected hints are hidding the non-expected ones.

> In my case for the "Parameter not used" I'm using a heavily overloaded > procedure "UseParameter" which does nothing and my code is clear of > this kind of hints. The problem is that I must updated the > "UseParameter" each time I use a new parameter type.

CI> I'm not sure what you mean? Can you give a small example?

unitparameters.pas
------------------
{$HINTS OFF}
procedure UseParameter(const A: integer); overload;
begin
end;
procedure UseParameter(const A: String); overload;
begin
end;
procedure UseParameter(const A: TObject); overload;
begin
end;
{$HINTS ON}

OtherUnit.pas
-------------
uses ...,unitparameter;

procedure ClickPos(Sender: TObject; X,Y: integer);
begin
  UseParameter(Sender);
  UseParameter(X);
  UseParameter(Y);
  Beep;
end;

This "technique" keeps my code more or less clean of expected non-used parameter hints, and when releasing program I perform a search and replace for "UseParameter" -> "//UseParameter".

Maybe an array of variants could be used to simplify, but then variants come in play and I do not like them if I can code without ;)

I agree. Maybe that specific hint is even poorly implemented, and overly trigger-happy.

In other words MY (capital, as it is my problem, maybe not the problem of other people) is that the amount of expected hints are hidding the non-expected ones.

Right. And as I said, it would probably be more productive to disable an entire type of hints.

Ok, I can see what you're doing there. In my opinion, it's not very pretty. How about something like this:

procedure SilenceHint(const A); inline;
begin
end;

That should require only 1 procedure, and wont require search-replace because it will simply be optimized out.

Still, I think it's kind of ugly ;-)

My original point is that the "uninitialized variable" hint is so common that it becomes practically useless in certain applications -- for example lazarus ones. If you could say, e.g:

{$HINT UNUSED_PARAMETER OFF}

Then that would make it easier for you to spot the real problems. Granted, it wont catch the maybe 1-in-1000 actual "unused parameter" problems, but littering the code with UseParameter() "calls" seems, in my opinion, quite ugly, and a lot of work for a small gain.

Maybe an array of variants could be used to simplify, but then variants come in play and I do not like them if I can code without ;)

I think my version works fine. You could even overload it to accept multiple argument, so you could do

SilenceHint(Sender, X, Y);

Christian Iversen wrote

SilenceHint(Sender, X, Y);

Or use array of const, like the format function.

Vincent

Hello Christian,

you wrote

> In other words MY (capital, as it is my problem, maybe not the problem > of other people) is that the amount of expected hints are hidding the > non-expected ones.

CI> Right. And as I said, it would probably be more productive to disable an CI> entire type of hints.

Well, I compile my code with all checks and it must be error/warning/hint free before being considered ready. Hide hints even of a given kind is not a solution to me, but of course it is better to have a way to hide them, kind by kind than nothing. The current Lazarus filter is fine for that but I only want to hide the hints in the places that it is the expected thing.

CI> Ok, I can see what you're doing there. In my opinion, it's not very CI> pretty. How about something like this:

CI> procedure SilenceHint(const A); inline;
CI> begin
CI> end;

Hmmm... I'm not used to use formal parameters, I'm always using strict formats and simply forget that possibility.

CI> That should require only 1 procedure, and wont require search-replace CI> because it will simply be optimized out.

Hmmm... not it will not be optimized out. Inline and formal parameters are not compatible and if not using inline it will not be optimized out at least not by FPC and I think the linker will not remove it also.

The remove maybe will be performed using global optimization, but I can not test it.

CI> Still, I think it's kind of ugly ;-)

It is :)

CI> My original point is that the "uninitialized variable" hint is so common CI> that it becomes practically useless in certain applications -- for CI> example lazarus ones. If you could say, e.g:
CI> {$HINT UNUSED_PARAMETER OFF}

I really prefer something like {$UNUSED X,Y,Other,Sender}

I prefer to specify which parameters are unused by intention.

CI> I think my version works fine. You could even overload it to accept CI> multiple argument, so you could do
CI> SilenceHint(Sender, X, Y);

Yes but that's a one specific shot, maybe good for one class, but not for a generic use (this kind of overload).

I still prefer compiler-level solution, but if Lazarus team agrees, I can use that method too. Anything for hints-free compilation ;-)

Maybe it is not salvageable, but then IMHO the hint should disabled by default in fpc.cfg.

Granted, it wont catch the maybe 1-in-1000 actual "unused parameter" problems, but littering the code with UseParameter() "calls" seems, in my opinion, quite ugly, and a lot of work for a small gain.

One way to combat ugliness would be to use keyword, as in

  procedure TMyForm.Button1Click(unused ASender: TObject);

which is very nice and readable, but the price is probably too steep.

BTW, did you actually try this? It does not work at least on FPC 2.2.4: Warning: "formal parameter" not yet supported inside inline procedure/function Warning: Inlining disabled

Hello Vincent,

Friday, April 10, 2009, 10:31:19 PM, you wrote:

VS> Christian Iversen wrote

> > SilenceHint(Sender, X, Y); >

VS> Or use array of const, like the format function.

Hmmmm... array of const does not use variants so it could be fine, in spanish keyboard the combination is quite difficult to be used "([,])" implies use modifiers in both hands (for most people) but seems to be a good option.

Op vrijdag 10-04-2009 om 22:51 uur [tijdzone +0200], schreef JoshyFun:

Very nice that you have made up this rule for yourself. But as you've find out you really make things complicated for yourself.

The fpc-team decided long time ago to make two different compiler-messages. The 'warnings' which are construct of which the compiler knows that they are always messy. In general, you should solve those.

And there are 'hints', things which are things that the compiler finds suspicious, but of which it CAN NOT BE SURE that it is a problem. Some programmers do strange things, but they have a reason for that, or it's too difficult for the compiler to decide if it's good or wrong, so it's up to the programmer.

Keep this rules in mind. When you want to write hint-free code, that's your choice, and it can lead to messy stuff. But don't blame the compiler.

A system to disable/enable each hint seperately is discussed often and there are some beginnings of implementations made. But it's not here yet, and yes: patches are welcome.

If you have a situation in which you know that a hint is always a 'false positive' and a way that the compiler could know that, you could try to file a bug or make a patch.

Further, this is the wrong list to discuss this, because it's fpc-specific, not Lazarus. Escpecially when you want that something is done about this, this is the wrong place. (As Matthias already stated)

Joost

Are you aware that fpc trunk already implemented an option to disable hints?

See: http://bugs.freepascal.org/view.php?id=8690

Luiz

Hello Joost,

Saturday, April 11, 2009, 11:48:02 AM, you wrote:

JvdS> Very nice that you have made up this rule for yourself. But as you've JvdS> find out you really make things complicated for yourself. [...]
JvdS> And there are 'hints', things which are things that the compiler finds JvdS> suspicious, but of which it CAN NOT BE SURE that it is a problem. Some

I know that, that's the reason I was not requesting nothing and the reason of note that it is "MY" problem.

JvdS> Keep this rules in mind. When you want to write hint-free code, that's JvdS> your choice, and it can lead to messy stuff. But don't blame the JvdS> compiler.

I had never done that, I was only showing my opinion as an user, I think that opinions as patches are welcome and developers can take them in account or simply discard them. Maybe more people thinks the same as me or maybe I'm an alien.

JvdS> A system to disable/enable each hint seperately is discussed often and JvdS> there are some beginnings of implementations made. But it's not here JvdS> yet, and yes: patches are welcome.

I'm very happy submitting patches but I will not submit a patch to something that I can not understand and garantee that it will work as expected and compiler technology is far away from my skills and I'm only submitting patches to small pieces of code for specific functions like the UTF8Decode one. I do not want to ruin a nice piece of code.

JvdS> If you have a situation in which you know that a hint is always a 'false JvdS> positive' and a way that the compiler could know that, you could try to JvdS> file a bug or make a patch.

Be sure about that.

JvdS> Further, this is the wrong list to discuss this, because it's JvdS> fpc-specific, not Lazarus. Escpecially when you want that something is JvdS> done about this, this is the wrong place. (As Matthias already stated)

You are right, I was following the thread and crossed the topic boundaries :( By my side the thread in this list is dead. Please if you like to reply this message use private mail or fpc mailing list.

Luiz Americo Pereira Camara wrote

Are you aware that fpc trunk already implemented an option to disable hints? See: http://bugs.freepascal.org/view.php?id=8690

Lazarus trunk also has this options.

Best regards,
Paul Ishenin.

I didn't try it, actually. It was just an idea.

How about defining a macro instead? You might have a macro that does nothing sufficiently well that it silences the hints.

As you can see from the part of my original post quoted above, this solution is, unfortunately, not useful .

OK.

Currently, you can disable only the "Parameter not used" hint and keep the other hints. If this is not enough, you can open a fpc bug report

Luiz