Zitat von Alexander Klenin <kle...@gmail.com>: > 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).
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. > 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. 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. > 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. ... or because they considered an even bigger picture than you. > 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. Wrong list. Lazarus will not change the compiler. > [1] FPC issues this warning even in Delphi mode, which is an outright bug. Mattias _______________________________________________ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus