fk0, легенда (29.12.2017 05:52 - 06:01, просмотров: 112) ответил Ксения на Статейку нашла на эту тему - с теми же проблемами авторы боролись, но суть сводится к тому, что лишь на Microsoft Visual C всё это работает. Но если так, то и экспортировать ничего не надо, а надо просто на VC писать, тем более что альтернативных
Если кому-то микрософт платит премию за продвижение визуал-студии, то из этого совершенно не следует, что вообще есть какие-то трудности за пределами виндовса или студии. Эти границы искусственно созданы самим микрософтом. В unix в общем случае НЕТ ВООБЩЕ разницы, код положен в shared library или прилинкован статически, механизм работает прозрачно. В cygwin и mingw эту разницу для windows тоже стремятся свести к нулю. А работающие по правилам микрософта как всегда в жопе и только микрософт на коне и при этом ни с кем не совместим, это известная история. Если ближе к технике, то в DLL большие проблемы с экспортом не C++ вообще, а попросту переменных. В то время как у нормальных людей переменные просто экспортируются и импортируются, то у виндоморонов там пляски с бубном вокруг ссылок на них (из-за отказа от PIC, и как следствия, отсутствия GOT они то же самое делают руками на пользовательском уровне). Ну и dllimport/dllexport для функций ещё, который опять же в нормальной ситуации прячется в PLT/GOT, а не тащится на уровень пользовательского кода. При чем здесь C++ вообще непонятно. Нет никаких препятствий, чтоб класть в библиотеки C++-функции, члены классов, операторы -- это всё функции. Было бы желание -- выкидывается студия, берётся mingw gcc и сразу всё работает.
[ZX]