Dotaz: Potomek tridy s implementaci v .so knihovne

[luky]

Potrebuju napsat potomka ke cryptopp::CascadableOStreamBuffer, ktereho potom pouziji v retezci buferu v cryptopp, mam ale problem s linkovanim - umre to na:

undefined reference to `typeinfo for cryptopp::CascadableOStreamBuffer'

Problem umim vyresit tak, ze smazu z Makefile cryptopp "-no-rtti" prepinac v CXXFLAGS, nicmene to zpusobi, ze libcrypto++ zacne zaviset na dalsich sdilenych knihovnach a musim rucne vynutit instance nekterych sablon. Zajimalo by me, jestli jde nejak presvedcit g++ aby vygenerovalo rtti jeste jednou v nejakem mem modulu pripadne jine reseni, ktere nevyzaduje zasah do te sdilene knihovny. THX

Odpovědi

[luky]

Tak jsem si to vyresil a kompiluju i svuj kod s -no-rtti, takze nezavisi na rtti nadrazenych trid.

[Sten]

Pokud nepotřebujete dynamic_cast, pak nepotřebujete RTTI (GCC generuje RTTI pro výjimky i s -fno-rtti).

Pokud ale RTTI (dynamic_cast) potřebujete, pak to lze řešit dvěma způsoby:

1. použít tu instanci jako výjimku a donutit tak GCC vygenerovat patřičné RTTI (nebude fungovat spolehlivě, pokud to nebude výjimka od stvoření!)

   try {
       nejakaFunkcePouzivajiciThrowMistoReturn();
   } catch (TridaProPretypovani &instance) {
       // Jako když se povede dynamic_cast
   } catch (...) {
       // Jako když dynamic_cast selže
   }
   

2. vygenerovat RTTI definováním nějaké metody z té třídy, typicky virtuálního destruktoru. Volat skutečnou implementaci ale potom vyžaduje šachování s linkerem:

   Class::~Class()
   {
       static void(Class::*orig)() = reinterpret_cast<void(Class::*)()>(dlsym("_ZN5ClassD2Ev", RTLD_NEXT));
       this->*orig();
   }
   

[luky]

Muj kod je jen jednoduche lepitko mezi transformacnimi funkcemi v C a knihovnou cryptopp, nikde v mem kodu ani v knihovne se dynamic_cast nepouziva, ani se objekt nevyhazuje jako vyjimka, takze me prekvapilo, ze tam to RTTI vubec je a zacal jsem si myslet, ze je potreba pro volani virtualnich metod (a to jsem si byl jisty, ze se pred par lety na to pouzival symbol vtable).

Muj problem byl v tom, ze RTTI gcc generuje pro vsechny objekty (pokud nepouzijete -no-rtti) a kdyz nemate RTTI pro predka, tak se RTTI potomka neslinkuje. Ja jsem cekal, ze kdyz se to RTTI nepouziva, tak ho proste linker zahodi.

Kazdopadne diky moc za info, jak to vyresit i v pripade potreby toho RTTI.

[Ivan]

No asi jsem mimo, ale i kdyz je predek uplne abstrakni tak by mel mit virtualni destruktor. Kdyz uz mas alespon jednu virtualni metodu implementovanou tak mas i RTTI pro predka.

[Ivan]

Pokud napises:

class AbsInterface {
 ...
 virtual ~AbsInterface {};
 ...
};

Tak se pro destruktor vygeneruje RTTI a zaroven bude kod destruktoru weak symbol. Tzn ten symbol bude jak v hlavni aplikaci a tak i v .so knihovne a zadnou kolizi to nezpusobi.

[Sten]

Oboje jsou tabulky ukazatelů, ale jsou trochu odlišné. vtable ukazuje na RTTI dané třídy a na jednotlivé virtuální metody, RTTI ukazuje na RTTI předků dané třídy, jméno třídy a umí down-casting (oddělené to je kvůli vícenásobné a virtuální dědičnosti, kdy je ukazatelů na stejné RTTI v jedné vtable více). Protože je ukazatel na RTTI uložen ve vtable, tak linker nepozná, že se to může vyhodit.

[little.owl]

Ten druhy bod je neskutecna cunarna.

[Ivan]

Na tohle pouzivam abstraktni tovarnu na objeky z knihovny Loki. http://codewrangler.home.comcast.net/~codewrangler/utility/factory.h Kod je na Linuxu nutne prelozit s optionen -rdynamic. Implementace tridy je v knihovne. Nepotrebuju zadny dlsym, ani manglovani jmen, kazda knihovna ma staticky inicializator a ten zajisti vse potrebne. Nova instance tridy se vyrobi takhle:

Lexer *l = LexerFactTwoParmSing::Instance().create("OracleGuiLexer", filename);

"OracleGuiLexer" - je "jmeno" tridy s implementaci(pod kterym byla zaregistrovana).
filename je 1. parametr pro konstruktor.