This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Can our C++ vectors hold derived classes?
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Mailing List <gcc at gcc dot gnu dot org>, Diego Novillo <dnovillo at google dot com>
- Date: Thu, 13 Jun 2013 10:31:28 +0200
- Subject: Re: Can our C++ vectors hold derived classes?
- References: <20130612172333 dot GG26236 at virgil dot suse> <CAFiYyc3vYi1XVXcpZn3fP46s8R85oiQu432aLe9G9hSQWWZ3JA at mail dot gmail dot com> <20130613081919 dot GC2336 at tucnak dot redhat dot com> <CAFiYyc1+2xy9USyHaYWRJkw-FD1+h4d4AZ7DOrYhYVz5KwPo9g at mail dot gmail dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, Jun 13, 2013 at 10:22:01AM +0200, Richard Biener wrote:
> On Thu, Jun 13, 2013 at 10:19 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> > On Thu, Jun 13, 2013 at 10:12:08AM +0200, Richard Biener wrote:
> >> > When I remove the ": public zzzA" part the earnings disappear. Thus,
> >> > it seems there is an error somewhere... or am I doing something wrong?
> >>
> >> I think you need to avoid using vl_embed vectors because their implementation
> >> uses offsetof.
> >
> > That is all of them though. vl_ptr uses vl_embed as its vec_ field.
>
> Oh ... ;)
>
> So I suppose we need to avoid the use of offsetof. But of course the whole
> way we construct vec_embedded vectors goes against C++ rules ...
>
> Thus indeed, we only support POD vector element types (we completely
> lack invocations of constructors and destructors for example).
That is probably because we use vec<something> also in contexts where
you can't use non-POD (e.g. va_arg (ap, vec<...>)). That is why vec itself
is a POD too.
Jakub