Re: [boost] [containers] Clarifications on incomplete type support?

Subject: Re: [boost] [containers] Clarifications on incomplete type support?
From: Mikael Persson (mikael.s.persson_at_[hidden])
Date: 2014-09-23 12:44:19

> I've found that PIMPL-like idioms might require at least some operations
(like the default constructor) to be incomplete type friendly.

Yes, that sounds reasonable. It could be reasonable to guarantee that
default constructors (and assignment, maybe) can be possible for incomplete
types. I guess in the same way as a pointer to an incomplete type can
provide some basic operations (create a pointer, init to NULL, copy the
pointer, etc.). It could make sense to just transpose whatever guarantees
the standard gives for pointers of incomplete type to the container and
iterator types as well. But I don't think it should or could go much beyond
that.

> Boost.Container has suffered a lot of changes recently, and it might
surely be a Boost.Container bug.

Actually, I investigated a bit, and the problem stems from a rather
embarrassing oversight on my part. I was using default-constructed
iterators as a kind of universal "null iterator". This means that my code
was riddled with undefined behavior as a consequence of that. It just
happened to work on Boost.Container containers prior to the SCARY iterator
changes. So, I was going to ask if it could be considered to add some
guarantee that default-constructed (value-initialized) iterators have a
well-defined "null" value (similar to default-constructed standard
stream-iterators). Then, I noticed that proposal n3644 proposes exactly
that, and it was accepted to C++14. See proposal "Null Forward Iterators":

http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2013/n3644.pdf

Therefore, this needs to be added to Boost.Container containers as well for
compliance with C++14. I would be happy to do it myself, but I'm afraid
that the whole under-the-hood iterator architecture used by Boost.Container
and Boost.Intrusive is too much for me to wrap my mind around just for a
purpose of adding a well-defined default-constructor. It should be a very
simple fix for someone who already knows the code-base well. Right?

Thanks,
Mikael.