Просто читайте, как обычно. Быстрее fgets все равно не выйдет

@avp, я не такой опытный, как вы, но сообразительней, а потому утверждаю, что это возможно реализовать нестандартно иными средствами(есть идеи), но за счёт некоторого ущерба в том, чем это реализовывать, но с гораздо большей скоростью и огромным выигрышем при поиске в файле, чем возможно std средствами С/С++.

Уважаемый @Дух сообщества, здесь решение вопроса требует нестандартного подхода, а поэтому понятен не каждому!

аналогичную управляющему символу '\n - ну так и ищите этот символ бинарным поиском. В хексах это будет 2-байта 0x0D0A = CRLF. Как найдёте, значит следующий символ это начало новой строки.

@PRODIGY Поясните про бинарный поиск...

@Reason "это возможно реализовать нестандартно иными средствами(есть идеи)" Вы бы поделились своими идеями, это всегда качество вопроса повышает, видно, что человек работал.

@MBo не знаю как на сишке, а в ассемблере это просто mov ax,0x0d0a --> repne scasw.

@PRODIGY Понятно. Это линейный поиск, а не бинарный (бинарный применяется для поиска в сортированных данных). Получается для каждой строки - чтение всех данных от начала файла до неё.

@PRODIGY не путайте пожалуйста терминологию, иначе очень сложно что либо понимать; бинарный/двоичный - имеет разный смысл; почему так? не знаю, этот вопрос точно не ко мне, а к лингвистам; однако же суть от это не меняется; вы имеете ввиду двоичные операции над данными/кодом, однако же применительно к поиску - термин "бинарный" означает конкретный алгоритм, без указания на реализацию оного; т.е. "бинарный поиск" - это абстрактный алгоритм поиска [в упорядоченных сортированных данных]

@InterceptorTSK > вы имеете ввиду двоичные операции над данными/кодом - я имею ввиду поиск двоичных данных в тексте, к которым относятся CRLF. имеет разный смысл; почему так? не знаю - ну так узнайте, а потом утверждайте, что они имеют разный смысл. И что значит Никто и ни что не может рассчитать в таких данных начало n-ой строки ? Если база = обычный тхт-файл, то вопрос решат ~20 ассемблерных инструкций, а если не тхт, то значит есть спец.софт, который создал эту базу.

конкретней на пальцах: есть файл строк размером в 1Гб, сколько там строк - вы не знаете, начала [позиции/смещения] каждой строки - вы не знаете, вычитайте из этого файла [не читая весь файл] например - 9756-ую строку

и да, если всё так просто, так вы прям щас создайте файл строк в 1Гб))) и получите из этого файла 9756-ую строку, но весь файл не читайте, начало файла - не трогайте, вообще ничего не парсите) оно же вам не нужно? не нужно) ну вот и запросто и найдёте каким то волшебным способом где начинается 9756-ая строка в этом большом файле, а как ассемблером найдёте - то непременно сюда выложите результат - это же не проблема? вперёд!

@InterceptorTSK, так я вам и говорю, что на любые перечисленные вами требования уйдёт 20 строк асм.кода. Если нельзя читать файл целиком (хотя вы это сами придумали), то можно читать его фрагментами по 1Кб. Или вы теперь скажете, что даже читать файл нельзя?

@PRODIGY вы совсем полностью на своей волне что ли? у автора даже русскими кириллическими буквами написано - "быстрый переход на начало новой строки"; какой строки? любой строки, любой n-ой строки; последовательное чтение кусками по 1Кб - быстрым доступом не является, опять по определению; где тут быстрый доступ? что бы добраться до строки - нужно из 1Гб последовательно читать и парсить например 500Мб? вам чем ассемблер поможет то?

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

детский сад, с каким-то надуманными условиями.

@PRODIGY надо полагать что вы даже сценарий на это придумать не в состоянии? есть война и мир того самого лео толстого, вы читаете сей эпос, затем на каком то месте закрываете его нафиг, а завтра хотите продолжить чтение; а вы каким образом обозначите где либо место на котором вы остановились читать? а если это не банальная книшка, а нечто - к чему обращается иное нечто, и хочет хочет знать где строчки лежат, но не хочет вычитывать весь файл - потому что файл - большой; т.е. такие сценарии конечно же не существуют ага?

