Forgot your password?
typodupeerror

Comment: Re:Very different code (Score 2) 225

by drawfour (#45739783) Attached to: Comparing G++ and Intel Compilers and Vectorized Code
No. Just because something is legal according to the specification does not make it "right". The specification _should_ be restricted, but it cannot because there are a _lot_ of lines of code out there that would suddenly stop compiling. It _IS_ wrong to do 'if (a = b)' for a few reasons:

1. Someone else won't necessarily know that this was intended unless you have a comment telling them. That comment would take up just as much space as putting an 'a = b;' line before the 'if (a)' line.
2. If your compiler is not capable of optimizing and figuring out that 'if (a=b)' and 'a=b; if (a)' should generate the same machine code, then your compiler is a piece of crap and should be upgraded or replaced.
3. If you get in the habit of doing those kind of 'shortcuts', you are more likely to accidentally do the wrong thing. And since you're so used to that kind of programming, you're more likely to miss it when trying to track down the bug that you introduced. If 'if (a = b)' just looks wrong to you because you never use it, it is more likely to jump out at you when you're debugging, whether it's your own code or someone else's.

The same thing is true for casting ints to pointers, having fall-throughs in switch statements, signed/unsigned mismatches, and a myriad of other "legal" but "just-as-wrong" things.

Comment: Re:Very different code (Score 3, Insightful) 225

by drawfour (#45738229) Attached to: Comparing G++ and Intel Compilers and Vectorized Code
There is a reason for warnings -- it's because you're doing something wrong. Unfortunately, the compiler lets you do it anyway, probably because there is a ton of legacy code that would suddenly "break" if they were errors by default. But that doesn't mean that you should stop trying to fix these issues. Many of these issues only appear to be benign until you stumble upon the exact issue the warning was trying to warn you about. Static code analysis tools are also your friend. That doesn't mean you can blindly trust them -- static analysis tools do have false warnings. But they're way better than inspecting the code yourself. You'll miss something way more times than the analysis tools will give you a false positive.

Comment: Re:Very different code (Score 4, Informative) 225

by drawfour (#45737389) Attached to: Comparing G++ and Intel Compilers and Vectorized Code
This is why all code should be compiled with highest warning level enabled, and all warnings should be treated as errors. The compiler can have a very hard time guessing at what you meant, so it's best to be as explicit as you can. If, for some reason, you're positive the code needs to be a certain way that is, and it is correct, you can always use a "pragma warning(disable)" (with appropriate push/pop semantics) to keep your code compiling clean.

Comment: Re:Jerry Was A Man (Score 1) 641

by drawfour (#45581861) Attached to: Lawsuits Seek To Turn Chimpanzees Into Legal Persons
Chimps can and do understand, they just have never been observed to understand it in the wild. http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2151757/

Elephants in the wild can understand human pointing. http://www.decodedscience.com/elephants-understand-pointing-better-chimps/38097

So, sure, chimps may not natively understand human pointing, but dogs only got that way because of thousands of years of selection of offspring that cohabit better with humans. Take a wolf and point, it won't understand.

Comment: Re:Agile is about commitment, not flexibility (Score 1) 221

by drawfour (#44247661) Attached to: Ask Slashdot: Development Requirements Change But Deadlines Do Not?
I like that yardstick analogy, mind if I use it?

Over the past few months, my org has moved from waterfall to scrum, and while the transition is painful for some people, I think it's really simple to grasp. We no longer have the 3-day meetings of adds/cuts to figure out what features we think we'll be able to ship in the next 2 years, we just have an idea of the bigger items we want to accomplish. Things that we need to do sooner rather than later are more detailed, such that we know whatever work we think we'll be doing over the next 2 sprints is very clear and detailed, with increasing fuzziness the further out we go.

We only work a sprint at a time (2 week schedule), make sure everything is as tested as we can before calling it complete. If we find gaps in our coverage before the sprint is complete, we fix them then and there (no checking in things with "known issues"). If we find gaps after the sprint was completed, we add them into our backlog for handling in the future, so we don't context switch out of our current work to service code. It's actually quite a blessing.

We're not a well-oiled machine yet (will take a while), but I think people are getting it more and more.

I don't think agile is necessarily the right tool for everyone or everything (I know some agile purists would disagree), but for the way we were doing waterfall before and all of the problems we felt year after year, I feel agile development is exactly what our org needed.

Comment: Re:And it still looks like (Score 2) 502

by drawfour (#43274741) Attached to: Windows Blue 9364 Screenshots Show Feature Enhancements
Yes, you are correct, as I already said. To quote myself:

Grammar is about the syntax and structure, not about the definition of the word.

I assume that you think that "syntax" means "definitions of the words", based on your reply, but if you look at the definition of the word syntax, you will see otherwise. Syntax is about the arrangement and interactions of words, not about the meanings of them.

No amount of genius can overcome a preoccupation with detail.

Working...