«

Stephen Howe wrote:
> is this legal?

Don't have a quote from the Standard ready, but somehow I recall that
it's not legal. Look through the archives for "instantiate templates
incomplete types C++" (or something like that, without quotes).

> // Start Header File TEST.h
> #include <vector>
>
> class CTest
> {
> public:
> CTest();
> ~CTest();
>
> private:
> struct Incomplete;
> std::vector<Incomplete> Vec_;
>
> private:
> CTest(const CTest &);
> CTest &operator = (const CTest &);
> };
> // End Header File TEST.h
>
> I wasnt sure of the position of incomplete types with standard containers.
> VS2005 does not seem to mind but that is not a benchmark.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

* Stephen Howe:
> On Tue, 02 Feb 2010 13:59:58 -0500, Victor Bazarov <> wrote:
>
>> Stephen Howe wrote:
>>> is this legal?
>> Don't have a quote from the Standard ready, but somehow I recall that
>> it's not legal. Look through the archives for "instantiate templates
>> incomplete types C++" (or something like that, without quotes).
>
> Thanks Victor. It is not legal
>
> I found Matt Austerns article here
>
> The Standard Librarian: Containers of Incomplete Types
> http://www.drdobbs.com/cpp/184403814
>
> which is useful and good except I dont beleive he is right on one point.
>
> You can have function declarations (not definitions) where the arguments
> and return type are incomplete types.

Yes.

To be precise, Matt Austern, then chair of the library working group of the C++
standardization committee, wrote "You can't pass or return incomplete types by
value, for the same reason that you can't define variables of an incomplete
type.", in the context of function declarations, and that's wrong.

Another case of a well-known expert getting this wrong is the GOTW on PIMPL,
where Herb Sutter, chair of the standardization committee, used std::auto_ptr
with incomplete type...

From which we might conclude that committee chairs don't go well with
incomplete types.

Or, there's something there.


Cheers,

- Alf

Alf P. Steinbach wrote:
>
> Another case of a well-known expert getting this wrong is the GOTW on
> PIMPL, where Herb Sutter, chair of the standardization committee, used
> std::auto_ptr with incomplete type...
>
> From which we might conclude that committee chairs don't go well with
> incomplete types.
>
I think that there was discussion about pimpl idiom (several years ago),
incomplete types and auto_ptr. As I remember catch was that destructor
of envelope class has to be in implementation file where definition of
type was visible, as if not, then, auto_ptr deletes incomplete type.

Greets

On Feb 2, 9:34 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
> Alf P. Steinbach wrote:

> > Another case of a well-known expert getting this wrong is
> > the GOTW on PIMPL, where Herb Sutter, chair of the
> > standardization committee, used std::auto_ptr with
> > incomplete type...

> > From which we might conclude that committee chairs don't go
> > well with incomplete types.

> I think that there was discussion about pimpl idiom (several
> years ago), incomplete types and auto_ptr. As I remember catch
> was that destructor of envelope class has to be in
> implementation file where definition of type was visible, as
> if not, then, auto_ptr deletes incomplete type.

That's not the issue, at least not formally. The standard
clearly says that it is undefined behavior to instantiate any of
the templates defined in the standard over an undefined type.
Typically, auto_ptr will only need to know the complete type in
the destructor, and you will get away with it if the destructor
of the pimpl is not inlined. But that's just a case of
undefined behavior happening to work, and you won't get away
with it if the implementation uses concepts. (And the next
version of the standard will, I think, require a diagnostic. At
least if concepts make it in.)

--
James Kanze

On Feb 2, 2:30*pm, James Kanze <james.ka...@gmail.com> wrote:
> On Feb 2, 9:34 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
>
> > Alf P. Steinbach wrote:
> > > Another case of a well-known expert getting this wrong is
> > > the GOTW on PIMPL, where Herb Sutter, chair of the
> > > standardization committee, used std::auto_ptr with
> > > incomplete type...
> > > From which we might conclude that committee chairs don't go
> > > well with incomplete types.
> > I think that there was discussion about pimpl idiom (several
> > years ago), incomplete types and auto_ptr. As I remember catch
> > was that destructor of envelope class has to be in
> > implementation file where definition of type was visible, as
> > if not, then, auto_ptr *deletes incomplete type.
>
> That's not the issue, at least not formally. *The standard
> clearly says that it is undefined behavior to instantiate any of
> the templates defined in the standard over an undefined type.
> Typically, auto_ptr will only need to know the complete type in
> the destructor, and you will get away with it if the destructor
> of the pimpl is not inlined. *But that's just a case of
> undefined behavior happening to work, and you won't get away
> with it if the implementation uses concepts. *(And the next
> version of the standard will, I think, require a diagnostic. *At
> least if concepts make it in.)