Ну, ребята, вы, блин, даёте - чем сложнее и нестандартнее вопрос, и требует нестандартного мышления и подхода, тем вы больше "опускаете" автора вопроса! Это говорит о "серости" и неспособности основной массы людей мыслить нестандартно и решать непростые задачи, и, в знак этого, вы "опускаете" автора! А следовало бы действовать наоборот! Спасибо всем, кто откликнулся на вопрос ответами! Разберём всё по-порядку в нескольких комментариях: 1)@PRODIGY, вы чаще кодите на asm, а потому и подход у вас 'бинарный'. Вы, похоже, имели ввиду под 'бинарным поиском' поиск в файле, открытого в двоичном режиме

Ни в текстовом, ни в двоичном режиме данную задачу не решить, поскольку нет подходящих для этого функций(про макросы не знаю) в арсенале С, С++, возможно, и в asm(его здорово подзабыл)! Вы, похоже, не совсем поняли вопрос и его нюансы; 2)@InterceptorTSK, вы хорошо поняли мой вопрос и наиболее широко и грамотно его рассмотрели; 3)@Harry, на данный момент я хреновый кодер, ибо asm, изученный в 1990 и 1995 г. без практики, здорово подзабыл, а С++ тоже без практики подзабыл за 5 лет, но по мышлению и алгоритмам, думаю, не плох и есть идеи по решению данного вопроса. Оба ответа близки к моим идеям

@Reason "Ни в текстовом, ни в двоичном режиме данную задачу не решить, поскольку нет подходящих для этого функций" - а что такое "функция"? и почему её нет? любая функция не растёт на дереве, и не является абстракцией в вакууме, и обычно "функция" обращается к более "фундаментальным" функциям, чем она есть сама; рассмотрите то что вы рассматриваете с точки зрения именно "фундаментальных" функций; вы можете читать, можете писать, а больше ничего не можете, потому что ничего другого - нет; и всякое любое производное - на этом и строится, потому что строить производное - больше не на чем

4)Здесь общий принцип - это первоначальное чтение всего файла от начала до конца и фиксация конца или начала каждой новой строки, с занесением этих данных, как варианты, в строку, массив, различные контейнеры, в файл. Тогда мы получим псевдопроизвольный доступ к началу каждой новой строки за счёт первоначальной, так сказать, инициализации файла. При таком подходе файл может быть изменяемым и строки могут быть произвольной длины, но до инициализации! @InterceptorTSK, вы правильно указали, что истинного произвольного доступа не добиться, однако можно решить задачу 'псевдопроизвольным' доступом.

нужно точное чтение [получение] не начала строки, а начала логического блока данных, обычно это 4Кб; так вот произвольный доступ к строкам - это кеш блоков по 4Кб, и метадата для этих блоков; весь текст [данные] - делятся на блоки по 4Кб, и для каждого такого блока смещение на начала строк - относительно начала блока; таким образом получится что-то типа 4Кб_блок_0 = { 6, 38, 258 }; 4Кб_блок_1 = { 62, 86, 126 }; индексация в данном случае привязана к жёсткозаданным размерам физических данных; читать нужно именно физическими блоками, и рыться нужно в физических блоках [метадата блоков]

@Reason, если в своих вопросах вы будете ограничиваться более конкретными условиями, то качество советов повысится. Я сказал про fgets, подразумевая, что это любой файл (поток данных, т.е. это может быть sequential socket, serial device или почти все что угодно). Если ограничиться дисковым файлом, то (и в *nix-ах и в винде) можно использовать так называемый mapping файла в память (реально в *nix данные файла всегда будут оставаться в файловом кэше ОС) и искать в нем '\n'-ны как в памяти, например memchr() будет работать в самом деле быстро (это все о нестандартных подходах и т.п. -))