Re: Can a well-formed program incur undefined behaviour?
On 2011-01-25 10:57, Johannes Schaub (litb) wrote:
James Kanze wrote:
On Jan 19, 9:52 am, "Johannes Schaub (litb)"<schaub-johan...@web.de>
wrote:
jord...@gmail.com wrote:
[...]
I can't find where the spec says what happens if a precondition of a
Requirement expression is violated, but I think behavior is undefined,
which would mean you don't violate a diagnosable rule.
?17.4.3.8:
Violation of the preconditions specified in a function?s
Required behavior paragraph results in undefined
behavior unless the function?s Throws paragraph
specifies throwing an exception when the precondition is
violated.
Doesn't apply. There is no "Required behavior:" paragraph on the tables for
the various requirement tables, like ForwardIterator or CopyConstructible.
Some of the requirements don't even necessiate functions.
vector<int>::iterator *p = vector.end();
int i = *p; // no function involved!
Where is the consequence of dereferencing a past-the-end iterator stated?
In the end everything is undefined, which is not properly defined ;-)
Table 107 ? Input iterator requirements lists preconditions, among these for the expression '*a':
pre: a is dereferenceable.
In the context of the table header it seems quite clear that pre is a short-cut for 'precondition'. Further:
[input.iterators] p. 1 says:
"A class or a built-in type X satisfies the requirements of an input iterator for the value type T if X satisfies the Iterator (24.2.2) and EqualityComparable (Table 33) requirements and the expressions in Table 107 are valid and have the indicated semantics."
This is a binding requirement for all types satisfying the input iterator requirements (and since there are no stronger guarantees for the refined forms, they hold for vector<int>::iterator as well).
23.2.1 p. 6 says that end() returns a past-the-end iterator and 24.2.1 p. 5 describes the past-the-end state. The somewhat weak descriptions of 24.2.1 imply that past-the-end iterator values have no guarantee to be dereferencable. In the absence of such a guarantee attempting to dereference such a beast is undefined behaviour.
This should be sufficiently clear IMO.
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]