Здравствуйте, Shmj, Вы писали:
S>Портируют библиотеки более универсальные.
Вот как раз STL — более универсальная. Потому что там алгоритмы отделены от контейнеров. Была бы возможность использовать её из Java — использовали бы.

S>Я не вижу что это возможно. Нет ни одной библиотеки. А у Java своя STL — эта библиотека не разрабатывается как универсальная — она заточена под особенности языка. Мы же говорим о создании универсальных библиотек.
Прекрасно. Вижу, вы начали понимать, в чём проблема. Оказывается, навелосипедить на С++ можно вовсе не любую библиотеку, а только с существенными оговорками и ограничениями. И использовать её можно будет не из любого языка, а с существенными оговорками и ограничениями. Объём обёрток "снаружи" и "внутри" зачастую будет таким, что выгоднее просто выполнить порт библиотеки в целевой язык, чем оборачивать обёртки.

Именно поэтому "умение поддерживать FFI" очень-очень редко является критерием для выбора языка реализации. А там, где оно является, внезапно С++ начинает проигрывать банальному C в удобстве разработки такой библиотеки.
Я вам ещё раз напомню, что библиотека матричной алгебры "для С++" пишется совершенно по-другому, чем та же библиотека для "FFI экспортов". И никаких особенных преимуществ от использования С++ вместо C при написании такой библиотеки вы так и не получите.
Так что мы возвращаемся к вопросу о том, почему же вы не пишете всё на С, а пользуетесь плохо переносимым С++.
Ответ, конечно же, очевиден — потому что заявленный вами критерий неважен даже для вас самого. Поэтому из трудностей публикации FFI-экспортов для iOS (которые вполне преодолимы) в C# не следует примерно ничего.