Is it generally safe to inherit from STL iterator classes?

[Kai-Uwe Bux]

Kai-Uwe Bux wrote: [snip]

I recall that some code that used to work
perfectly fine broke when my standard library incorporated concept checks
(however, my memory is notoriously unreliable and could be making this
up). At that point, I learned that the standard requires complete types
for the template arguments in many places even in cases where there there
are natural implementations that would not need that. I think, the
assumption that you can meaningfully derive from set::iterator is not
that different.

On the contrary: it is quite different. The C++ specification explicitly
says that you cannot use incomplete types in that context, so you
violated an express prohibition. There is no such prohibition on
deriving from std::const_iterator, and no reasonable implementation will
prevent that.

The standard explictly marks the type std::set::const_iterator as
implementation_defined. The cases may not be exactly parallel, but relying
on being able to derive from set::const_iterator is formally implementation
defined behavior.


Best

Kai-Uwe Bux

 

[Pete Becker]

Pete Becker wrote:


The standard explictly marks the type std::set::const_iterator as
implementation_defined. The cases may not be exactly parallel, but relying
on being able to derive from set::const_iterator is formally implementation
defined behavior.

Again: it is permissible for an implementation to make things difficult
for its users by making it hard or impossible to derive from various
types. It is also permissible to not do that, and that's the approach
taken by every implementation I'm aware of. Blocking inheritance means
writing and maintaining extra code for no clear benefit. That's not high
on my list of things to worry about.

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.