LINUX.ORG.RU

Непрерывное чтение из файла - что имел в виду автор?

 , ,


0

2

Привет, народ.

Тут мне потенциальный работодатель прислал тестзадание. Один из пунктов такой:

Координаты точек записаны в бинарном файле в формате int16_t для каждой из координат. Чтение файла должно быть непрерывным (зацикленным), порциями по 1000 точек (4000 байт) и осуществляться в отдельном потоке. Отобразить точки на плоскости, одновременно не более 16000 точек.



Смотрю я на это и думаю, что конкретно нужно сделать. Ограничения на размер файла нет... Чтение порциями - это я понимаю. Но «чтение должно быть непрерывным (зацикленным)» - это что имеют в виду? Нужно ли держать файл все время открытым? Или после каждого чтения 1000 точек надо закрывать файл? Что делать при достижении конца файла? Начинать считывать с начала? Значит, таки файл надо после чтения очередных 1000 точек закрывать? То есть, подразумевается, что файл может меняться между итерациями чтения?

Кто что думает?

★★★★★

Ответ на: комментарий от Xintrea

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

peregrine ★★★★★ ()

Эммм...

Вот интересный вопрос - как ты собираешься трудиться, если не можешь даже постановку тестового задания вкурить? Мы то конечно объясним и расскажем, не вопрос, но как бэ постановка же вполне себе…

Читаешь файл поблочно до eof/завершения ПО/завершения задачи. Тебя просят сделать обычный цикл обработки событий в отдельном потоке - пришла пачка точек, распарсил сделал с ними что-то. Что бы совсем не читерить, только намекну - обычный блокирующий read - это решение в лучшем случае на тройку сдаётся мне.

pon4ik ★★★★★ ()
Ответ на: комментарий от beastie

Координаты [..] в бинарном файле в формате int16_t для каждой из координат

А координат то сколько? Одна, две, много? ;) Т.е. 1D, 2D, 3D…??? или всё в одном ште16?

(зацикленным)

Постановщик задания тоже чуть-чуть зацилился. Т.е. описывает имплементацию, а не ТЗ.

beastie ★★★★★ ()
Последнее исправление: beastie (всего исправлений: 1)
Ответ на: комментарий от beastie

А координат то сколько? Одна, две, много? ;) Т.е. 1D, 2D, 3D…??? или всё в одном ште16?

В других пунктах там плоскость, 2D.


Постановщик задания тоже чуть-чуть зацилился. Т.е. описывает имплементацию, а не ТЗ.

Вот именно. Вместо описания окружения и конечного результата, написана неполная имплементация. В этом то и проблема.

Xintrea ★★★★★ ()

Имхо, тупой циклический read из файла по 4000 байт до eof или до 16х4000. Просто постановщик косноязычен.

Напиши потом, что хотел сказать автор своим произведением.

eagleivg ★★★★★ ()

Всяческих успехов по работе. Надеюсь, что при этом Тетра не умрёт.

Зы постарайся обыграть/предложить несколько вариантов.

anonymous ()

Сформулировано действительно слабо. Как мне кажется, ожидается поведение, похожее на tail -f. Этот ключ предназначен для отслеживания логов, в конец которых что-то пишется, в реальном времени.

После вывода сколько-то последних строк файла tail с ключом -f продолжает работать и циклически проверяет размер файла, дописывая к выводу вновь появившиеся байты.

Исходники GNU tail, если нужны, лежат тут: https://github.com/coreutils/coreutils/blob/master/src/tail.c

Bagrov ★★★★★ ()
Ответ на: комментарий от Bagrov

Как мне кажется, ожидается поведение, похожее на tail -f. Этот ключ предназначен для отслеживания логов, в конец которых что-то пишется, в реальном времени.

И каким образом это накладывается на то, что заказчик ему прислал файл из которого нужно «непрерывно» читать?

EXL ★★★★★ ()

Я бы понял это так:

  • файл это буфер, ака буфер uart/fifo
  • мы из него забираем данные, стирая что считали
  • если дошли до конца переходим в режим ожидания наполнения буфера, по таймаут либо набору данных на пачку - читаем
Silerus ★★★ ()
Ответ на: комментарий от beastie

Постановка согласен, не ах. А так вообще кто ясно мыслит, ясно излагает, а работать под руководством тех у кого каша в голове, так себе затея. Мозги сношать будут по КД и лисапедов на Луну требовать будут, а платить будут мало.

peregrine ★★★★★ ()
Ответ на: комментарий от annulen

