Journal Articles
Browse in : |
All
> Journals
> CVu
> 125
(21)
All > Topics > Programming (877) Any of these categories - All of these categories |
Note: when you create a new publication type, the articles module will automatically use the templates user-display-[publicationtype].xt and user-summary-[publicationtype].xt. If those templates do not exist when you try to preview or display a new article, you'll get this warning :-) Please place your own templates in themes/yourtheme/modules/articles . The templates will get the extension .xt there.
Title: Undefined vs. Implementation Defined
Author: Administrator
Date: 03 September 2000 13:15:40 +01:00 or Sun, 03 September 2000 13:15:40 +01:00
Summary:
Body:
In an article, I recently found some code like:
delete this; // ... this->other.count-;
Of course, it was not so easy to spot, but was hidden in some function calls, but the effect was the same: the object was used after deletion. By doing so, the author entered the realm of undefined behaviour. (Note: delete this; is not a problem as long as you do not use the object afterwards.)
The author of the code probably tested it and it worked fine, and this is exactly the problem of "undefined behaviour". Undefined behaviour cannot be tested. It still is undefined.
On the Internet, there are often jokes about undefined behaviour like: "The program might unplug the computer and shoot it to the moon." Of course, you and I, we know that such things do not happen. The real problem is: if you see something that is undefined but it behaves the way you want (and you tested it), you still cannot be sure about this behaviour. While it might run 99 times correctly (or 9999 times), the next time it might fail. The same program. The same executable. And if you recompile it, it might do completely different things.
The recompile point leads us to something that looks similar, but is in fact completely different: "Implementation defined".
E.g. sizeof(int) is implementation defined. You can test it, and if it works the way you expect, it is guaranteed to work always the same way. You can even recompile it - as long as you use exactly the same compile options. E.g. the alignment or padding of struct members is implementation defined and will probably differ even with the same compiler, dependent whether you optimise for speed or for size. So you should better look it up in the documentation of the compiler, if you use implementation defined behaviour.
So, the bottom line is:
Never use undefined behaviour, even if you tested it. You can never be sure.
If you use implementation defined behaviour, your code might not be portable, not even with the same compiler, but as long as you follow the documentation of your compiler, you're on the safe side.
Notes:
More fields may be available via dynamicdata ..