4 ms·

Compilers are complex, and these conditionals had to be evaluated in some way. Sure the author could have split it up into multiple if statements, but would hav

by webkike 12y ago

Compilers are complex, and these conditionals had to be evaluated in some way. Sure the author could have split it up into multiple if statements, but would have that really helped?

adamnemecek 12y ago
Yes, yes it would have, there is literally no question about that. It also appears that some of the parts of the conditions are repeated, so those could have been refactored.
- laichzeit0 12y ago
  I'm sure a good optimizing compiler like GCC would optimize out repeated expressions in conditions ;) (perhaps not if they're declared volatile(?))
  - smcl 12y ago
    Definitely not if they're declared volatile
VMG 12y ago
You could pull out boolean subexpressions and give them descriptive names and still use one if statement. It's even in the Google C++ style guide I believe.
frozenport 12y ago
`if` statements are for the 80s, we live in in the 90s and have objects, inheritance and C++. The conditions can be implicit in the objects.
- jblow 12y ago
  I don't even.
  - fennecfoxen 12y ago
    A qualified defense of the grandparent post. In a lot of software in the industry I've seen, I'd say he's right -- instead of an "if X condition, do X code, if U condition, do Y, otherwise do Z" you can make an object, subclass the object's base class into a default type doing Z and two other types that do X and Y instead. (If you need to share more behaviors in a more complicated setup, you make the strategies into classes as well, then have the X1 and X2 classes invoke the X strategy.) Happiness ensues! (unless you're stuck with too much ugly-looking Java boilerplate or insane C++ templatization angle-brackets) That said... any good advice like that should be taken with a MASSIVE grain of salt because of the exigencies of real software development, especially software like gcc. Moreover the approach is not a panacea against code complexity because sometimes the relationships between different types of conditions are just plain complicated, as appears to be the case here. So I can totally understand where this code is coming from, and while I can imagine it being far more elegant, it's not really the prime candidate for a rant. Grandparent post should chill out.

by webkike 12y ago

Compilers are complex, and these conditionals had to be evaluated in some way. Sure the author could have split it up into multiple if statements, but would have that really helped?

adamnemecek 12y ago

Yes, yes it would have, there is literally no question about that. It also appears that some of the parts of the conditions are repeated, so those could have been refactored.

laichzeit0 12y ago
I'm sure a good optimizing compiler like GCC would optimize out repeated expressions in conditions ;) (perhaps not if they're declared volatile(?))
- smcl 12y ago
  Definitely not if they're declared volatile

VMG 12y ago

You could pull out boolean subexpressions and give them descriptive names and still use one if statement. It's even in the Google C++ style guide I believe.

frozenport 12y ago

`if` statements are for the 80s, we live in in the 90s and have objects, inheritance and C++. The conditions can be implicit in the objects.

jblow 12y ago
I don't even.
- fennecfoxen 12y ago
  A qualified defense of the grandparent post. In a lot of software in the industry I've seen, I'd say he's right -- instead of an "if X condition, do X code, if U condition, do Y, otherwise do Z" you can make an object, subclass the object's base class into a default type doing Z and two other types that do X and Y instead. (If you need to share more behaviors in a more complicated setup, you make the strategies into classes as well, then have the X1 and X2 classes invoke the X strategy.) Happiness ensues! (unless you're stuck with too much ugly-looking Java boilerplate or insane C++ templatization angle-brackets) That said... any good advice like that should be taken with a MASSIVE grain of salt because of the exigencies of real software development, especially software like gcc. Moreover the approach is not a panacea against code complexity because sometimes the relationships between different types of conditions are just plain complicated, as appears to be the case here. So I can totally understand where this code is coming from, and while I can imagine it being far more elegant, it's not really the prime candidate for a rant. Grandparent post should chill out.