Здравствуйте, Shmj, Вы писали: S>STL не нужно заворачивать — используйте внутри библиотеки обычным образом.
Не-не-не. STL — это и есть библиотека. S>Относитесь к FFI как в WebAPI, только очень быстрому и доступному для вызова лишь локально.
Прекрасно. Относитесь к WebAPI, как к FFI, только глобально доступному и полностью (а не ограниченно, как в C ABI) кроссплатформенному. S>Попробуйте на C# написать либу с одной функцией — которая принимает возвращает строку. И потом скрипты сборки под 6 платформ а так же h-файл. S>Возможно ли это?
Да, возможно. Но я подожду момента, когда вы вызовете из Java STL.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Shmj, Вы писали:
S>WebAPI расточительно. Это сервер нужен, запросы, отдельный процесс.
Не нужен никакой "сервер". А наличие отдельного процесса — благо. Когда криворукий автор на той стороне забора не может запороть моё адресное пространство просто потому, что он не знал, что нельзя скармливать переданный ему указатель в его free. S>Притом что FFI в нормальных языках никакого мучения не вызывает. Все в том же потоке, все не требовательно к ресурсам — быстро и надежно.
Хмм. Я начинаю подозревать, что вы либо не пробовали вызывать "немучительный" FFI ни из каких языков, кроме одного. Либо вы готовы взять свои необдуманные слова про "из любого языка" обратно. Скорее и то и другое — вы просто не представляете себе машинерию, которой обложены вызовы FFI в какой-нибудь JVM, при этом уже начали сдавать назад, перейдя от "любых" языков к "нормальным".
С таким подходом вообще не имеет смысла вступать в дискуссию — я просто объявлю "нормальным" ровно один язык: C#. И все языки будут делиться на те, на которых библиотеки для C#-клиентов писать удобно (например, C#), приемлемо (С), и все остальные, которые просто идут лесом за свою бесполезную громоздкость (например, C++ и Java).
S>Другой вопрос — что C# просто не умеет так.
Умеет. Но спроса на то, чего вы хотите, нету.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Serginio1, Вы писали:
S> Я так и написал. Но голый FFI не интересен. Нужны классы над этими FFI, а это уже намного больше работы!
API должен быть максимально общий. Если добавите классы — он уже не подойдет по той причине, что многие языки не содержат такой концепции. Структуры же есть везде в том или ином виде.
S>Ты видел SkiaSharp. Там обертка вокруг FFI в тысячи раз больше чем сам FFI
Обертку на родном языке можете сделать какую вам удобно — а сам интерфейс общий должен быть на универсальном стандарте, который признали все народы.
S>>Вы и WebAPI назовете ненужным? По сути WebAPI — аналогичен по функционалу. И этого достаточно. S> WebAPI нужен, как и gRPC и SOAP. Но они ну ни как не аналогичны FFI. S>Посмотри на gRPC и тот же swagger. Никакого аналога и близко нет. Это намного более функциональная надстройка.
Представь что FFI — это сверх быстрый и супер оптимизированный WebAPI.
Здравствуйте, Sinclair, Вы писали:
S>Не-не-не. STL — это и есть библиотека.
И что? Зачем ее портировать — в каждом языке — своя STL, удобная для парадигм этого языка.
Портируют библиотеки более универсальные.
S>>Относитесь к FFI как в WebAPI, только очень быстрому и доступному для вызова лишь локально. S>Прекрасно. Относитесь к WebAPI, как к FFI, только глобально доступному и полностью (а не ограниченно, как в C ABI) кроссплатформенному.
Вот поколение смузи пошло. Если для каждой либы будете создавать свой процесс со своим взаимодействием по HTTP — никаких ресурсов не хватит.
S>>Попробуйте на C# написать либу с одной функцией — которая принимает возвращает строку. И потом скрипты сборки под 6 платформ а так же h-файл. S>>Возможно ли это? S>Да, возможно. Но я подожду момента, когда вы вызовете из Java STL.
Я не вижу что это возможно. Нет ни одной библиотеки. А у Java своя STL — эта библиотека не разрабатывается как универсальная — она заточена под особенности языка. Мы же говорим о создании универсальных библиотек.
Здравствуйте, Sinclair, Вы писали:
S>Не нужен никакой "сервер". А наличие отдельного процесса — благо. Когда криворукий автор на той стороне забора не может запороть моё адресное пространство просто потому, что он не знал, что нельзя скармливать переданный ему указатель в его free.
Не прячься за криворукость. Если библиотека с багами — ее тестируют, исправляют баги. А не полагаются на то что процесс можно будет постоянно убивать и воссоздавать.
Нет, WebAPI для каждой либы — это глупость и расточительство. Человечество уже давно придумало интерфейс взаимодействия и это то немногое, в чем все согласились. А нам нужно держаться за такие стандарты.
C# так же позволяет вызывать либы FFI — так же совместим. Но на нем нельзя сделать универсальную либо под все 6 платформ. Ну нету таких.
S>>Притом что FFI в нормальных языках никакого мучения не вызывает. Все в том же потоке, все не требовательно к ресурсам — быстро и надежно. S>Хмм. Я начинаю подозревать, что вы либо не пробовали вызывать "немучительный" FFI ни из каких языков, кроме одного. Либо вы готовы взять свои необдуманные слова про "из любого языка" обратно. Скорее и то и другое — вы просто не представляете себе машинерию, которой обложены вызовы FFI в какой-нибудь JVM, при этом уже начали сдавать назад, перейдя от "любых" языков к "нормальным".
FFI используется для универсальных библиотек, а не для тех, которые заточены под конкретный язык.
Внутри C++ библиотеки используете все возможности языка и стандартной библиотеки. А уже на верх отдаете в строгом API — по возможностям оно будет эвкивалентно WebAPI — только во много крат более быстрое и не трбовательное к ресурсам.
S>>Другой вопрос — что C# просто не умеет так. S>Умеет. Но спроса на то, чего вы хотите, нету.
Вы можете дать пример такой библиотеки и победить в дискуссии. Но нету. Куча слов — а воз и ныне там.
Дайте библиотеку с 1 функцией, которая принимает и возвращает строку. Но чтобы были скрипты сборки по 6 платформ + h-файл в C-стиле, для вызова из других языков. Если есть такое хотя бы одно во Вселенной — я пожму руку и признаю поражение. Но чтобы не нужно было штуку баксов за это платить ежегодно — как с www.remobjects.com
Здравствуйте, Shmj, Вы писали: S>Портируют библиотеки более универсальные.
Вот как раз STL — более универсальная. Потому что там алгоритмы отделены от контейнеров. Была бы возможность использовать её из Java — использовали бы.
S>Я не вижу что это возможно. Нет ни одной библиотеки. А у Java своя STL — эта библиотека не разрабатывается как универсальная — она заточена под особенности языка. Мы же говорим о создании универсальных библиотек.
Прекрасно. Вижу, вы начали понимать, в чём проблема. Оказывается, навелосипедить на С++ можно вовсе не любую библиотеку, а только с существенными оговорками и ограничениями. И использовать её можно будет не из любого языка, а с существенными оговорками и ограничениями. Объём обёрток "снаружи" и "внутри" зачастую будет таким, что выгоднее просто выполнить порт библиотеки в целевой язык, чем оборачивать обёртки.
Именно поэтому "умение поддерживать FFI" очень-очень редко является критерием для выбора языка реализации. А там, где оно является, внезапно С++ начинает проигрывать банальному C в удобстве разработки такой библиотеки.
Я вам ещё раз напомню, что библиотека матричной алгебры "для С++" пишется совершенно по-другому, чем та же библиотека для "FFI экспортов". И никаких особенных преимуществ от использования С++ вместо C при написании такой библиотеки вы так и не получите.
Так что мы возвращаемся к вопросу о том, почему же вы не пишете всё на С, а пользуетесь плохо переносимым С++.
Ответ, конечно же, очевиден — потому что заявленный вами критерий неважен даже для вас самого. Поэтому из трудностей публикации FFI-экспортов для iOS (которые вполне преодолимы) в C# не следует примерно ничего.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>Портируют библиотеки более универсальные. S>Вот как раз STL — более универсальная. Потому что там алгоритмы отделены от контейнеров. Была бы возможность использовать её из Java — использовали бы.
C++ -овская STL — заточена только под C++, она не универсальна и для других языков ее адаптировать смысла нет.
Java имеет свою стандартную библиотеку — ничем не хуже.
Вы путаете — хорошая и богатая библиотека, заточенная под язык — это не значит универсальная.
Я не требую чтобы стандартную библиотеку C# портировали для запуска через FFI. Нет же — используйте только внутри C#-кода. Но должна быть возможность на C# написать конечную библиотеку с FFI-доступом, которая бы собиралась для всех 6 платформ: Windows, Linux, macOS, Andorid, iOS, WASM.
S>>Я не вижу что это возможно. Нет ни одной библиотеки. А у Java своя STL — эта библиотека не разрабатывается как универсальная — она заточена под особенности языка. Мы же говорим о создании универсальных библиотек. S>Прекрасно. Вижу, вы начали понимать, в чём проблема. Оказывается, навелосипедить на С++ можно вовсе не любую библиотеку, а только с существенными оговорками и ограничениями. И использовать её можно будет не из любого языка, а с существенными оговорками и ограничениями. Объём обёрток "снаружи" и "внутри" зачастую будет таким, что выгоднее просто выполнить порт библиотеки в целевой язык, чем оборачивать обёртки.
Из других языков можно исользовать обертку на урезанном голом C — т.н. FFI.
Но язык C++ позволяет сделать это для всех 6 платформ. Т.е. вы сможете написать либу на C++, сделать FFI обертку (сведя все к голому С) — и потом использовать на всех 6 платформах человечества из любого ЯП.
Это признак универсальности и взрослости языка.
C# пока такого не позволяет сделать. Т.е. вещь в себе — только для внутреннего использования.
S>Именно поэтому "умение поддерживать FFI" очень-очень редко является критерием для выбора языка реализации. А там, где оно является, внезапно С++ начинает проигрывать банальному C в удобстве разработки такой библиотеки.
Для разработки универсальной библиотеки — это главный критерий. А сейчас кроссплатформенность и возможность использования из родных платформ — очень важно.
S>Я вам ещё раз напомню, что библиотека матричной алгебры "для С++" пишется совершенно по-другому, чем та же библиотека для "FFI экспортов". И никаких особенных преимуществ от использования С++ вместо C при написании такой библиотеки вы так и не получите.
C++ позволяет где это удобно — использовать классы. А внешне, конечно, все нужно сводить к голому С — стандарту.
Просто относитесь к этому как в WebAPI. Внутри либы в можете использовать все конструкции — но наружу отдаете в строгом стандарте упрощенно.
S>Так что мы возвращаемся к вопросу о том, почему же вы не пишете всё на С, а пользуетесь плохо переносимым С++. S>Ответ, конечно же, очевиден — потому что заявленный вами критерий неважен даже для вас самого. Поэтому из трудностей публикации FFI-экспортов для iOS (которые вполне преодолимы) в C# не следует примерно ничего.
Еще раз — внешний интерфейс — FFI — максимально упрощен и стандартизирован, там нет классов. Как WebAPI по возможностям (ну лучше, конечно).
Внутри C++ позволяет более удобно работать с ООП. Это важно.
А внешне — да, тот же С-интерфейс отдаете. Это универсально.
На C# я не видел чтобы была такая возможность под все 6 платформ. Найдете или сами напишите скрипты сборки под все 6 платформ + FFI-доступ — ну значит вы были правы.
А пока лишь отговорки почему это не так важно. Нет уж, это самый главный критерий для библиотек. Если этого нет — то нельзя написать универсальную библиотеку.
нет проблем. Проблемы в том, что не все библиотеки соответствуют требованиям Native AOT. Но ведется активная работа по их адаптации.
В конце концов как для блазора есть интерпретация кода.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> нет проблем. Проблемы в том, что не все библиотеки соответствуют требованиям Native AOT. Но ведется активная работа по их адаптации. S>В конце концов как для блазора есть интерпретация кода.
Можно ли будет это использовать из других ЯП — т.е. есть ли универсальность библиотек? Или же это вещь в себе — дотнетчики только для дотнетчиков?
S>> нет проблем. Проблемы в том, что не все библиотеки соответствуют требованиям Native AOT. Но ведется активная работа по их адаптации. S>>В конце концов как для блазора есть интерпретация кода.
S>Можно ли будет это использовать из других ЯП — т.е. есть ли универсальность библиотек? Или же это вещь в себе — дотнетчики только для дотнетчиков?
Native AOT это не про дотнетчики только для дотнетчиков. Для этого существуют нормальные Nuget в MSIL коде.
Вы даете ссылку не на то — зачем не ваши внутренние обсуждения из багтрекеров или реквесты?
Покажите пример библиотеки, которая содержит скрипты сборки под все 6 платформ а так же FFI -интерфейсы для вызова из все ЯП. К примеру, чтобы я собрал эту либу под macOS и вызвал и node.js. Или чтобы собрал под iOS и вызвал из Dart.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>Native AOT это не про дотнетчики только для дотнетчиков. Для этого существуют нормальные Nuget в MSIL коде. S>>Если выставишь для методов Native AOT UnmanagedCallersOnly. S>>https://github.com/dotnet/runtime/issues/88737 S>>https://github.com/dotnet/runtime/pull/92141 S>>https://github.com/dotnet/runtime/issues/80905
S>Вы даете ссылку не на то — зачем не ваши внутренние обсуждения из багтрекеров или реквесты?
S>Покажите пример библиотеки, которая содержит скрипты сборки под все 6 платформ а так же FFI -интерфейсы для вызова из все ЯП. К примеру, чтобы я собрал эту либу под macOS и вызвал и node.js. Или чтобы собрал под iOS и вызвал из Dart.
Я тебе уже показывал. Но ты не читатель! Я тебе должен показать все команды
dotnet build
dotnet publish
Вы не внимательны. Нужно все 6 платформ — включая iOS, Android и WASM.
И мне нужны не обсуждения или дока — а просто репозиторий с либой и скриптами сборки. Либа может быть очень простой — функция FFI для вызова из других ЯП. Потом соберем и посмотрим что получается, какой размер будет, как быстро работает и т.д. Но это уже второй шаг — пока даже первого шага я не вижу.
Вы даете куски каких-то экспериментов, все разрозненно. Там кто-то попробовал для эксперимента запустить Android, почему то даже не официальный сайт. Та кто-то WASM, то уже иначе.
Это еще не готовое промышленное решение. Это эксперименты, результат не всегда удачен.
Когда сможете сделать универсальную библиотеку — тогда и приходите — посмотрю, проверю. Цель я вам указал: (1) работает на 6 платформах, (2) доступна для подключения через все ЯП — т.е. FFI.
Здравствуйте, Shmj, Вы писали:
S>>Я тебе и на IOS давал, про блазор и прочее писал и про андроид S>>https://github.com/jonathanpeppers/Android-NativeAOT S>>https://byandriykozachuk.wordpress.com/2023/12/29/net-wasi-native-aot-performance/ S>> Сам поищи. Почему я должен тратить время? S>>dotnet publish -r wasi-wasm -c <Configuration> /p:MSBuildEnableWorkloadResolver=false /p:UseAppHost=false –self-contained
S>Вы даете куски каких-то экспериментов, все разрозненно. Там кто-то попробовал для эксперимента запустить Android, почему то даже не официальный сайт. Та кто-то WASM, то уже иначе.
S>Это еще не готовое промышленное решение. Это эксперименты, результат не всегда удачен.
S>Когда сможете сделать универсальную библиотеку — тогда и приходите — посмотрю, проверю. Цель я вам указал: (1) работает на 6 платформах, (2) доступна для подключения через все ЯП — т.е. FFI.
Ты утверждаешь — ты и опровергай. Бери те ссылки которые я тебе указал и проверяй.
Тебе доказывают, что ты не прав! Есть возможность и люди используют!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Shmj, Вы писали: S>Вы путаете — хорошая и богатая библиотека, заточенная под язык — это не значит универсальная.
Я как раз ничего не путаю. Критерии качества библиотеки, в порядке убывания приоритетов:
1. функциональность
2. удобство использования.
3. производительность
...
99. Возможность использования из других языков
Зачем мне, скажем, на C# пердолиться с библиотекой матричной алгебры, написанной на С++? Родная библиотека, написанная на любом CLR-нативном языке, будет в разы удобнее. Как раз потому, что я смогу использовать естественные для C# способы записи интерфейсов.
Или вот, скажем, библиотека linq2db. Она при использовании из C# рвёт любые другие способы доступа к данным как тузик грелку. Нативные для Java, нативные для JavaScript.
Её не имеет смысла даже пытаться выставлять наружу через FFI, потому что её достоинства не переживут такой кастрации. Можно попробовать навелосипедить её аналог на C++. Теоретически. Меня ещё несколько лет назад убедили, что С++ стал достаточно взрослым языком, чтобы суметь сделать то, что нужно. Однако, на практике подобной библиотеки для С++ не существует. Стало быть, эта возможность так и остаётся в области фантазий. Делает ли это С++ плохим языком? Ну, для приложений, которые в основном занимаются обработкой данных, таки да. Для других применений — нет, не делает.
S>Я не требую чтобы стандартную библиотеку C# портировали для запуска через FFI. Нет же — используйте только внутри C#-кода. Но должна быть возможность на C# написать конечную библиотеку с FFI-доступом, которая бы собиралась для всех 6 платформ: Windows, Linux, macOS, Andorid, iOS, WASM.
Кому должна-то? Зачем? Вы ставите телегу впереди лошади: сначала должна быть задача, а уже потом — её решение.
S>>>Я не вижу что это возможно. Нет ни одной библиотеки. А у Java своя STL — эта библиотека не разрабатывается как универсальная — она заточена под особенности языка. Мы же говорим о создании универсальных библиотек.
Кто такие "мы"? Что за "универсальные библиотеки"? "Библиотеки" бывают очень и очень разные.
S>Из других языков можно исользовать обертку на урезанном голом C — т.н. FFI.
Ну так это же — слабое подобие левой руки. Если мы пишем библиотеку на C, то возможность задействовать её из других языков — прекрасно. Но это не означает, что С является единственным приемлемым языком.
Вообще, скажу вам по секрету, не существует единственного идеального языка. Невозможно "выучить" один язык и всю жизнь пользоваться только им.
S>Это признак универсальности и взрослости языка.
Это признак того, что вы не понимаете, как устроены критерии выбора языка.
S>C# пока такого не позволяет сделать. Т.е. вещь в себе — только для внутреннего использования.
S>Для разработки универсальной библиотеки — это главный критерий. А сейчас кроссплатформенность и возможность использования из родных платформ — очень важно.
Вы ещё даже не определились, что ваша библиотека будет делать. S>C++ позволяет где это удобно — использовать классы. А внешне, конечно, все нужно сводить к голому С — стандарту.
S>>Так что мы возвращаемся к вопросу о том, почему же вы не пишете всё на С, а пользуетесь плохо переносимым С++. S>Внутри C++ позволяет более удобно работать с ООП. Это важно.
Преимуществ от ООП вы через FFI никаких не получите. Поэтому важность этой возможности для разработки универсальной библиотеки — околонулевая.
S>А пока лишь отговорки почему это не так важно. Нет уж, это самый главный критерий для библиотек. Если этого нет — то нельзя написать универсальную библиотеку.
На языке пишут вовсе не только библиотеки.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Serginio1, Вы писали:
S>Ты утверждаешь — ты и опровергай. Бери те ссылки которые я тебе указал и проверяй. S>Тебе доказывают, что ты не прав! Есть возможность и люди используют!
Я утверждаю что нет ни одной реально используемой C#-библиотеки (открытой), которая бы собиралась под все платформы (6 штук) и была адаптирована для использования чрез FFI.
Возможно какие-то эксперименты на частном уровне проводятся, так же существуют решения за деньги — типа remobjects.com (по 1000 долларов в год на каждого разраба). Но вот промышленного решения от MS пока нет и не факт что появится.
Опровергнуть меня очень легко. Даете ссылку на репо этой либы, где бы были скрипты сборки под 6 платформ и h-файл для вызова из других языков. Только пожалуйста не давайте ссылки на обсуждения и эксперименты. Просто репо покажи и все. Скрипты сборки обязательно.
Здравствуйте, Sinclair, Вы писали:
S>Или вот, скажем, библиотека linq2db. Она при использовании из C# рвёт любые другие способы доступа к данным как тузик грелку. Нативные для Java, нативные для JavaScript.
Есть библиотеки, которые заточены исключительно под ваш язык и платформу. Центральная тема таких либ — ПЛАТФОРМА, ТЕХНОЛОГИЯ. Они для разработчиков, которые используют конкретный ЯП.
А есть либы, которые заточены под КОНЕЧНОГО ПОЛЬЗОВАТЕЛЯ, ПРОДУКТ. К примеру, либа для работы с мессенджером, крипто-либа, финансовая либа (крипта и пр.), сетевая (tor) — ее нет нужны писать для каждой платформы с нуля. Вы можете написать один раз — и использовать из всех платформ и языков.
Т.е. когда в центре — пользователь и его конкретная нужда — лучше писать универсальную либу для работы на всех платформах и вызова из всех языков.
S>>Я не требую чтобы стандартную библиотеку C# портировали для запуска через FFI. Нет же — используйте только внутри C#-кода. Но должна быть возможность на C# написать конечную библиотеку с FFI-доступом, которая бы собиралась для всех 6 платформ: Windows, Linux, macOS, Andorid, iOS, WASM. S>Кому должна-то? Зачем? Вы ставите телегу впереди лошади: сначала должна быть задача, а уже потом — её решение.
Это нужно чтобы не делать одну и ту же работу n раз. Если нет универсальной либы — вам нужно 6*10 разных кодов поддерживать — для каждой из 6 платформ (ОС) + для каждого из 10 популярных ЯП.
Вместо этого — лучше сделать одну либу, которая собирается везде и которую можно вызвать из любого ЯП.
S>Вообще, скажу вам по секрету, не существует единственного идеального языка. Невозможно "выучить" один язык и всю жизнь пользоваться только им.
Зато существуют языки, на которых можно написать либу под все платформы и вызывать из всех ЯП.
то удобно — использовать классы. А внешне, конечно, все нужно сводить к голому С — стандарту.
S>Преимуществ от ООП вы через FFI никаких не получите. Поэтому важность этой возможности для разработки универсальной библиотеки — околонулевая.
FFI — только снаружи виден. На внутреннюю реализацию это никак не влияет.
Это все равно что WebAPI — внешне вы даете в виде простого WebAPI — а внутри у вас сложная архитектура из множества классов.
S>>А пока лишь отговорки почему это не так важно. Нет уж, это самый главный критерий для библиотек. Если этого нет — то нельзя написать универсальную библиотеку. S>На языке пишут вовсе не только библиотеки.
Основное все должно быть в библиотеке. GUI и пр. нужно стремиться делать декларативным с минимумом сложных языковых конструкций. Все сложное нужно стремиться перенести в ядро в виде универсальных библиотек.
Здравствуйте, Shmj, Вы писали: S>Есть библиотеки, которые заточены исключительно под ваш язык и платформу. Центральная тема таких либ — ПЛАТФОРМА, ТЕХНОЛОГИЯ.
Не обязательно. В STL центральная тема — не "платформа" или "технология". А отделение алгоритмов от структур. Центральная тема linq2db — это типизированный язык запросов.
Просто выясняется, что вот такие "центральные темы" невозможно выразить в терминах "плоских функций". Это не делает эти библиотеки плохими. Это делает плохой идею реализовывать такие библиотеки в терминах "плоских функций".
S>А есть либы, которые заточены под КОНЕЧНОГО ПОЛЬЗОВАТЕЛЯ, ПРОДУКТ. К примеру, либа для работы с мессенджером, крипто-либа, финансовая либа (крипта и пр.), сетевая (tor) — ее нет нужны писать для каждой платформы с нуля. Вы можете написать один раз — и использовать из всех платформ и языков.
"Работа с мессенджером", my ass. Современные мессенджеры управляются по WebAPI. То есть "либа" нужна не для того, чтобы вообще "работать с мессенджером". А для того, чтобы ошибочный код по взаимодействию с WebAPI обнаруживался компилятором. Например, правила работы с чатами/группами/каналами Телеграма удобно выражать в виде некой системы типов, несводимой к "целым числам разной разрядности" и "указателям на целые числа разной разрядности". Поскольку системы типов в разных языках совершенно разные, не имеет смысла писать "FFI обёртку" для C++-ной либы и потреблять её из Java. Имеет смысл выразить API телеграма в виде набора типов Java, или набора типов С++, или набора типов C#, или набора типов typescript. С-шная "библиотека" по работе с Телеграмом имеет отрицательную ценность при работе из любого языка, кроме С.
То же самое касается, скажем, "крипто-либы" по работе с Ethereum. То же самое — "финансовая либа". То же самое — "сетевая либа". Мне в дотнете нафиг не упали какие-то вызовы нативных функций по работе с tor. Мне надо идиоматическую обёртку, которую я могу использовать вместо обычного HTTP-соединения. Ничего этого мне С++ не даст.
S>Это нужно чтобы не делать одну и ту же работу n раз. Если нет универсальной либы — вам нужно 6*10 разных кодов поддерживать — для каждой из 6 платформ (ОС) + для каждого из 10 популярных ЯП.
Более-менее нормальные языки позволяют писать либу 1 раз, не задумываясь о платформе. Например, тот же C#, или Java, или Typescript. Write once, run everywhere — слыхали?
Не существует "linq2db для iOS". То, что С++ требует от вас унижаться при компиляции под каждую платформу — это его проблема, а не достоинство.
S>Вместо этого — лучше сделать одну либу, которая собирается везде и которую можно вызвать из любого ЯП.
Ещё раз поясню самую трудную для вас вещь: для всех перечисленных вами областей либа, специфичная для какого-то языка, будет в разы удобнее и полезнее т.н. "универсальной". Если вы собрались ставить во главу угла конечного пользователя, то последнее, что стоит делать — это кастрировать С++ библиотеку до extern "C".
А если вы собрались делать обёртки на всех 10 языках — то а) все эти обёртки вам всё равно придётся меинтейнить, и б) даже если вы сможете выделить из них какой-то общий код, который был бы вызывабелен через FFI, то этот код скорее всего удобнее будет писать на С, а не на С++.
Посмотрите на реальные примеры: https://core.telegram.org/tdlib/docs/td__json__client_8h.html Внезапно библиотека "по работе с мессенджером" из любого языка предлагает JSON в качестве формата данных. Читай — ребята изобрели WebAPI. Чисто для справки: этот FFI при использовании не будет шибко эффективнее, чем честный WebAPI или там передача JSON через сокет. Потому что в современных платформах сокет на localhost работает примерно так же, как и FFI вызов, только безопаснее с т.з. адресного пространства. Кроме того, обёртки вокруг сокетов на любом языке программирования уже сделаны безопасным образом — в частности, там решены все потенциальные проблемы с контролем за временем жизни передаваемого буфера. В вашем подходе рулить этим велосипедом предлагается самостоятельно.
S>FFI — только снаружи виден. На внутреннюю реализацию это никак не влияет.
Ну так используете-то вы библиотеку снаружи, а не изнутри. Если вы хотите превратить жизнь пользователя в ад — да, ок, добро пожаловать в extern "C". То, что вы там у себя внутри что-то где-то используете, никак ему не поможет. Я же вам привёл простые примеры — даже из С++ использовать библиотеку, написанную на С++, но бинарно скомпилированную и выставленную наружу через extern "C", в разы противнее, чем напрямую потреблять С++ из С++.
S>Основное все должно быть в библиотеке. GUI и пр. нужно стремиться делать декларативным с минимумом сложных языковых конструкций. Все сложное нужно стремиться перенести в ядро в виде универсальных библиотек.
Что "основное"-то? Приведённые вами примеры выглядят неубедительно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
