I wouldn't put parens on a * b + c because I have that bit of
precedence memorized. I guess I have the comparison operators
memorized in the same way because mixing them doesn't bother me. At
some point we have to expect people have the rules internalized, yes?
It's a little beside the point, but often checking so many variables
at once is sometimes a sign that the design could be improved. For
instance, for 'x < a && a <= y' type stuff I usually use a Range
object (and I can be sure I'm consistently half-open). In the
num_screens case, it's changed now, but there was some weird stuff
where if screen==0 the dimensions are from Fl::x() etc. and if it's >0
then it's from the screens array.
So I'd say, don't worry about the parens, but fix the underlying
problem f you can :)
On Fri, May 27, 2011 at 3:55 AM, Albrecht Schlosser
<ajs856s...@go4more.de> wrote:
> On 27.05.2011 10:43, MacArthur, Ian (SELEX GALILEO, UK) wrote:
>
>> As I was reviewing the recent commits, I was looking at this line of
>> code:
>>
>> + if (num_screens> 0&& n>= 0&& n< num_screens&& screens) {
>
> [...]
>
>> It's not just me - recent versions of gcc whine on about this too!
>
> Really? I can only remember having seen gcc warnings if you combine
> '&&' and '||' (where '&&' takes precedence over '||' anyway, and
> we "fixed" all *these* warnings already).
>
> Albrecht
> _______________________________________________
> fltk-dev mailing list
> fltk-dev@easysw.com
> http://lists.easysw.com/mailman/listinfo/fltk-dev
>
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
