This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

operator==() of the type_info class


Hi,

my name is Joerg Budischewski, I am a Sun Microsystems employee working 
on OpenOffice (see http://www.openoffice.org) / StarOffice. I work on 
UNO,  the openoffice component model.

There is currently some effort underway to port the linux build of 
openoffice from gcc 2.95.2 to gcc 3.01. The results of the build are 
currently very promising (some shared libraries have shrinked in size by 
50-60%, you have done a great job !), though I can't give a final 
statement as the build has not finished yet (we e.g. need to change lots 
of code lines due to the harder check for exception specifications).

However, we have run into a problem I would like to discuss here.

The throwing of exceptions via shared library boundaries only works, when 
the shared library exports the exception's typeinfo symbol. This is due 
to that the type_info::operator==() is implemented by comparing the 
type_info-instances-pointers instead of comparing the type-names. 

In the version 2.95.2, there was an additional strcmp() for the names 
after the pointer comparision. 

In our case, we want to limit the exports of shared libraries to the 
absolute minimum (which are 3 C-functions for each shared library in our 
case). So every library has its own instance of the exception-typeinfo. 
This leads to the unexpected exception.

Though we could solve this by additinal exporting every type_info 
exception symbol, there may still arise a problem when the first library 
offering a certain exception symbol gets unloaded (dlclose()). The 
type_info for this certain type is then not available for other libraries 
anymore which may lead to segfaults.

So I would like to raise the question, why the strcmp() was removed ? The 
only thing I can think of is performance and codesize of the inline 
function, but I think both have only neglectable effect in case of 
exception throwing. 

Greetings, Joerg Budischewski


PS: If would like to cite Bjarne Stroustrup (The C++ programming 
language, 3rd edition, chapter 15.4.4 Typeid and extended type 
information )  on this topic : 

'It is not guaranteed that there is only one type_info object for each 
type in the systen. In fact, where dynamically linked libraries are used, 
it can be hard for an implementation to avoid duplicate type_info 
objects. Consequently we should use == on type_info objects to test 
equality, rather than == on pointers to such objects.'



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]