[cxx-abi-dev] Deleted virtual functions

[Dennis Handly]

>From: Sean Perry <perry at ca.ibm.com>
>Another area I've had concerns about is the comparison for equality of the
>typeid operator (2.9.3).  There is a statement that doing a straight
>address comparison is sufficient for testing equality.  That doesn't always
>work when you considered shared libraries.

Yes, we had issues with customers porting and we told them tough, you
must make the symbols visible.  (See Mark's comments.)  We fiddled with
compiler options and made it hard to hide compiler generated class metadata.

>  I am sure one of the python
>boost failures for xlC on linux is because the two sides of a comparison
>aren't resolving to the same object as you would expect.  I was initially
>worried about systems like AIX where runtime symbol resolution wasn't the
>norm
Sean Perry

Of course a big important customer came along and we did this:
_HP_ACC_TI_STRING_COMPARE is always on in our runtime lib.

  bool operator== (const type_info& __arg) const
    { return __name == __arg.__name
#if defined(__ia64) && defined(_HP_ACC_TI_STRING_COMPARE)
      || do_string_compare && strcmp(__name, __arg.__name) == 0
#endif
       ; }

#if defined(__ia64) && defined(_HP_ACC_TI_STRING_COMPARE)
  static int do_string_compare;
#endif

>From: Mark Mitchell <mark at codesourcery.com>
>other people don't.  For example, when building plugins, you often want
>each shared library to be completely independent; if my plugin's "class
>Plugin" is the same as your plugin's "class Plugin", very bad things happen.

They should use lawyers to solve this, not engineers.  ;-)

We had to tell another important customer over and over this violated the
ODR rule.  And our above changes making it hard to hide these classes
caused them issues.  They didn't want to use the mangled name for many
classes.  They finally accepted our reasoning, since other vendors had
to use kludges too.  :-)

>If you do, then the dynamic linker can merge the
>addresses, and the types are "the same".  If you don't, then they're
>not.  The programmer gets to choose.

Right, provided he has enough documentation.

>On other systems (e.g., DLL-based systems) you have no choice but to use
>string comparison.  In that case, you'll lose in the plugin case.
Mark Mitchell

Has anyone reviewed the proposed new standard for C++ and shlibs?

Prem and I provided enough questions in the Hawaii meeting they pulled it.
Future directions in the standard should be thought out for the ABI.