iterator error

[Pete Becker]

I couldn't find that definition. In fact, iterators are defined
operationally,
by the operations that they support.


That's an unfortunate term, which should be "sequence container",
just as we have "associative container" and "unordered container." And
it's clear from the way I used it that I wasn't referring to a sequence
container, but to a sequence in its more ordinary sense.


Exactly.

I should add, too, that many of the algorithms in the standard are
described as operating on sequences, but aren't restricted to sequence
containers.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

 

[James Kanze]

If something is IMPLEMENTATION DEFINED the implementation
is required to document what it is. If it is UNDEFINED
it is not required. Therefore, if behavior is UNDEFINED
in any allowable instance, it's UNDEFINED in general.

It can also be unspecified.

In this case, the standard pretty much says that anything you do
with the standard library that is not conform with the specified
requirements is undefined behavior.

--

 

[James Kanze]

Is it explicitly undefined (as in dereferencing a null pointer)?

Yes. The standard says that just about anything you do with the
library that isn't conform results in undefined behavior. There
are practically no requirements that e.g. a diagnostic be
emitted.

In practice, there's a lot of undefined behavior that will
either work, or result in a diagnostic, even if the standard
says it's undefined. The line `cout<<"ok!";' in the above
program, for example, is undefined behavior, since the code
fails to include the necessary header (<ostream>). But I can't
conceive of an implementation in which it either worked, or
failed to compile.

All I can see in the standard is that 'iterator' type in 'std::map'
is implementation-defined.

The type is implementation defined; most typically, it will be a
nested class or a typedef. The operations which it must support
are defined, however. And any attempt to do anything else with
it is undefined behavior.

Is it not conceivable that the type
might actually define comparison with 0?

The implementation might define it. That's one legal way of
handling undefined behavior. In the case of `cout<<"ok!"', for
example, both the g++ and the Dinkumware library define it; g++,
at least, has explicitly added code in <iostream> to make it
defined. And on my system, dereferencing a null pointer is
defined---the system guarantees an immediate core dump. But the
standard still says it is undefined, and I've used systems where
it could do some very strange things.