Всем привет! Подскажите как решить такую проблему: Я объявил переменную типа file; Подскажите как подсчитать количество строк в файле?
Файл простой текстовой... Точнее я хочу чтобы файл был с расширением другим, но редактировать его можно было как текстовой
а если так? Code: var Strings: TStringList; ... Strings := TStringList.Create; Strings.LoadFromFile('c:\vdebug.txt'); ShowMessage(IntToStr(Strings.Count));
Ну если файл текстовый то лучше f: text; Если таким образом то кол-во строк посчитывается мега-тривиально
Подсчет на PHP Если php то: PHP: <? $file= file('имя_файла.тхт'); echo count($file) ?> не забывай правильно указать путь до файла
2 energ77 а теперь посчитай таким образом кол-во строк в файле весом 3 гига. слабо? если Си то Code: FILE* f; int cnt; char buf[256]; f = fopen("filename", "rt"); if (f) { while (!feof(f)) if (fgets(buf, 256, f)) cnt++; fclose(f); }
slesh Эм, а зачем считывать строки? Вот моя вариация на C#: Code: using System; using System.IO; namespace ConsoleApplication1 { class Program { static void Main(string[] args) { int numLines = 0; using (FileStream fStream = new FileStream(@"D:\1.txt", FileMode.Open)) { // Если файл непустой. if (fStream.Length != 0) { int b; numLines = 1; while ((b = fStream.ReadByte()) != -1) { // Если считан символ '\n'. if (b == 10) { ++numLines; } } } } Console.WriteLine(numLines); Console.ReadKey(); } } }
действительно, куда лучше побайтно считать файл кстати, твой код просрётся на маковских файлах строго говоря, для небольших файлов только TStringList осилит задачу при любом формате файла, а для гигабайтных файлов решения ещё никто не привёл))
2 X-rus дело в тому, что по сути это одно и тоже, вот только в случае со строчками сишный CRT/LIBC буферизует данные в памяти, что намного ускоряет работу 2 fd00ch я привел. спокойно будет работать и на 100 гиговых файлах. главное тип переменно cnt поставить int64. А про мак формат - он и нах никому не нужен потому что редкий очень под винду. а в маке, там gets умеет читать его
slesh 1. если я правильно понял - твой код не осилит файл, в которои строки занимают больше 256 символов) 2. скорее всего он также просрется если переносы отличны от CRLF 3. если плюнуть на перевод строки, то код проверки файла любого размера привели выше, с использованием textfile)) 4. textfile в delphi тоже работает с буферизацией, никто там отдельные строки из файла не считывает, хапают блоками 5. ну и общий "фи" ко всем решениям - 99% что они все просрутся с юникодными файлами, где в переносах строк черт ногу сломит))
2 fd00ch 1) осилит, потому что если строка будет больше, то она обрежется. но непосредственно сама строка будут всё же прочитана, только в буфер не помещена целеком 2) да будет тебе известно что перенос строк для fget идет по стандарту Posix/C90/C99 то есть символ \n а то, что MacOS нарушая стандарты сделало перенос \r то это её проблемы 3) я привел на Си а не на Делфи 4) ну да буферизация есть везде почти 5) да будет тебе известно, юникод - это принцип кодирования текста, и он не затрагивает символы переноса строки. и это дело зависит от программы кодировщика. по этому символы \r\n записываются также, только для каждого будет двухбайтовая кодировка. хотя некоторые программы всё равно оставят однобайтовую. Если дело на то пошло, то тут нет вообще ни единого правильного метода, потому что самый правильный метод это файлмаппиг в память блоками кратными размеру страницы и размеру кластера, и далее посимвольная проверка. Но кому блять она нужна такая оптимизация если люди юзают тут делфи!!!!
slesh 1. возможно, в С не силен. но не удивлюсь, если такая тупость там возможна - прочитал всю строку, а возвратил часть) как искать остаток и его длину - х.з... 2. юзеру похер на всю эту порнографию - ему нужно узнать число строк и если прога на этой "простой" операции просирается - то и прога, и её создатель получают соответствующую оценку... 5. ты паришь, ещё как зависит. хотя бы то, что вместо CR LF получается CR 00 LF 00. есть и другие отличия, подробности - в вики в статье Перенос строки
fd00ch, не ну холивар, раз уж всякие маки и прочую хрень предлагаешь, если действительно тут про Delphi спрашивают, если бы я писал, то искал бы LF в строке, а на CR не обращал внимания. Во во.
2 fd00ch 1) нет это в делфи тупость. тут строго задано что считать не более 255 символов. можно поставить вообще 1 и тогда будет еще более оптимальнее решение, а то что делфи будет выделять памяти для строки и потом помещать в неё всё строку (хотя это даже и не надо) - это весьма плохо. и будет сказываться на производительности. 2) да похеру, как и что написано, но если человек не знает как делать элементарное, то эта часть особой роли не играет. Да и не было указано что и как должно работать. 5) ну давай раз на то пошло то почитай всё туже википедию где будет сказано CR (ASCII 0x0D) используется в 8-битовых машинах Commodore, машинах TRS-80, Apple II, системах Mac OS до версии 9 и OS-9; При этом последняя версия девятой линейки это 9.2.2 которая была выпущена - 6 декабря 2001 так что это уже не актуально. Хотя тут дело всё зависит и от файла который ты загружаешь, т.к. в Си есть функции и для работы с юникод файлами.
