Re[23]: Новости C#13. params
От: Shmj Ниоткуда  
Дата: 25.10.24 06:22
Оценка:
Здравствуйте, 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-доступ — ну значит вы были правы.

А пока лишь отговорки почему это не так важно. Нет уж, это самый главный критерий для библиотек. Если этого нет — то нельзя написать универсальную библиотеку.
Отредактировано 25.10.2024 7:14 Shmj . Предыдущая версия .
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.