Ruby и не только, подсчёт строк

оптимизацию включил?

>if (e) do p = rawmemchr(p, '\n') + 1, ++count; while (p <= e);

это что за хрень?

смысл в общем понятен, но в этой строчке какаято херь написана.

>оптимизацию включил?

Вот ещё:)

> Вот ещё:)

ну ее ж не зря придумали :)

c -02

Time 1: 35.440000 Time 2: 8.840000

короче ты победил:)) но товарищ arsi всёравно всех сделал как тузик грелку:)

> смысл в общем понятен, но в этой строчке какаято херь написана.

таки да

> короче ты победил:)) но товарищ arsi всёравно всех сделал как тузик грелку:)

у него решение завязано на ОС и не соберется, например, на win и mac os

хотя конечно в полном решении надо делать #ifdef и выжимать все что можно используя код arsi для конкретной платформы

Если говорить о руби и безотносительно к алгоритму - можно сделать так:

seek(offset, whence) - перейти к концу файла
lineno - получить номер строки

>>if (e) do p = rawmemchr(p, '\n') + 1, ++count; while (p <= e);

>это что за хрень?

if (e != NULL) {
    do {
        p = rawmemchr(p, '\n') + 1;
        ++count;
    } while (p <= e);
}

или даже так:

if (e != NULL) {
    do {
        p = rawmemchr(p, '\n');
        count++;
    } while (p++ != e);
}

так лучше воспринимается? ;)

кстати, замена rawmemchr(p, '\n') на memchr(p, '\n', size) всего на ≈10% медленнее,
но так будет работать на любой платформе с ммапом (вроде даже на вендах есть аналог).

>у него решение завязано на ОС и не соберется, например, на win и mac os
а ничего, что в виндах не просто '\n' новая строка?

> а ничего, что в виндах не просто '\n' новая строка?

по-твоему это влияет на результат?

> а ничего, что в виндах не просто '\n' новая строка?

ничего, линуксу это жить не мешает.
и да, если парсить виндовый файл, в котором \n встречается только после \r
(справедливо для всех text/plain файлов), то никаких проблем.
совсем другое дело — мак, где конец строки представлен только символом \r.
(или, пока я был в анабиозе, уже что-то изменилось?)

вариант проверки вендовых/досовских текстовиков.
считается _только_ количество CRLF, ну и +1,
если последняя строка на CRLF не заканчивается.
время подсчёта — в полтора раза дольше предыдущего варианта.

#define _GNU_SOURCE
#include <stdio.h>
#include <unistd.h>
#include <memory.h>
#include <sys/mman.h>
#include <fcntl.h>

#define  CR   13
#define  LF   10
#define  SUB  26

int main(int argc, char **argv) {
	int fd, count = 0;
	off_t size;
	const char *file = "lor-3920508-win.c";
	const char *p, *e;
	
	if (argc == 2)
		file = argv[1];
	if ((fd = open(file, O_RDONLY)) < 0 || (size = lseek(fd, 0, SEEK_END)) < 0 ||
			(p = mmap(NULL, (size_t)size, PROT_READ, MAP_PRIVATE, fd, 0)) == NULL) {
		perror(file);
		return -1;
	}
	if (size && p[size-1] == SUB)
		--size;
	if (size > 1 && (p[size-1] != LF || p[size-2] != CR))
		++count;
	for (e = p + size; e > p && e[1] != LF; e = memrchr(p, CR, e - p - 1));
	if (e++) do {
		p = rawmemchr(p, CR);
		if (*++p == LF)
			++count;
	} while (p != e);
	printf("%d\n", count);
	return 0;
}

> совсем другое дело — мак, где конец строки представлен только символом \r.
> (или, пока я был в анабиозе, уже что-то изменилось?)

вы таки долго там были :) в Мак ОС '\r' был только до 9-ки

>по-твоему это влияет на результат?
если там будет '\r\n\n\n\n' то скорее всего повлияет

а если файл не в однобайтовой кодировке, ведь это тоже может помешать

> если там будет '\r\n\n\n\n' то скорее всего повлияет

открой такое в редакторе и посмотри

> а если файл не в однобайтовой кодировке, ведь это тоже может помешать

man utf

> а если файл не в однобайтовой кодировке, ведь это тоже может помешать

мир несовершенен.

