Widoczność symboli, wyjątki, błąd runtime

Jestem autorem oryginalnego patcha do GCC dodającego obsługę widoczności klas, a moje oryginalne howto, które jest sklonowane GCC jest w http://www.nedprod.com/programs/gccvisibility.html . Dziękuję Vargadowi za wysłanie mi osobiście e-maila, aby powiedzieć mi o tym pytaniu.

Zachowanie, które obserwujesz, jest ważne dla ostatnich GCC, jednak nie zawsze tak było. Kiedy pierwotnie łatałem GCC w 2004 roku, złożyłem prośbę do Bugzilli GCC o porównanie środowiska wykonawczego obsługi wyjątków GCC typy rzucane przez string porównanie ich zniekształconych symboli zamiast porównywania adresów tych łańcuchów-zostało to odrzucone w tym czasie przez opiekunów GCC jako niedopuszczalny koszt wykonania, mimo że takie zachowanie robi MSVC, i pomimo tego wydajność podczas rzucania WYJĄTKÓW nie jest ogólnie uważana za ważną, biorąc pod uwagę, że są one rzadkie. Dlatego musiałem dodać specjalny wyjątek do mojego przewodnika widoczności, aby powiedzieć, że każdy wyrzucony Typ nigdy nie może być ukryty, nie raz, w binarnym jako " hiddenness "przebija" default", więc tylko jedna deklaracja ukrytego symbolu gwarantuje nadpisanie wszystkich przypadków tego samego symbolu w danym binarnym.

Co się stało potem chyba nikt z nas się nie spodziewał - KDE bardzo publicznie przyjęło moją funkcję. To kaskadowe w prawie każdym dużym projekcie wykorzystującym GCC w zadziwiająco krótkim czasie. Nagle ukrywanie symboli było normą, a nie wyjątkiem.

Niestety, niewielka liczba osób nie zastosowała mojego poradnika poprawnie dla typów wyrzuconych wyjątków, a także ciągłe raporty o błędnej obsłudze WYJĄTKÓW obiektów współdzielonych w GCC ostatecznie spowodowały, że opiekunowie GCC zrezygnowali i wiele lat później wprowadzili poprawki w porównywaniu łańcuchów dla dopasowania typu wyrzuconego, tak jak pierwotnie prosiłem. Stąd w nowszych GCCs sytuacja jest nieco lepsza. Nie zmieniłem przewodnika ani instrukcji, ponieważ takie podejście jest nadal najbezpieczniejsze na każdym GCC od v4. 0, a nowsze GCC są bardziej niezawodne w obsłudze wyjątek rzuca się z powodu używania porównywania łańcuchów, przestrzeganie zasad przewodnika tego nie zaszkodzi.

To sprowadza nas do problemu typeinfo. Dużym problemem jest to, że najlepsza praktyka C++ wymaga, aby zawsze dziedziczyć praktycznie w typach throwable, ponieważ jeśli skomponujesz dwa typy WYJĄTKÓW, oba dziedziczące (powiedzmy) z STD::exception, posiadanie dwóch równoodległych klas bazowych STD::exception spowoduje catch (STD:: exception&) do auto call terminate (), ponieważ nie może określ, która klasa bazowa ma być dopasowana, więc zawsze musisz mieć tylko jedną klasę bazową STD::exception i to samo uzasadnienie dotyczy każdej możliwej kompozycji typu throwable. Ta najlepsza praktyka jest szczególnie wymagana w każdej bibliotece C++, ponieważ nie możesz wiedzieć, co użytkownicy zewnętrzni zrobią z Twoimi typami WYJĄTKÓW.

Innymi słowy, oznacza to, że wszystkie wyrzucane typy WYJĄTKÓW w najlepszych praktykach zawsze będą miały łańcuch kolejnych RTTI dla każdej klasy bazowej, a ten wyjątek dopasowanie jest teraz przypadkiem wewnętrznego wykonania udanej operacji dynamic_cast do dopasowanego typu, operacji o (liczba klas bazowych). A żeby dynamic_cast pracował nad łańcuchem wirtualnie dziedziczonych typów, zgadliście, trzeba każdego tego łańcucha mieć domyślną widoczność. Jeśli nawet jeden jest ukryty przed kodem wykonującym catch (), cały caboodle idzie w górę i dostajesz terminate (). Byłbym bardzo zainteresowany, gdybyś przerobił powyższy przykładowy kod na wirtualnie i zobacz co się stanie - jeden z twoich komentarzy mówi, że odmawia linkowania, co jest świetne. Ale załóżmy, że DLL A definiuje typ A, podklasy DLL B Typ A na B, podklasy DLL C Typ B na C, a program D próbuje złapać wyjątek typu A, gdy Typ C został wyrzucony. Program D będzie miał dostępną informację o typie a, ale powinien być błędny podczas próby pobrania RTTI dla typów B i C. Może jednak ostatnie GCC też to naprawiły? Nie wiem, moja uwaga w ostatnich latach jest na clang jako to przyszłość dla wszystkich kompilatorów C++.

Oczywiście jest to bałagan, ale jest to bałagan specyficzny dla elfów - nic z tego nie wpływa na PE lub MachO, z których oba uzyskują wszystkie powyższe prawa, nie używając globalnych tabel symboli procesów w pierwszej kolejności. Jednak grupa analityczna WG21 SG2 Modules pracująca nad C++17 musi skutecznie zaimplementować wyeksportowane szablony modułów do pracy w celu rozwiązania naruszeń ODR, A C++17 jest pierwszym proponowanym standardem, który widziałem, aby być napisany z myślą o LLVM. Innymi słowy, kompilatory C++17 będą musiały zrzucić złożony AST na dysk, tak jak robi to clang. A to oznacza ogromny wzrost gwarancji tego, co jest dostępne RTTI-rzeczywiście, dlatego mamy SG7 Reflection study group, ponieważ Ast z modułów C++ umożliwia ogromny wzrost możliwych możliwości autorefleksji. Innymi słowy, spodziewaj się, że powyższe problemy szybko znikną wraz z adopcją C++17.

Więc, w skrócie, trzymaj się mojego oryginalnego przewodnika na razie. And things will mam nadzieję, że w następnej dekadzie będzie znacznie lepiej. I podziękuj Apple za sfinansowanie tego rozwiązania, minęło bardzo dużo czasu, ze względu na to, jak bardzo trudne jest.

Niall