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

fifo?

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

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

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

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

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

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

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

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

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

Может стоит написать ему и спросить, а не гадать на лоре?

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

У тебя может вообще не быть смещения, если это пайп.

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

Эммм...

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

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

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

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

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

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

Мы вам перезвоним.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И нет никакой гарантии, что дальше не будет хуже

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А ты не накладывай, а намазывай.

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

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

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

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

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

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

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

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

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

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

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

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

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

состовляют
костноязычны

...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

...

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

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

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

будь мужиком и удиви всех

сделай mmap()!

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

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