Вывод из std:: exception в библиотеке: работает ли решение только для заголовков для перехвата исключений?

в нашей кросс-платформенной библиотеке с открытым исходным кодом мы выводим из std:: exception для определения пользовательских исключений, которые могут быть пойманы в библиотечном коде, а также в пользовательском коде. Я видел, что это на самом деле рекомендуемая процедура, но в Visual Studio 2015 (или, скорее, сопровождающая новая версия MSVC?) в классе реализации ( предупреждение C4275 ) - см. Также здесь: как dllexport класс, производный от std:: runtime_error?

Of конечно, мы могли бы просто игнорировать ошибку, но мне это кажется неправильным.

причиной появления предупреждения, по сравнению со старыми версиями Visual Studio, кажется, что std:: exception используется для экспорта в более старой версии MSVC, но между тем больше не экспортируется. В любом случае, я чувствую, что это никогда не было "правильным способом" продолжать об этом в форме компиляции в библиотеку.

из того что я читал в ответах, лучший способ сделать это "встроенный" класс, так как экспорт базового класса (std:: exception) может привести к большим осложнениям. Если я правильно понимаю, "inlining" здесь означает не использование ключевого слова "inline", а перемещение определения в заголовок и не экспортировать его. Это вообще правильно?

предполагая, что это то, что подразумевается: мой вопрос в том, если скомпилированная библиотека, которая выдает исключения, которые определены в одном из ее заголовков, позволит правильно поймать исключения в исполняемой ссылке это динамическая библиотека. Но что, если компиляторы разные? Информация о типе среды выполнения (RTTI) кажется здесь актуальной, поэтому это гарантированно работает таким образом, даже при использовании разных версий компилятора или даже разных компиляторов? Если это не сработает, как решить эту проблему "правильным" способом?

1 ответов


слово проблема Microsoft Connect (веб-архив) в сообщении, связанном в вопросе;

... размещение типов STL в интерфейсе DLL заставляет вас играть по правилам STL (в частности, вы не можете смешивать разные основные версии VC, и ваши настройки IDL должны совпадать). Однако существует обходной путь. C4251-это, по сути, шум и его можно отключить...

смешивание версий и опций компилятора может (и вероятно, в какой-то момент) вызовет проблемы и непредсказуемое поведение приложения. Таким образом, нет никаких гарантий, что это сработает, возможно, наоборот, это не сработает.

при использовании встроенной техники, упомянутой выше (т. е. реализация только заголовка), и убедившись, что настройки и компиляторы согласованы между проектами, позволяет обойти ограничения экспорта dll.

учитывая, что это проект с открытым исходным кодом, он может легко строится для среды клиентов, поэтому любой из упомянутых методов должен быть подходящим, потому что клиент сможет построить код, учитывая их компилятор и параметры, которые они хотят.