Comments 10
Utf8 не поддерживает кириллицу
Это как?
Возможно имелось в виду что винда не может выводить в консоль utf-8 текст без плясок с бубном (до этого автор упоминал проблемы с кодировкой при выводе на консоль). Но в случае передачи строки в C# можно использовать UTF-8, C# умеет с ней работать.
А разве utf-8 не кодировка по умолчанию в . net?
char в .NET 16-бит.
UTF-8 на сегодня представлен как Span<byte>.
Смотря что значит "по умолчанию")
Строки изнутри в UTF-16 кодировке (но понятное дело что получить строку можно из данных в любой кодировке которая может конвертироваться в UTF-16).
На консоль выводятся байты в системной "легаси" консольной кодировке (Console.OutputEncoding в .NET). По умолчанию это не UTF-8 а до-юникодная DOS кодировка (зависит от языка, на русском это CP866). Можно самому заменить на UTF-8 но тогда другая сторона (например IDE) тоже должна ожидать именно UTF-8, как-то об этом договориться "на лету" нельзя. Многие программы могут работать только с системной кодировкой, другие только с UTF-8.
Решил перепроверить и не зря. Связка .toNativeUtf8 и Marshal.PtrToStringUTF8 тоже работает.
Видимо, я всё-таки запутался в кодировках в первый раз.
Вообще там есть специальное WinApi заклинание которое шлет в CMD (который не терминал, а эмулятор) команду о переключении кодировки местного std-in-out в нужную.
SetConsoleCP(CP_UTF8)
SetConsoleOutputCP(CP_UTF8)
Кресты собираются в utf-8 по дефолту (не всегда, но на это вполне можно вязатся), в общем, это и есть причина проблемы.
Я это выяснил, когда gdb.exe корректно буквы отражал, а cmd отчего-то нет. Классическое легаси которое низя ломать, потому-что половина laba1.c на неё завязано
Круто, что на флаттер приложеньках можно юзать либы из C#, например. Но подойдёт ли такой подход для реальных дексктоп приложений с запуском в прод?
Плюсами такого подхода считаю увеличение производительности и расширение пула библиотек
Было интересно увидеть сравнение - насколько эта самая производительность увеличивается. Сравнить одно и тоже приложение, использующее изоляты, для выполнения Dart функций, и запускающее в изолятах функции C#/C++ с помощью FFI
Подобные сравнения я видел на примерах нескольких программ. Из-за "построения мостов", которые тоже требуют процессорное время, производительность достигается только при большом объёме вычислений. А на сколько - всё уже зависит от самих функций.
Я один из примеров оптимизации здесь читал: https://blog.flutter.wtf/dart-ffi/
Дружим Flutter с С# и С++