Topic: Pointer to incomplete type in STL container fails.


Author: "Aaron S. Binns" <asbinn@rstcorp.com>
Date: 1997/11/20
Raw View
I checked all the on-line STL references I could find along with the
printed ones that I have and cannot find any information related to
the following problem.

    #include <vector.h>  // or <vector> depending on the
compiler/library

    class X;

    vector< X* > a_;

I've used a couple different compilers with different STL vendors, but
I always get an error on the line declaring a_ indicating that X
is an incomplete type.

I've tracked down the problem to the class vector and it's allocator.
The allocater calls a template non-member function like:

   template<class _Ty>
   inline
   void _Destroy(_Ty  *_P)
   {
     (_P)->~_Ty();
   }

   // More on these later
   inline void _Destroy(char  *_P)
 {}
   inline void _Destroy(wchar_t  *_P)
 {}

This one is from Plauger's implementation distributed with Microsoft
Visual C++ 5.0.  There is an extremely similar function in the
ObjectSpace STL implementation.

Anyways, what happens is that this function is instantiated with X* as
the template argument and you wind up with (effectively):

   void _Destroy( X*  *_P)
   {
     (_P)->~X*();
   }

And the compiler complains.

Oddly enough, instantiating a vector<T> of void* works, i.e.

    #include <vector.h>  // or <vector> depending on the
compiler/library

    vector< void* > a_;  // no problem!

I would have thought that the same problem with the template _Destroy
function would occur, as:

   void _Destroy( void*  *_P)
   {
     (_P)->~void*();
   }

But, for some reason I don't get any problems with template<void*>.
Could those two specializations for _Destroy(char*) and
_Destroy(wchar_t*) be allowing the _Destroy(void*) to work (by some
conversion??) ?


I guess my question boils down to:

   How can I put pointers to an incomplete type into a STL container?

If the answer is: You can, your implementations/compiler are/is broken.
I can live with it, is there a fix?

If the answer is: You can't.
Why not, it seems like a perfectly reasonable thing to do.


Aaron
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: paul@ra.avid.com (Paul Miller)
Date: 1997/11/21
Raw View
"Aaron S. Binns" <asbinn@rstcorp.com> writes:

>I checked all the on-line STL references I could find along with the
>printed ones that I have and cannot find any information related to
>the following problem.

[problem with forward-declared class types in STL containers removed]

The problem is a bug in Microsoft VC++. It NEEDS the class definition
that will be placed in the container. It also requires implementations
to be present for operator= even though it is never called.

The SGI MIPSPro compilers handle this case perfectly fine - since
template instantiation can be set to only the member functions that
are actually used.

As you can imagine this makes writing portable code between the two
compilers a real pain.

--
Paul T. Miller                | paul@elastic.avid.com
Principal Engineer            | Opinions expressed here are my own.
Avid Technology, Inc. Madison - Graphics and Effects Software Group
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]