| ??? 07/07/08 16:49 Read: times |
#156487 - How broken things work Responding to: ???'s previous message |
Anyway, but what you would expect. Optimized code is smaller and faster (Hopefully) that shows up timing issues. Sharing of the memory since the compiler thinks it is unused, but you are using it anyway. The any change problem. "My code works" "But if I change.... It does not" this can be optimization add or delete code. If you have a hole and move stuff around and something will fall in.
In the end it is debugging. If it does not work you need to track it down. You thing newbies have it bad? Put a few years in and you will speed some time tracking down a bug in the compiler that you are sure must be your mistake. |
| Topic | Author | Date |
| Why Is Debugging Optimized Code Such an Issue? | 01/01/70 00:00 | |
| Usually not | 01/01/70 00:00 | |
| False Assumptions | 01/01/70 00:00 | |
| "language specification" ?? | 01/01/70 00:00 | |
| Do not assume it is that easy | 01/01/70 00:00 | |
| Common Stuff Leading To Errors | 01/01/70 00:00 | |
| "common stuff" falling apart when optimized | 01/01/70 00:00 | |
| How broken things work | 01/01/70 00:00 | |
| It is not like that | 01/01/70 00:00 | |
| A bad workman blames his tools | 01/01/70 00:00 | |
| A common side effect of optimisation | 01/01/70 00:00 | |
| Newbies | 01/01/70 00:00 | |
| another good reason | 01/01/70 00:00 | |
| a rule of thumb | 01/01/70 00:00 | |
| excellent advice, however - and | 01/01/70 00:00 | |
| Defeatist? | 01/01/70 00:00 | |
| Or turn it down as needed | 01/01/70 00:00 | |
| Using Pragmas During Debugging | 01/01/70 00:00 | |
| Free lunch? | 01/01/70 00:00 | |
| a dream | 01/01/70 00:00 | |
| If it were easy everone would be doing it. | 01/01/70 00:00 | |
you can't | 01/01/70 00:00 |