Это зависит от того, чего ты больше хочешь. Или меньше памяти жрать (эта структура небось в одном экземпляре чаще всего будет или как?) или меньше кода писать.

Можно вообще убить двух зайцев тем же кортежом, к примеру

Наверное всётаки действительно две т.к. со временем часто оказывается, что юзеры есть разных типов (с разными полями). И чтобы не усложнять авторизацию разными типами пользователей для авторизации как раз и пойдёт отдельная структура, общая для любых юзеров.

А как происходит чтение бинарного файла? Ведь чтобы прочитать файл нам нужно выделить для него блок памяти какого-то размера. Но когда мы читаем файл мы же не выполняем операцию подсчета в явном виде. Она происходит скрыто? т.е. в начале считается размер файла, потом выделяется блок памяти, потом он считается?

вопрос о стандартной библиотеке или о системном вызове?

И так и сяк

Системный вызов это дергание API ОС?

да

В нем как все реализовано?

вообще-то подсчёт идёт

для каждого открытого файла в структуре процесса хранится дескриптор

а как он сделан? При обращении к файлу в начале считается его размер?

там есть переменная (кажется seek)

нет

просто читает

есть символ конца файла

на нём и останавливается

Тоесть первое чтение идет лишь для того тчj,s размер получить?

Просто мы же не можем его прочитать в память т.к. не знаем размер сколько ему нужно выделить

размер файла не хранится в самом файле

не...

файл целиком мы не можем просто так прочитать

нужно у файловой системы запросить его размер

он хранится отдельно

от самого файла

все ФС размер хранят?

да

кажется да

ext, ntfs точно

и помимо размера много всякой информации

Тоесть в начале мы запрашиваем у ФС размер файла? Потом выделяем в оперативной памяти такой же блок?

этого не делает системный вызов

системый вызов read

размер файла запрашивается отдельно

по сути не всегда даже это надо

можно читать файл блоками, пока не упрёшься в конец

и обрабатывать файл этими блоками

такой подход единственно верный, если файл не может быть физически помещён в память

какова задача то изначально?

разобраться в вопросе

если надо прочитать файл в оперативу целиком, то последовательность такая: 1. запрашивается размер файла 2. выделяется буфер этого размера 3. читается одним вызовом весь буфер

вот только не всегда это нужно

Так это реализация API так?

нет

отдельно идут вызовы запроса аттрибутов файла, один из которых размер

отдельно вызов чтения

ну и отдельно вызов на выделение памяти

Тоесть так работают сами библиотечные функции в том же Ди?

вызов readText выполняет такую последовательность

Как я понимаю можно еще читать в небольшой буфер все скользящим окном?

да

И какие плюсы\минусы данного решения?

такой подход единственно верный, если файл не может быть физически помещён в память

да и если ты не хочешь тратить много оперативы при обработке файла

да и быстрее в некоторых ситуациях

вот например весит у тебя файл, который нужно обработать, несколько гигов

и ты не хочешь тратить несколько гигов оперативы

Угу, понял. А в Ди какая функция это умеет делать?

ну блин

обычная, которая читает в буфер

rawRead

Когда ты читаешь файл и не знаешь его размера, то есть стандартный паттерн удваивания буфера

Если ты прочитал кусочек файла и уже не помещается в буфер, то выделяем под буфер в 2 раза больше места

Ну это нас так в универе учили :) В реальности там посложнее конечно алгоритм

а в какой ситуации ты не знаешь размер файла?

хотя, видимо, если ты его передаёшь по сети

но там можно сразу писать в файл

А можно как-то в одной строке два условия проверить? Чтобы на писать && if (usersFromDB.filter!(u=>u.login == login) && usersFromDB.filter!(u=>u.pass == pass))

Этот код явно работает не так, как тебе надо.

чёрт, что это за код?

это же просто жесть

да? Почему?

нельзя хранить в явном виде пароли в базе

Да я понимаю, тут пока такой вариант сойдет

Ну блин..)) А как надо то?

1. Пароли в явном виде 2. filter в if условии 3. Ищется пользователь с определённым логином. Затем ищется пользователь с определённым паролем. Это могут быть (и будут) 2 разных пользователя.

ну обычно берут хеш с логина и пароля

а уже хеш хранится и сверяется

Если не фильтр, то что тогда?

find?

canFind

Или фильтр, и затем проверка в `if`е.

В документации было так: // Filtering items (similar to WHERE clause from SQL) auto found = db.collection!Country("Countries").filter!(s => (s.name == "Poland" || s.name.canFind("ar")));

@sigod как ты форматируешь текст?)))

@DmitryBubnenkov когда тебе много людей нужно выбрать, то да, но всё равно нет

@deviator блоки кода из Markdown поддерживаются. Только в Telegram Desktop.

collection.filter!f1.filter!f2

test

о, отлично) чёт не пробовал даже)

Там очень кривое решение у Телеграм.

Вообще фильтр или map нужен?

Можно жирным выделить, но только через @bold бота.