Вот именно. Потому уточнить что именно из 3-ёх вариантов им требуется, а если там неадекваты, которые считают что их должны понимать с половины слова, то они сами спалятся, сказав что перезвонят.

peregrine ★★★★★ ()
Последнее исправление: peregrine (всего исправлений: 2)

Если файл в процессе меняется (в конец дописываются значения) другим процессом - видимо нужно постоянно его допрочитывать, по мере поступления новых данных.

Если файл не меняется - видимо его надо по нескольку раз читать повторно.

Правильней всего будет уточнить у работодателя тестзадание, чтоб не гадать.

SZT ★★★★★ ()
Ответ на: комментарий от Xintrea

Вот именно. Вместо описания окружения и конечного результата, написана неполная имплементация. В этом то и проблема.

Хотя на самом деле, тестовое задание моей нынешней которы я тоже с «неуд» заклеймил.

С десяток задач решил за час, но… с кучей side-channel knowledge.

В общем матюгнулся им, что если хотят отпугнуть кандидатов, то в путь-дорогу.

К чему я это? А к тому, что задачи состовляют те, кто мало того, что костноязычны, так ещё и не знают, что хотят и выдумывают под конкретную временную проблему.

Но! Это и сигнал к разброду и внутренним шатаниям. Т.ч. коль хочешь пикантных ощущений? Why not? Но в общем это red flag.

ЗЫ: с другой стороны, где конь не пахал, и шансов много.

beastie ★★★★★ ()
Последнее исправление: beastie (всего исправлений: 2)

Один поток у тебя должен в читать файл в цикле порциями по 4000 байт, складывая куда-нибудь данные, другой по этим данным должен рисовать точки на плоскости, но их должно быть не более 16к. Что делать если их больше и какую их часть откидывать непонятно.

То есть, подразумевается, что файл может меняться между итерациями чтения?

Возможно, но выглядит это как полная херня. Лучше заюзать stdin.

crutch_master ★★★★★ ()

Чую, что здесь загвоздка в представлении точек таком, чтобы можно было быстро их отсекать при рисовании. k-d-деревья или что-то в таком духе.

dave ★★★★★ ()
Ответ на: комментарий от beastie

Постановка вопроса и в самом деле та ещё.

В тестовых заданиях иногда преднамеренно расставляют/оставляют «белые пятна» и размытые/неоднозначные формулировки. Делается это для того, чтобы заставить соискателя задавать уточняющие вопросы. По таким вопросам, в принципе, можно оценивать степень самостоятельности (самоуверенности) кандидата и его возможности/способности по выуживанию нужной информации из потока невнятных хотелок.

Безотносительно того, хорошая ли это практика или нет, она имеет место быть. И в данном случае Xintrea показывает отсутствие таких способностей. Ну или, по меньшей мере, желания проделать эту работу самостоятельно.

eao197 ★★★★★ ()

Постановка задачи мутная. Я считаю (предварительно совершив некий #include <ashral.h>, что так:

  • Открываешь файл
  • считываешь по 4000 байт точки
  • скидываешь в некий условный QLinkedList (доступ к данным через мютекс только)
  • так читаешь пока не eof.
  • Если eof, то закрываешь файл. Потом опять открываешь (хрен знает зачем). Данные пока не кидай никуда, т.к. не набралось 4000 байт.
  • при отображении точек, отсеивать лишние точки (я так понял, что сначала), если больше 16к элементов. Куда это впихивать - хз, можно попробовать при считывании.

задача неясна, но я вообще студентота безработная, так что другие мб уже и ответили нормально

Release ()

Что делать при достижении конца файла? Начинать считывать с начала?

Похоже, это. Я бы уточнил это у работодателя (приложив вариант того, как ты это понял, и код по выбранному варианту).

И да, как и анонимус выше, я надеюсь, что MyTetra будет развиваться.

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 1)

Я не уверен что тут написано...

Но задача как по мне похожа на стандартный лог файл в который постоянно что-то пишется, а прога должна это читать и отображать скроллируя экран.

Тоесть ты при чтении не закрываешь файл, а постоянно читаешь обрабатывая eof как просто подождать следующую пачку данных.

Да. Меня тоже удивляет когда с такой хренью в лор приходят как двоечники и списывальщики.

HIS ()
Ответ на: комментарий от eao197

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

Если это на должность разработчика и менеджера в одном лице, могу согласиться.

gag ★★★★★ ()
Ответ на: комментарий от EXL

И каким образом это накладывается на то, что заказчик ему прислал файл из которого нужно «непрерывно» читать?

Каким образом наличие файла мешает его «непрерывно» читать?

Dudraug ★★★★★ ()