2009/4/9 Mattias Gärtner <nc-gaert...@netcologne.de>:
>> As I already written some time ago, the solution is to introduce a
>> hint/warning for the circular dependencies in implementation sections.
>> This hint should probably be disabled by default, for compatibility reasons.
>
> Yes, a hint would be nice.
> But a hint won't be enough. It would go unnoticed too easy.
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.
--
Alexander S. Klenin
_______________________________________________
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
