Re: Incomplete types and std::vector
On Feb 6, 1:23 pm, "Leigh Johnston" <le...@i42.co.uk> wrote:
[...]
Most uses of pimpl are as simple as this. I would be
skeptical of a design which had "multiple pimpl pointers".
The constructor body of Foo is generally that, no more, no
less, give or take the names. However, I suppose there's
nothing to lose by using std::auto_ptr either.
Not really, there is nothing wrong with a top-level "model"
class containing multiple objects that you don't want to
expose in the model header file to reduce dependencies and
compilation times.
There's nothing wrong with a top-level model class doing a lot
of things; most of the ones I deal with today contain things
like std::vector<double>, for example. But we were talking here
about the pimpl idiom. As defined by Herb Sutter. (Formally,
it's really the compilation firewall idiom, and before Herb
popularized it, it was often known as the Cheshire cat
idiom---named by Jim Adcock?) It's a very specific idiom.
I would think that it would be undefined behavior if
Foo::~Foo is defined in a scope where FooImpl is an
incomplete type. Interestingly enough, if I move the
Foo::~Foo definition to before the FooImpl class definition
in the same translation unit, a scope where FooImpl is an
incomplete type, visual studios 2008 still deletes it as a
complete type, which completely mystifies me. Is this visual
studios protecting me from myself, and making it "do the
right thing" in a case of undefined behavior? Or do I
completely fail at understanding the template instantiation
and name lookup rules?
Comeau complains if you do this so I wouldn't trust an
individual compiler's behaviour as to what constitutes
undefined behaviour or not.
The standard says that instantiating std::auto_ptr (or any
template defined in the standard) over an incomplete type is
undefined behavior). In this case, the standard probably could
have been a bit laxer, and only required a complete type where
the destructor was instantiated. But the standard having
specified this restriction, it wouldn't surprise me if some
compiler/library implementation enforced it. (G++ enforces a
lot of this sort of thing in its library implementation; I don't
know off hand if this particular case is covered or not,
however.)
--
James Kanze