Здравствуйте, ·, Вы писали:

·>Классы в dll? Гы, такой гемор. Обычно из юзабельного только extern "C".

Да нет, ничего особенного. Вполне можно использовать.
Собственно говоря, класс есть класс независимо от того, лежит он в EXE или DLL
А как, собственно, делать иначе, если некий класс нужен в нескольких project из этого solution ? Дублировать его ?

https://learn.microsoft.com/ru-ru/cpp/cpp/using-dllimport-and-dllexport-in-cpp-classes?view=msvc-170

Ну а уж в C# в DLL только классы и есть. Там даже есть специальный тип проекта в VS — Class Library


PD>> ·>Да и вообще, ничего усложнённого я не вижу, две строчки кода. Гораздо проще, чем загружать dll — по сути указали источники, взяли класс по имени и готово.
PD>> А почему действительно нет загрузки jar ? Он же по сути аналог DLL/COM тут — набор клаcсов. Почему нельзя его просто загрузить ? При статическом подключении (явно или через pom.xml) фактически он же загружается со всеми своими потрохами.
·>Я не знаю что может означать "jar загружается". Есть classpath — места где ищутся классы. И это вовсе не обязательно должны быть jar (который просто обычный zip-архив). Классы могут грузится и из обычной директории, из на лету сгенерённого массива байтов и даже из сети.

Означать может просто "подключить все классы из этого архива". Иными словами, сделать то же самое, что делается при прописывании dependency на него в pom.xml. Только в рантайме, а не статически.
Так же как LoadLibrary означает "загрузить все, что в ней есть"

·>В качестве аналогии можно сказать так: dll — соответсвует java-классу, а jar — это LD_LIBRARY_PATH. Вот и попробуй представь что может означать "загрузка LD_LIBRARY_PATH".

Ну даже чисто формально DLL не есть один класс (или namespace), а целая коллекция средств — например, WinSock или GDI. Ты же не скажешь, что GDI32.DLL — это один класс ?
И уж в любом случае это один файл, а не path