Could you explain this to me then? Why was it ever allowed to delete a
pointer to an incomplete type? As I understand it, the compiler must
already know if the type is complete or incomplete. It has to know
which destructor to call at compile time. If it can always detect it,
and it's always an error (aka undefined behavior), why not require a
diagnostic instead of call it undefined behavior? Dittos for deleting
a void pointer. Why allow that? I've hit numerous bugs and wasted a
lot of time tracking down memory leaks because of this IMO silly
mistake in the standard, and because of lack of QoI in modern
commercial compilers. At least gcc will issue warnings about these two
cases with the proper flags, so the script calling gcc can check the
log for these warnings and fail the build. Visual studios
unfortunately will not even issue a warning in one of these cases even
with all of the relevant flags enabled.

James Kanze wrote:
> That's not the issue, at least not formally. The standard
> clearly says that it is undefined behavior to instantiate any of
> the templates defined in the standard over an undefined type.
> Typically, auto_ptr will only need to know the complete type in
> the destructor, and you will get away with it if the destructor
> of the pimpl is not inlined. But that's just a case of
> undefined behavior happening to work, and you won't get away
> with it if the implementation uses concepts. (And the next
> version of the standard will, I think, require a diagnostic. At
> least if concepts make it in.)

I have no idea what are concepts, but does it mean that the compilation
of the code using pimpl is going to fail with the c++0x?

On Feb 2, 11:25 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> On Feb 2, 2:30 pm, James Kanze <james.ka...@gmail.com> wrote:
> > On Feb 2, 9:34 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
[...]
> Could you explain this to me then? Why was it ever allowed to
> delete a pointer to an incomplete type?

No, I can't explain it. It seems as incongruous to me as it
does to you. IMHO, it should be an error, requiring a
diagnostic.

--
James Kanze

On Feb 3, 8:39 am, Vladimir Jovic <vladasp...@gmail.com> wrote:
> James Kanze wrote:
> > That's not the issue, at least not formally. The standard
> > clearly says that it is undefined behavior to instantiate
> > any of the templates defined in the standard over an
> > undefined type. Typically, auto_ptr will only need to know
> > the complete type in the destructor, and you will get away
> > with it if the destructor of the pimpl is not inlined. But
> > that's just a case of undefined behavior happening to work,
> > and you won't get away with it if the implementation uses
> > concepts. (And the next version of the standard will, I
> > think, require a diagnostic. At least if concepts make it
> > in.)

> I have no idea what are concepts, but does it mean that the
> compilation of the code using pimpl is going to fail with the
> c++0x?

Not if you do it right. (And concepts are simply a means of
getting improved compile time error checking from templates.
The standard says, for example, that a type used to instantiate
std::vector must be assignable and copiable: without concepts,
you don't get an error until you try to instantiate one of the
functions which actually assigns or copies; with concepts, you
can get an error any time you try to instantiate the vector.)

--
James Kanze

On Feb 3, 5:16 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> James Kanze wrote:
> > That's not the issue, at least not formally. The standard
> > clearly says that it is undefined behavior to instantiate
> > any of the templates defined in the standard over an
> > undefined type. Typically, auto_ptr will only need to know
> > the complete type in the destructor, and you will get away
> > with it if the destructor of the pimpl is not inlined. But
> > that's just a case of undefined behavior happening to work,
> > and you won't get away with it if the implementation uses
> > concepts. (And the next version of the standard will, I
> > think, require a diagnostic. At least if concepts make it
> > in.)

> boost::shared_ptr doesn't require for the type to be complete.
> Since the new standard will include a similar smart pointer,
> will it lose that feature?

I don't think so. IIRC, the wording in the latest draft I saw
said that this case was undefined, unless otherwise specified.
And the description of shared_ptr specified otherwise. (But I
think it's about the only template which did.)

--
James Kanze

On Feb 3, 5:32 pm, "Leigh Johnston" <le...@i42.co.uk> wrote:
> "Juha Nieminen" <nos...@thanks.invalid> wrote in message

[...]
> I
> asked a question elsewhere about the status of auto_ptr. It seems to be
> quite common to use auto_ptr to implement the pimpl idiom.

Does it? My thoughts here are: why bother. You still need an
out of line destructor, and if you have to write a destructor
anyway, what's the problem with putting a delete in it, and
using a raw pointer. The whole point of the compilation
firewall idiom is to reduce include file dependencies, and any
smart pointer will require at least one extra include file.

--
James Kanze