Сообщение Re[2]: Экспорт p-impl из dll от 24.07.2023 15:56
Изменено 24.07.2023 16:12 Chorkov
Re[2]: Экспорт p-impl из dll
Здравствуйте, Kernan, Вы писали:
K>Какие цели преследуешь делая так? Для чего это делаешь?
Я отдаю на сторону: (1) несколько библиотек с закрытым кодом, и (2) несколько библиотек "в исходниках", которые пользователь может (пере)собрать или встроить в свой проект прямо исходниками.
Все это выделяется из существующей кодовой базы, где все было единым проектом.
Библиотеки (2) используют библиотеки из (1) и (2).
Граница между закрытой и открытой частями проходит как-раз по по объектам реализованным в стиле p-impl.
(Не все, но многие. Это делалось для уменьшения времени компиляции.)
Не везде p-impl на основе основан на shared_ptr, чаще unique_ptr. Но с ним, тоже самое предупреждение.
В качестве аргументов методов класса фигурируют либо числа, либо классы векторов и матриц (из библиотек (1)), либо std::valarray<double>.
(Почему std::valarray<double> не дает такого предупреждения, я еще не разобрался, но это тоже, наверное, ошибка.)
Простой путь: порезать проект на части, все что экспортируется пометить как __declspec(dllexport), под линукс __attribute__((visibility("default"))). Это работает и проходит тесты.
Однако предупреждения — смущают. Что если на машине пользователя другая версия CRT?
Т.е. это явная ошибка, и непонятно почему компиляторы выдают только предупреждение.
K>Какие цели преследуешь делая так? Для чего это делаешь?
Я отдаю на сторону: (1) несколько библиотек с закрытым кодом, и (2) несколько библиотек "в исходниках", которые пользователь может (пере)собрать или встроить в свой проект прямо исходниками.
Все это выделяется из существующей кодовой базы, где все было единым проектом.
Библиотеки (2) используют библиотеки из (1) и (2).
Граница между закрытой и открытой частями проходит как-раз по по объектам реализованным в стиле p-impl.
(Не все, но многие. Это делалось для уменьшения времени компиляции.)
Не везде p-impl на основе основан на shared_ptr, чаще unique_ptr. Но с ним, тоже самое предупреждение.
В качестве аргументов методов класса фигурируют либо числа, либо классы векторов и матриц (из библиотек (1)), либо std::valarray<double>.
(Почему std::valarray<double> не дает такого предупреждения, я еще не разобрался, но это тоже, наверное, ошибка.)
Простой путь: порезать проект на части, все что экспортируется пометить как __declspec(dllexport), под линукс __attribute__((visibility("default"))). Это работает и проходит тесты.
Однако предупреждения — смущают. Что если на машине пользователя другая версия CRT?
Т.е. это явная ошибка, и непонятно почему компиляторы выдают только предупреждение.
Re[2]: Экспорт p-impl из dll
Здравствуйте, Kernan, Вы писали:
K>Какие цели преследуешь делая так? Для чего это делаешь?
Я отдаю на сторону: (1) несколько библиотек с закрытым кодом, и (2) несколько библиотек "в исходниках", которые пользователь может (пере)собрать или встроить в свой проект прямо исходниками.
Все это выделяется из существующей кодовой базы, где все было единым проектом.
Библиотеки (2) используют библиотеки из (1) и (2).
Граница между закрытой и открытой частями проходит как-раз по по объектам реализованным в стиле p-impl.
(Не все, но многие. Это делалось для уменьшения времени компиляции.)
Не везде p-impl на основе основан на shared_ptr, чаще unique_ptr. Но с ним, тоже самое предупреждение.
В качестве аргументов методов класса фигурируют либо числа, либо классы векторов и матриц (из библиотек (1)), либо std::valarray<double>.
(Почему std::valarray<double> не дает такого предупреждения, я еще не разобрался, но это тоже, наверное, ошибка.)
Простой путь: порезать проект на части, все что экспортируется пометить как __declspec(dllexport), под линукс __attribute__((visibility("default"))). Это работает и проходит тесты.
Однако предупреждения — смущают. Что если на машине пользователя другая версия CRT?
Т.е. это явная ошибка, и непонятно почему компиляторы выдают только предупреждение.
P.S.
Поскольку код из исходной кодовой базы продолжит использоваться, хочется изменения были, по возможности, минимальны. Т.е. интерфейс экспортируемых классов лучше не менять.
K>Какие цели преследуешь делая так? Для чего это делаешь?
Я отдаю на сторону: (1) несколько библиотек с закрытым кодом, и (2) несколько библиотек "в исходниках", которые пользователь может (пере)собрать или встроить в свой проект прямо исходниками.
Все это выделяется из существующей кодовой базы, где все было единым проектом.
Библиотеки (2) используют библиотеки из (1) и (2).
Граница между закрытой и открытой частями проходит как-раз по по объектам реализованным в стиле p-impl.
(Не все, но многие. Это делалось для уменьшения времени компиляции.)
Не везде p-impl на основе основан на shared_ptr, чаще unique_ptr. Но с ним, тоже самое предупреждение.
В качестве аргументов методов класса фигурируют либо числа, либо классы векторов и матриц (из библиотек (1)), либо std::valarray<double>.
(Почему std::valarray<double> не дает такого предупреждения, я еще не разобрался, но это тоже, наверное, ошибка.)
Простой путь: порезать проект на части, все что экспортируется пометить как __declspec(dllexport), под линукс __attribute__((visibility("default"))). Это работает и проходит тесты.
Однако предупреждения — смущают. Что если на машине пользователя другая версия CRT?
Т.е. это явная ошибка, и непонятно почему компиляторы выдают только предупреждение.
P.S.
Поскольку код из исходной кодовой базы продолжит использоваться, хочется изменения были, по возможности, минимальны. Т.е. интерфейс экспортируемых классов лучше не менять.