длиная то процес удаления
может очень замедлить загрузку данных
звиняюсь, но это утверждение - полная фигня
.
Самая медленная операция здесь - чтение файла, и процессор фактически стоит пока идут любые операции с диском. Даже если файл полностью в процессорной кэши, всё равно времени пробежать по строке будет выше крыши. Это O(strlen(chbuf)) тактов. Причём константа где-то 3-4 (проверь ассемблерный листинг). Что даст по верхней границе 256*4= 1024 такта. 1 ГГц процессор обработает миллион таких (256 символов) строк в секунду. Это 1 Гб :!: . Оперативной памяти хватит на секунду в лучшем случае
. А у диска время доступа в лучшем случае 5 мс. Сеть - ещё медленее (если не гигабит).
Тем не менее, способов минимизировать возню с символами много. Хотя код RXL вполне работоспособен и фактически есть strrchr (поиск с конца строки) плюс забиение нулями найденного. Ну если использовать поиск с начала, то можно написать типа проще (хотя вариант RXL будет быстрее для "нормальных случаев" большого кол-ва не-переводов строк и малого - переводов строк в конце)
вариант 1:
char* cp=strchr(chbuf,'\n');
if(cp) *cp=0;
вариант 2:
char* cp;
(cp=strchr(chbuf,'\n'))?*cp=0:;
Ну и надо бы написать
#pragma intrinsic(strchr)
чтобы эта библиотечная ф-ция компилировались инлайном. Съэкономишь с десяток тактов на call/ret