Alternatywne schematy wdrażania vptr?
To pytanie nie dotyczy samego języka C ++ (tj. Nie o standardzie), ale o tym, jak wywołać kompilator w celu wdrożenia alternatywnych schematów funkcji wirtualnej.
Ogólny schemat implementacji funkcji wirtualnych polega na użyciu wskaźnika do tabeli wskaźników.
<code>class Base { private: int m; public: virtual metha(); }; </code>
ekwiwalentnie w C oznacza coś takiego
<code>struct Base { void (**vtable)(); int m; } </code>
pierwszy element to zwykle wskaźnik do listy funkcji wirtualnych itp. (fragment obszaru w pamięci, nad którym aplikacja nie ma kontroli). W większości przypadków zdarza się to kosztem rozmiaru wskaźnika przed rozważeniem elementów itd. Tak więc w 32-bitowym schemacie adresowania około 4 bajty itd. Jeśli utworzyłeś listę 40k obiektów polimorficznych w swoich aplikacjach, jest to około 40k x 4 bajty = 160 tys. Bajtów przed dowolnymi zmiennymi składowymi itp. Wiem też, że jest to najszybsza i najczęstsza implementacja wśród kompilacji C ++.
Wiem, że jest to skomplikowane przez wielokrotne dziedziczenie (szczególnie w klasach wirtualnych w nich, np. W strukturze diamentu itp.).
Alternatywnym sposobem zrobienia tego samego jest posiadanie pierwszej zmiennej jako identyfikatora indeksu do tabeli vptrs (równoważnie w C, jak poniżej)
<code>struct Base { char classid; // the classid here is an index into an array of vtables int m; } </code>
Jeśli całkowita liczba klas w aplikacji jest mniejsza niż 255 (łącznie z wszystkimi możliwymi instancjami szablonów itp.), To char jest wystarczająco dobry, aby pomieścić indeks, zmniejszając w ten sposób rozmiar wszystkich klas polimorficznych w aplikacji (wykluczam problemy z wyrównaniem itp.)
Moje pytania brzmią: czy w GNU C ++, LLVM lub innym kompilatorze jest jakiś przełącznik? lub zmniejszyć rozmiar obiektów polimorficznych?
Edytuj: Rozumiem o wskazanych kwestiach wyrównania. Ponadto, jeśli był to system 64-bitowy (zakładając 64-bitowy vptr) z każdym polimorficznym członkiem obiektu kosztującym około 8 bajtów, koszt vptr wynosi 50% pamięci. Dotyczy to głównie małych polimorfizmów utworzonych w masie, więc zastanawiam się, czy ten schemat jest możliwy dla co najmniej konkretnych obiektów wirtualnych, jeśli nie dla całej aplikacji.