LINUX.ORG.RU

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

 ,


0

2

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

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

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



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

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

★★★★★

  • открываешь файл
  • создаёшь буффер
  • в цикле
    • читаешь в буфер
    • обрабатываешь

И так по кругу. В случае ошибки чтения выходишь из цикла и закрываешь файл.

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

Это как с /dev/random читать. Только сам зациклишь

В комплекте с заданием идет файл, который надо считывать. Что нужно зацикливать?

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

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

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

В случае ошибки чтения выходишь из цикла и закрываешь файл.

А потом снова открываешь и стартуешь с того же смещения, или с начала?

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

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

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

Нет. Ты в цикле читаешь в буффер свои 4000 байт. Ошибки чтения фатальны.

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

Ну это тоже верно, уточнить, но стоит заранее изложить варианты, ИМХО.

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

Я ж говорю что это не пайп, а файл ограниченного размера.

Xintrea ★★★★★
() автор топика

Эммм...

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

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

pon4ik ★★★★★
()

А если возьмут, будешь на лоре спрашивать, что имел в виду начальник в поставленных задачах?

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

Постановка вопроса и в самом деле та ещё. Сказали бы читать поток, все сразу бы поняли. А тут какие-то детали имлементации вплели.

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

А если возьмут, будешь на лоре спрашивать, что имел в виду начальник в поставленных задачах?

И у начальника, и на лоре. А что тут такого?

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от 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 ★★★★★
()
Ответ на: комментарий от EXL

Может ещё нужно красиво оформить, и он прислал примеры?

anonymous
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У тебя problems с выражением your мыслей.

anonymous
()

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

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

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

crutch_master ★★★★★
()

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

dave ★★★★★
()

И ваще. Переспроси их. Да ту же HR! Язык тебе на что дан?)

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

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

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

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

eao197 ★★★★★
()
Ответ на: Эммм... от pon4ik

только намекну - обычный блокирующий read - это решение в лучшем случае на тройку сдаётся мне.

Дошколёнок, кому ты там собрался ставить оценки. Бегом в школу.

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

по нескольку раз читать повторно

Выглядит ооооочень нездорово. Это такая беда синтетических заданий?

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

Это кто там тявкает? Надеюсь не автор задачки из под лавки?

pon4ik ★★★★★
()

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

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

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

Release
()

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

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

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

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

Ну и что? Уточнил что там на самом деле было надо?

deep-purple ★★★★★
()

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

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

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

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

HIS
()

Даже написали какой размер буфера чтения сделать.

А тебе что-то непонятно.

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

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

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

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

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

Но задача как по мне похожа ...

...

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

Просто образец логики! :D

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

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

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

Dudraug ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.