> мир несовершенен.

но не настолько же, пока вы все еще были в анабиозе, да - придумали utf, но для которого банальный поиск '\n' все так-же дает правильный результат

> но не настолько же, пока вы все еще были в анабиозе, да - придумали utf, но для которого банальный поиск '\n' все так-же дает правильный результат

> придумали utf

хм… а в каком году произошло это эпохальное событие? а то ведь до анабиоза я о такой кодировке и не слышал. о всяких utf-8, utf-16 (utf-16le/utf-16be, ucs2) и utf-32 (utf-32le/utf-32be, ucs4) да, слышал, но вот о кодировке utf, которая своим появлением каким-то магическим образом превратила все текстовые файлы в кодировку, «для которого банальный поиск '\n' все так-же дает правильный результат»…

и да, текст "А\r\n\n\nБ" под виндами в ихнем эталонном plain-text редакторе (notepad.exe) будет в две строчки (в начале второй строчки будут отображаться, ЕМНИП, кубики). опять же, в виду длительного анабиоза уточню, что это касается хп и более ранних версий оффтопика, висту и семёрку видел только на картинках.

> о всяких utf-8, utf-16 (utf-16le/utf-16be, ucs2) и utf-32 (utf-32le/utf-32be, ucs4) да, слышал

молодец, только не перечисляй каждый раз весь список - в отличие от вас мы понимаем о том, что речь идет о всем семействе кодировок

> каким-то магическим образом

вы не знаете базовых вещей - про то как работает assert, про С99, про то как задается конец строки в MacOS, про то как задаются символы в unicode - и это мы узнали всего за несколько ваших постов, может вам стоит подучится?

> и да, текст "А\r\n\n\nБ" под виндами в ихнем эталонном plain-text редакторе (notepad.exe)

таки да( правда notepad.exe даже конфиг от вендового Quake в одну строку показывает ), а вот visual не захотел показывать такой файл как текст - даже при явном указании, что открывать как текст, только hex, справедливо полагая, что такой файл уже не текстовый, других редакторов нет

> молодец, только не перечисляй…

мы уже на «ты»?

> …каждый раз весь список - в отличие от вас мы понимаем о том, что речь идет о всем семействе кодировок

т.е. вы таки утверждаете, что для текста в _любой_ из utf-* кодировок «банальный поиск '\n' все так-же дает правильный результат»?

> вы не знаете базовых вещей - про то как работает assert

опять кривой либастрал?

> про С99

это не _базовый_ стандарт. базовый — это как раз анси с, где переменные можно объявлять только в начале блока. предположив, что у меня объявление переменных в начале блока inspired by pascal, вы скорее показали _своё_ незнание основ.

> про то как задается конец строки в MacOS

а оно мне нада?

> про то как задаются символы в unicode

кто бы говорил об юникоде после эпик фэйла с «банальный поиск '\n' все так-же дает правильный результат» ;)

> может вам стоит подучится?

примите валерьянки.

> мы уже на «ты»?

у вас комплексы?

> т.е. вы таки утверждаете, что для текста в _любой_ из utf-* кодировок «банальный поиск '\n' все так-же дает правильный результат»?

для utf-7 нет - но он практически не используется и не рекомендован, везде utf-8/16/32

> опять кривой либастрал?

продолжаете отмазываться? как хотите

> это не _базовый_ стандарт

на дворе 2009-й

> предположив, что у меня объявление переменных в начале блока inspired by pascal

я просто не знал, что есть люди, которые живут в прошлом

> а оно мне нада?

нет конечно

> примите валерьянки.

:)

> у вас комплексы?

конечно. нельзя?

> для utf-7 нет - но он практически не используется и не рекомендован, везде utf-8/16/32

переформулирую вопрос: вы утверждаете, что для текста в _любой_ из utf-n кодировок при n={8|16|32} «банальный поиск '\n' все так-же дает правильный результат»?

> на дворе 2009-й

> я просто не знал, что есть люди, которые живут в прошлом

мало ли чего вы не знали. может, вы ещё не знали, что есть компиляторы, которые понимают только анси с? и да, их нельзя заменить на «мегафичастый» гцц, т.к. последний не имеет необходимых сертификатов (industrial safety, знаете ли). и обновить на более современные версии либо невозможно, либо мегадорого.