gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Changes to NSTableView wont compile


From: Nicola Pero
Subject: Re: Changes to NSTableView wont compile
Date: Mon, 18 Mar 2002 16:21:28 +0000 (GMT)

Thanks - I think Pierre-Yves just forgot some unfinished or experimental
code there - I made the little tweak so that it compiles again on CVS.

> Hi Pierre,
> 
> the dragging changes you made to NSTableView wont compile with gcc 2.93 
> or any other compiler that wont allow you to mix declareations and other 
> code. To get it working the beginning of the draggingUpdated: method 
> should read:
> 
> - (unsigned int) draggingUpdated: (id <NSDraggingInfo>) sender
> {
>    NSPoint p = [self convertPoint: [sender draggingLocation] fromView: nil];
>    NSRect newRect;
>    NSTableViewDropOperation operation = NSTableViewDropAbove;
>    int row;
>    int quarterPosition = (p.y - _bounds.origin.y) / _rowHeight * 4.;
>    unsigned dragOperation;
> 
> 
> I also did notice that other parts of this file do create warnings from 
> the gcc, please remove them (tey are mostly unused variables). It would 
> be great if all of GNUstep could compile without giving warnings, 
> currenlty this is not possible because of the exception handling code, 
> but for the rest we should try and get them away.

Yes - we should not be religious about warnings - they are not necessarily
harmful - but yes well written code should compile with -Wall and not
produce any warnings (which just means all the warnings have been
considered, and, if harmful, fixed; if harmless, the code has been tweaked
to make them disappear), so code which does not produce warnings under
-Wall is generally appreciated. :-)  We currently compile the whole gui
with -Wall.

I must say that there is also a gcc specific issue here - when you compile
with debug=yes that will actually hide some of the warnings because (no
matter what -Wxxx options you give the compiler) gcc can only track usage
of variables if it performs flow analysis, which is only done when
optimizations are used (I consider that a gcc strange behaviour).

In other words, debug=yes turns off optimizations, which turns off flow
analysis, which disables warnings for usage of variables (which are pretty
important).  To get all the warnings, you should compile without
debugging.

This means that people compiling with debugging disabled see more warnings
than people compiling with debugging enabled.

Perhaps Pierre-Yves was compiling with debugging enabled, while you are
compiling with debugging disabled, so he didn't see all the warnings you
see.

Anyway - I suggest that people from time to time try to compile without
debugging, and try to address the warnings they see.  That without being
too anal about warnings ... removing warnings is a good idea, and can help
making the software better, but the important thing is that the software
is good, the fact that it doesn't generate warnings is just a side issue.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]