![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
На CppCon 2014 докладчик Stefanus Du Toit представил концепцию hourglass-интерфейсов для динамически связываемого кода на C++:
http://www.slideshare.net/StefanusDuToit/cpp-con-2014-hourglass-interfaces-for-c-apis
Идея заключается в том, чтобы из DLL-ек и so-шек экспортировать тонкие C89-интерфейсы, обрамляя их C++ным кодом с обоих сторон (как с клиентской, так и со стороны библиотеки). Это позволяет избежать различных проблем с несовместимостью ABI, например:
- библиотека собрана компилятором MSVC, а клиент - mingw, или Borland/Embarcadero C++ (библиотека распределяет память из одной кучи, а клиент пытается её освободить в контексте другой кучи)
- библиотека и клиент используют различные версии libc (например в libgcc_s до некоторой версии функция __cxa_allocate_exception не инкрементировала счётчик количества активных исключений в __cxa_get_globals, затем начала инкрементировать, а после некоторой совсем недавней версии опять перестала).
- библиотека и клиент собраны разными версиями компилятора, чуть изменился формат RTTI, и теперь этот ваш dynamic_cast во время блужданий по чужим графам типов, сохранённым новой версией компилятора в новом формате, получает сигнал от ядра
На самом деле, hourglass-концепция — довольно старая штука. Весь Win32 API построен по этому принципу. Даже DLL-ки, у которых внутри явно C++ (ufat.dll), экспортируют сишные интерфейсы.
Кстати, эту hourglass-концепцию можно воплотить в более экстремальной форме, подобно тому, как это делает libcurl: самый минимум функций: самый общий конструктор (аргумент — номер типа), самая общая функция установки значения (аргументы — номер типа, указатель на объект, номер поля, номер типа значения, void*-указатель на значение), самая общая функция получения значения, самая общая функция запуска метода на выполнение, и самая общая функция разрушения. В таком случае даже изменения ABI в части выравнивания полей в структурах, или добавление новых полей в структуры не испортят такой API. Удобно будет делать bindings к разным языкам. Ведь специфический c-компилятор, портированный в golang с plan9, может выравнивать ваши структурки вовсе не так, как gcc или msvc. Или выбрать другой размер enum'а.
Жаль, что авторы Windows GDI в своё время до такого не додумались. Или додумались, но пожертвовали архитектурой ради скорости: знаете, во времена 16-разрядных процессоров и 4Мб ОЗУ в этом мог быть смысл.
http://www.slideshare.net/StefanusDuToit/cpp-con-2014-hourglass-interfaces-for-c-apis
Идея заключается в том, чтобы из DLL-ек и so-шек экспортировать тонкие C89-интерфейсы, обрамляя их C++ным кодом с обоих сторон (как с клиентской, так и со стороны библиотеки). Это позволяет избежать различных проблем с несовместимостью ABI, например:
- библиотека собрана компилятором MSVC, а клиент - mingw, или Borland/Embarcadero C++ (библиотека распределяет память из одной кучи, а клиент пытается её освободить в контексте другой кучи)
- библиотека и клиент используют различные версии libc (например в libgcc_s до некоторой версии функция __cxa_allocate_exception не инкрементировала счётчик количества активных исключений в __cxa_get_globals, затем начала инкрементировать, а после некоторой совсем недавней версии опять перестала).
- библиотека и клиент собраны разными версиями компилятора, чуть изменился формат RTTI, и теперь этот ваш dynamic_cast во время блужданий по чужим графам типов, сохранённым новой версией компилятора в новом формате, получает сигнал от ядра
На самом деле, hourglass-концепция — довольно старая штука. Весь Win32 API построен по этому принципу. Даже DLL-ки, у которых внутри явно C++ (ufat.dll), экспортируют сишные интерфейсы.
Кстати, эту hourglass-концепцию можно воплотить в более экстремальной форме, подобно тому, как это делает libcurl: самый минимум функций: самый общий конструктор (аргумент — номер типа), самая общая функция установки значения (аргументы — номер типа, указатель на объект, номер поля, номер типа значения, void*-указатель на значение), самая общая функция получения значения, самая общая функция запуска метода на выполнение, и самая общая функция разрушения. В таком случае даже изменения ABI в части выравнивания полей в структурах, или добавление новых полей в структуры не испортят такой API. Удобно будет делать bindings к разным языкам. Ведь специфический c-компилятор, портированный в golang с plan9, может выравнивать ваши структурки вовсе не так, как gcc или msvc. Или выбрать другой размер enum'а.
Жаль, что авторы Windows GDI в своё время до такого не додумались. Или додумались, но пожертвовали архитектурой ради скорости: знаете, во времена 16-разрядных процессоров и 4Мб ОЗУ в этом мог быть смысл.
