Друзья что надо нажать чтобы закрыт этого

крестик..................

System.Convert.ToSingle?

Это с бинарными форматами)

Оно не умеет принимать на вход byte[] или char[]) А в случае со строковым файлом флоат при чтении через поток байт без лишних аллокаций будет записан в зависимости от кодировки в виде массива символов или массива байт) В бинарном формате флоат будет занимать если не ошибаюсь 4 байта, и там вообще морочиться не надо) Так как есть вполне конкретное представление) И ты знаешь сколько байт тебе надо читать)

Obj это у нас не бинарный формат, а текстовый. И с текстовым в чём прикол. Количество занимаемых байт зависит от кодировки и количества символов. Но у тебя может быть число «345.123» и «345». В бинарном файле - это всегда 4 байта. А в текстовом - это у нас зависит от длинны строки и кодировки. Скажем в utf-8 символы в самом максимуме весят 4 байта. То есть для первого числа тебе нужно будет считать 7х4=28 байт (так как точка тоже символ), а во-втором 3х4=12 байт) В той же ASCII кодировке символ весит 1 байт, так что там это будет 7 и 3 байт соответственно)

Поэтому задача сводится к возможности перевода динамического массива байт записанного в буффер с неизвестным положением точки - в флоат число :) И она вполне решаема)

И именно по причине такого уровня сложности и в целом усложнения операций чтения в случае огромных файлов строковые форматы - это плохо :) Но у них есть свои преимущества. Что obj поддерживается любым утюгом, что csv можно много где загрузить и открыть, что json. Так как это некоторые стандарты)

Хотя если нужно что-то быстрое в контексте конкретной скажем игры или внутри проекта, то уже юзают bson, protobuf и так далее. Ну или хз, что там у нас сейчас модное) Бд это неплохо, но у них свои минусы)

Сложность миграции версии базы при изменении версии приложения (json можно хоть регулярками в новый формат без потери данных пользователя перегнать), время на db.connect, индексы место на диске пользователя занимают и так далее)

Ну да, вообще все эти размышления «что юзать» начинаются тогда, когда файлы по 100мб+ :) Когда это классические конфиги по 10-100кб - вообще пофигу, так как разница незаметна в скорости) У меня просто контекст специфичный, так как то я модели по 1-2гб грузил, то csv файлы для визуализации такого же размера)

Там есть метод, который принимает byte[]

не вижу такого на msdn

Да и не должно его быть, плюс интересен скорее char[], с byte[] вопрос, что он делает. Так как чтобы обрабатывать массив байт нужно знать, что ты обрабатываешь

Это другое

Это 4 байта массив чёткий, а не произвольный массив байт

Ты как читаешь файл?

Как строку?

В бинарных файлах да можно. Но это не тоже самое, что char[] превратить в флоат, по причинам описанным выше