Здравствуйте, Serginio1, Вы писали:
S> Библиотеки нужны прежде всего для доступа к коду .Net из разных языков. S>Есть решения Написание пользовательского хост-приложения .NET для управления средой выполнения .NET из машинного кода
S> Их используют, но ты библиотек этих не найдешь. Это как "Видишь суслика — нет. А он есть!" S>Это же касается и использование нативных библиотек. Сам натив нужен для приложений ускорения и обфускации прежде всего. S> А создавать нативные кроссплатформенные библиотеки это уже некий приятный бонус.
Покажи мне библиотеку на C#, которую можно собрать под 6 платформ человечества и вызывать из всех языков (через FFI -обертку, конечно). Ну нету таких.
Зная человечество уверен что если бы это возможно было написать — уже написали бы. Людей миллионы и кому-то в голову эта идея пришла бы.
Раз не написано — то значит есть принципиальная невозомжность.
Попробуй написать сам и узнаешь в чем проблема. Можешь так же дать денег мне — я попробую написать и скажу почему не получилось.
Здравствуйте, Shmj, Вы писали: S>Потому что нужна реализация сборщика мусора и прочих фишек .net под все 6 платформ — а этого просто нет.
Ну конечно же есть.
S>Внутри библиотеки пользуете все фишки C++ -а. А наружу делаете простые упрощенные обертки в C-стиле. Никаких проблем с этим нет. Библиотеку изменять не нужно.
Дыштакое то. Ну сделайте мне простые "упрощённые обёртки" над STL в C-стиле. Над boost::bind мне сделайте обёртку!
S>Ссылка на функцию стандартизирована. . А ссылка на объект класса — нет, не стандартизована. VMT не стандартизована. Обработка исключений не стандартизована. Менеджер памяти не стандартизован. Примерно ничего из того, что может захотеться использовать в С++-библиотеке, не стандартизовано.
S>Выше написал — нет сборщика мусора под все платформы
от повторения ваше заблуждение не станет ближе к истине. Под какую из платформ вы не нашли CLR?
S>и возможности собрать стандартную .net-библиотеку под все платформы.
Есть такая возможность. Аж два раза: можно запаковать в "библиотеку" зависимость от .net runtime, и поставлять байткод. А можно собрать из библиотеки .dll/.lib под нужную платформу при помощи NativeAOT. S>А C++ — все можно. Даже важные сторонние библиотеки все собираются под все платформы — тот же boost.
Вы путаете две ортогональных вещи: кроссплатформенность и межъязыковую совместимость. Оттого, что boost можно "собрать" (на самом деле — нельзя) под все платформы, он не станет доступным из кода на Java или Object Pascal. "
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Shmj, Вы писали:
S>Покажи мне библиотеку на C#, которую можно собрать под 6 платформ человечества и вызывать из всех языков (через FFI -обертку, конечно). Ну нету таких.
Вот вам такая библиотека: https://github.com/dotnet/samples/tree/main/core/nativeaot/NativeLibrary S>Зная человечество уверен что если бы это возможно было написать — уже написали бы. Людей миллионы и кому-то в голову эта идея пришла бы.
Нет конечно. Примерно никому такое не нужно. Вообще библиотек, которые "можно вызывать из любого языка на всех шести платформах", в мире единицы, независимо от языка их реализации.
И во всех из них на кроссплатформенность положено столько усилий, что простым гражданским это нафиг не упало.
То, что вам это кажется лёгким и приятным, связано не с тем, что это легко, а с тем, что сами вы ничего подобного никогда в жизни не пробовали писать и маинтейнить. S>Раз не написано — то значит есть принципиальная невозомжность.
Редко удаётся встретить столь неудачную мысль.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>Покажи мне библиотеку на C#, которую можно собрать под 6 платформ человечества и вызывать из всех языков (через FFI -обертку, конечно). Ну нету таких. S>Вот вам такая библиотека: https://github.com/dotnet/samples/tree/main/core/nativeaot/NativeLibrary
Как мне ее собрать под iOS и вызвать из Flutter?
Как собрать из других 5 платформ и вызвать из Flutter?
Где скрипты сборки? Где описание процесса сборки?
Покажи что это реально работает. Желательно чтобы была авто-сборка в GitHub на всех платформах (хотя бы скрипты сборки под все 6 платформ человечества) — и h-файл для подключения.
Здравствуйте, Sinclair, Вы писали:
S>>Ссылка на функцию стандартизирована. S>. А ссылка на объект класса — нет, не стандартизована. VMT не стандартизована. Обработка исключений не стандартизована. Менеджер памяти не стандартизован. Примерно ничего из того, что может захотеться использовать в С++-библиотеке, не стандартизовано.
Чтобы работать с объектом класса — используете хандлер.
Потом в метод передаете хандлер первым параметром и данные как в инстациональный метод. Все просто.
Вместо исключений — коды ответов + описание (если нужно).
Очистку памяти делаете специальными функциями.
Внутри же библиотеки можете использовать все возможности — ограничение только на верхнем уровне. И это правильно — чтобы была возможность универсального доступа из 6 платформ — так нужно сделать.
S>>Выше написал — нет сборщика мусора под все платформы S>от повторения ваше заблуждение не станет ближе к истине. Под какую из платформ вы не нашли CLR?
Под iOS и Android.
S>>и возможности собрать стандартную .net-библиотеку под все платформы. S>Есть такая возможность. Аж два раза: можно запаковать в "библиотеку" зависимость от .net runtime, и поставлять байткод. А можно собрать из библиотеки .dll/.lib под нужную платформу при помощи NativeAOT.
Покажите как это сделать. Чтобы были скрипты сборки под все платформы и генерация h-файла для использования из любого языка.
S>>А C++ — все можно. Даже важные сторонние библиотеки все собираются под все платформы — тот же boost. S>Вы путаете две ортогональных вещи: кроссплатформенность и межъязыковую совместимость. Оттого, что boost можно "собрать" (на самом деле — нельзя) под все платформы, он не станет доступным из кода на Java или Object Pascal. "
Boost можно собрать под все платформы и использовать в своей C++ -библиотеке. А чтобы использовать уже вашу библиотеку в других языках — пишется FFI-интерфейсы — читай методы на голом C. И это то немногое, с чем могли договорится все народы мира.
S>>>Выше написал — нет сборщика мусора под все платформы S>>от повторения ваше заблуждение не станет ближе к истине. Под какую из платформ вы не нашли CLR?
S>Под iOS и Android.
Я уже тебе давал ссылку https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=windows%2Cnet9plus#tabpanel_2_net9plus
В .Net 9+ все поддерживается. Только в андроиде no built-in Java interop. Для IOS нет проблем.
S>>>и возможности собрать стандартную .net-библиотеку под все платформы. S>>Есть такая возможность. Аж два раза: можно запаковать в "библиотеку" зависимость от .net runtime, и поставлять байткод. А можно собрать из библиотеки .dll/.lib под нужную платформу при помощи NativeAOT.
S>Покажите как это сделать. Чтобы были скрипты сборки под все платформы и генерация h-файла для использования из любого языка.
Ты ну не читатель. Генерится все через рослин обрабатывая UnmanagedCallersOnly
Тут обсуждают https://github.com/dotnet/runtime/issues/100747
и солнце б утром не вставало, когда бы не было меня
Зачем ты даешь доку? Дай готовую библиотеку со скриптами сборки под все платформы и h-файлом, чтобы я мог подключить ее в Python, Node.js или Flutter.
S>>Покажите как это сделать. Чтобы были скрипты сборки под все платформы и генерация h-файла для использования из любого языка. S> Ты ну не читатель. Генерится все через рослин обрабатывая UnmanagedCallersOnly S>Тут обсуждают https://github.com/dotnet/runtime/issues/100747
Ну вот когда наобсуждаете — тогда и посмотрим.
По итогам попробуйте написать библиотеку + h-файл + скрипты сборки под 6 платформ. Пока я не вижу результат. Возможно вы сделали просто запуск приложений и библиотеки только для .Net — но это не то.
Здравствуйте, Shmj, Вы писали: S>Как мне ее собрать под iOS и вызвать из Flutter? S>Как собрать из других 5 платформ и вызвать из Flutter? S>Где скрипты сборки? Где описание процесса сборки? S>Покажи что это реально работает. Желательно чтобы была авто-сборка в GitHub на всех платформах (хотя бы скрипты сборки под все 6 платформ человечества) — и h-файл для подключения.
Сразу после того, как вы завернёте алгоритмы STL в FFI и покажете, как отсортировать ими список строк на Java.
Можно даже без авто-сборки на всех платформах.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Сразу после того, как вы завернёте алгоритмы STL в FFI и покажете, как отсортировать ими список строк на Java. S>Можно даже без авто-сборки на всех платформах.
STL не нужно заворачивать — используйте внутри библиотеки обычным образом.
А вот API библиотеки должно быть упрощенным. Примерно так же как вы делаете WebAPI. Вы WebAPI делали когда-нибудь? Вас же не смущает что WebAPI не обладает возможностью передавать объекты классов и пр. вещи?
Относитесь к FFI как в WebAPI, только очень быстрому и доступному для вызова лишь локально.
Попробуйте на C# написать либу с одной функцией — которая принимает возвращает строку. И потом скрипты сборки под 6 платформ а так же h-файл.
S>STL не нужно заворачивать — используйте внутри библиотеки обычным образом.
S>А вот API библиотеки должно быть упрощенным. Примерно так же как вы делаете WebAPI. Вы WebAPI делали когда-нибудь? Вас же не смущает что WebAPI не обладает возможностью передавать объекты классов и пр. вещи?
Как это не может? Все передается через Json сериализацию или gRPC
А многие используют и memory mapped files
Опять же по gRPC можно получить описание используемых классов через .proto
S>Попробуйте на C# написать либу с одной функцией — которая принимает возвращает строку. И потом скрипты сборки под 6 платформ а так же h-файл.
S>Возможно ли это?
Ну тебе же уже давали ссылку. Кроме того через Source Generator или обработку Il кода нет проблем создать h файлы. Я уже тебе давал ссылки.
Но еще раз. Видишь суслика — нет. А он есть.
Кому надо те делают. Большинству это просто не нужно. Проще использовать тот же gRPC
В том же андроиде многое сделано через обмен сообщений с сервисами
и солнце б утром не вставало, когда бы не было меня
S>А вот API библиотеки должно быть упрощенным. Примерно так же как вы делаете WebAPI. Вы WebAPI делали когда-нибудь? Вас же не смущает что WebAPI не обладает возможностью передавать объекты классов и пр. вещи? S>Относитесь к FFI как в WebAPI, только очень быстрому и доступному для вызова лишь локально.
Вооот, уже потихоньку прогресс пошел.
Осталось сделать шажок "Относитесь к FFI как в WebAPI" -> "А может сразу сделать WebAPI к библиотеке и не мучаться".
Здравствуйте, Serginio1, Вы писали:
S>>А вот API библиотеки должно быть упрощенным. Примерно так же как вы делаете WebAPI. Вы WebAPI делали когда-нибудь? Вас же не смущает что WebAPI не обладает возможностью передавать объекты классов и пр. вещи?
S> Как это не может? Все передается через Json сериализацию или gRPC S>А многие используют и memory mapped files
Объект класса — это не только данные, но и связанные с ними методами. Как ты его передашь через WebAPI?
Вот и рассматривай FFI как аналог API к твоей библиотеке — только очень быстрый и с доп. возможностями.
S>Опять же по gRPC можно получить описание используемых классов через .proto
Классов или структур? Методы то не инстанциальные.
S>>Возможно ли это? S>Ну тебе же уже давали ссылку. Кроме того через Source Generator или обработку Il кода нет проблем создать h файлы. Я уже тебе давал ссылки.
На что ссылку? На документацию Native AOT? Дай пример библиотеки + скрипты сборки под 6 платформ, которая поддерживает FFI.
S> Но еще раз. Видишь суслика — нет. А он есть. S> Кому надо те делают. Большинству это просто не нужно. Проще использовать тот же gRPC S>В том же андроиде многое сделано через обмен сообщений с сервисами
Вот в том то и дело что проще — потому что иначе невозможно и вы делаете через такой костыль. А это не то и близко не то. Это и медленно и требует доп. ресурсов.
Пойми — человечество за тысячелетия своего существования смогло договориться не о таком уж большом количестве стандартов. Так вот FFI — это то немногое, к чему смогли прийти люди и с чем согласились за миллионы лет своего развития.
Здравствуйте, syrompe, Вы писали:
S>Осталось сделать шажок "Относитесь к FFI как в WebAPI" -> "А может сразу сделать WebAPI к библиотеке и не мучаться".
WebAPI расточительно. Это сервер нужен, запросы, отдельный процесс.
Притом что FFI в нормальных языках никакого мучения не вызывает. Все в том же потоке, все не требовательно к ресурсам — быстро и надежно.
Другой вопрос — что C# просто не умеет так. Не сделано. По этому это вещь в себе — чисто для корпоративных приложений, которые используются внутри организации. Но не для глобальных важных библиотек.
Здравствуйте, Shmj, Вы писали:
S>Пойми — человечество за тысячелетия своего существования смогло договориться не о таком уж большом количестве стандартов. Так вот FFI — это то немногое, к чему смогли прийти люди и с чем согласились за миллионы лет своего развития.
На самом деле универсальный это COM Портирование COM на Linux
СОМ IDL описание интерфейсов. Единственно там проблема с подсчетом ссылок, но и в твой системе не меньше проблем.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> На самом деле универсальный это COM Портирование COM на Linux S>СОМ IDL описание интерфейсов. Единственно там проблема с подсчетом ссылок, но и в твой системе не меньше проблем.
Нет, это чисто фишка MS. Ну портировали на Linux — ОК, Там же и Wine есть. На остальных платформах ничего и близко нет.
Повторюсь. Не так много вещей есть, с все народы мира согласились и приняли за стандарт. FFI — одна из немногих таких вещей. Это работает везде — из любых ЯП вы можете вызывать FFI.
C# просто фундаментально не состоявшийся язык — нет возможности писать универсальные библиотеки. Возможно появится такая возможность в будущем — но пока ее нет
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> На самом деле универсальный это COM Портирование COM на Linux S>>СОМ IDL описание интерфейсов. Единственно там проблема с подсчетом ссылок, но и в твой системе не меньше проблем.
S>Нет, это чисто фишка MS. Ну портировали на Linux — ОК, Там же и Wine есть. На остальных платформах ничего и близко нет.
S>Повторюсь. Не так много вещей есть, с все народы мира согласились и приняли за стандарт. FFI — одна из немногих таких вещей. Это работает везде — из любых ЯП вы можете вызывать FFI.
FFI это про функции, а COM это про классы! Чувствуешь разницу?
СOM по сути это по сути абстрактный класс. Вернее ссылка на данные первым элементом которой это ссылка на VMT.
Один объект может поддерживать несколько COM интерфейсов через QueryInterface. При этом передается ссылка на поле в котором содержится VMT с корректировкой this оносительно смещения этого поля.
Так же и свой менеджер памяти. То есть FFI это огромный шаг назад.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>FFI это про функции, а COM это про классы! Чувствуешь разницу? S> СOM по сути это по сути абстрактный класс. Вернее ссылка на данные первым элементом которой это ссылка на VMT. S>Один объект может поддерживать несколько COM интерфейсов через QueryInterface. При этом передается ссылка на поле в котором содержится VMT с корректировкой this оносительно смещения этого поля. S>Так же и свой менеджер памяти. То есть FFI это огромный шаг назад.
Больше — не значит лучше. ООП — это особенность реализации конкретного языка. В другом языке ООП может вовсе не быть. Теряется универсальность.
Понятный для вас пример — WebAPI. WebAPI простой как двери — но стандарт и более-мене используется. Только это не подходит для библиотек — это сервер, медленный канал обмена, отдельный процесс и т.д.
Здравствуйте, Shmj, Вы писали:
S>>FFI это про функции, а COM это про классы! Чувствуешь разницу? S>> СOM по сути это по сути абстрактный класс. Вернее ссылка на данные первым элементом которой это ссылка на VMT. S>>Один объект может поддерживать несколько COM интерфейсов через QueryInterface. При этом передается ссылка на поле в котором содержится VMT с корректировкой this оносительно смещения этого поля. S>>Так же и свой менеджер памяти. То есть FFI это огромный шаг назад.
S>Больше — не значит лучше. ООП — это особенность реализации конкретного языка. В другом языке ООП может вовсе не быть. Теряется универсальность.
S>Понятный для вас пример — WebAPI. WebAPI простой как двери — но стандарт и более-мене используется. Только это не подходит для библиотек — это сервер, медленный канал обмена, отдельный процесс и т.д.
Ну вот COM была поддержка всех языков на Windows. Это не проблема.
А вот те кто пишет кроссплатформенные библиотеки, они же как правило еще и предоставляют нормальный интерфейс для каждого языка. Например SkiaSharp это обертка над нативными SKIA библиотеками.
Никому не интересны голый FFI.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Ну вот COM была поддержка всех языков на Windows. Это не проблема.
Причем тут Windows? Библиотека должна писаться под все 6 платформ, а не под одну.
S> А вот те кто пишет кроссплатформенные библиотеки, они же как правило еще и предоставляют нормальный интерфейс для каждого языка. Например SkiaSharp это обертка над нативными SKIA библиотеками. S>Никому не интересны голый FFI.
И этот интерфейс — основан на FFI всегда — загляните внутрь. Т.е. основа всего — функции на голом С.
Вы и WebAPI назовете ненужным? По сути WebAPI — аналогичен по функционалу. И этого достаточно.
Здравствуйте, Shmj, Вы писали:
S>> Ну вот COM была поддержка всех языков на Windows. Это не проблема.
S>Причем тут Windows? Библиотека должна писаться под все 6 платформ, а не под одну.
При том, что COM вполне реально можно перенести на все платформы. Или VMT запретили? S>> А вот те кто пишет кроссплатформенные библиотеки, они же как правило еще и предоставляют нормальный интерфейс для каждого языка. Например SkiaSharp это обертка над нативными SKIA библиотеками. S>>Никому не интересны голый FFI.
S>И этот интерфейс — основан на FFI всегда — загляните внутрь. Т.е. основа всего — функции на голом С.
Я так и написал. Но голый FFI не интересен. Нужны классы над этими FFI, а это уже намного больше работы!
Ты видел SkiaSharp. Там обертка вокруг FFI в тысячи раз больше чем сам FFI
S>Вы и WebAPI назовете ненужным? По сути WebAPI — аналогичен по функционалу. И этого достаточно.
WebAPI нужен, как и gRPC и SOAP. Но они ну ни как не аналогичны FFI.
Посмотри на gRPC и тот же swagger. Никакого аналога и близко нет. Это намного более функциональная надстройка.
и солнце б утром не вставало, когда бы не было меня
. А ссылка на объект класса — нет, не стандартизована. VMT не стандартизована. Обработка исключений не стандартизована. Менеджер памяти не стандартизован. Примерно ничего из того, что может захотеться использовать в С++-библиотеке, не стандартизовано.
