[ Date Prev][ Date Next][ Thread Prev][ Thread Next][ Date Index][ Thread Index]
Re: Mangling: Special names
- To: Martin von Loewis <loewis@xxxxxxxxxxxxxxxxxxxxxxx>
- Subject: Re: Mangling: Special names
- From: dehnert@xxxxxxxxxxxxxxxxxxxx (Jim Dehnert)
- Date: Mon, 27 Mar 2000 19:44:33 -0800 (PST)
> From loewis@xxxxxxxxxxxxxxxxxxxxxxx Mon Mar 27 06:05:59 2000
>
> No, that won't work. Is this the in-charge, or not-in-charge
> constructor? Is it allocating or not?
>
> Reconsidering this, I think it is right to have the special names as
> unqualified names in a nested name. Just as you'd have
>
> _ZN3FoongE
>
> to denote Foo::operator!(); you also have C1,... as *names* of the
> constructors. Since we need more than one name per constructor, we
> need to make them special
Yes, I think you're right. I've changed it.
> > > Likewise, _ZN3Foo3BarTVE would be the Foo::Bar virtual table.
> >
> > No, it goes:
> >
> > <encoding> -> _Z <name> <type>
> > -> _Z <special-name> <class-enum-type>
> > -> _Z TV <nested-name>
> > -> _Z TV N 3Foo 3Bar E
>
> In my view, the Foo::Bar virtual table is a static member of Foo::Bar,
> which would be written down as 'Foo::Bar::__vtable'. Just as this
> specific member would be encoded as
>
> _ZN3Foo3Bar8__vtableE
>
> I would assume that the vtable is encoded with TV as the name of the
> static member. Your approach would also work, but I feel this is more
> consistent that way.
Hmmm, I hadn't thought of it that way. Your method would work, too,
though sometimes it would result in extra N...E delimiters, as in the
vtable for a simple class Foo, which would become _ZN3FooTVE instead of
_ZTV3Foo. Not a huge difference -- does anyone else have an opinion?
Jim
- Jim Dehnert dehnert@xxxxxxx
(650)933-4272
|