djamshud, однако. позвольте. что конкретно Вас не устраивает в данном сдвиге и почему это Вы лично к сдвигу не относите? повторюсь данный код из файла "123" делает файл "1123" по сути освобождая первый символ под запись. ужо рашпилем из этого сделал сдвиг на 2 байта. но выкладывать пока не буду. надо ж для начала понять, что ж такое сдвиг.

17dufa,
1. Хороший сдвиг - это если бы вы открыли файл и просто приписали бы к нему в начало данные. Как делает обычный

только не в конец, а в начало. Так вот, так сделать по-простому нельзя.

2. Ваш код не работает. Причну я уже описал.

djamshud, 
пункт 1 - эт я б сдвигом не назвал. так что не стоит бросаться громкими словами, для начала надо словари синхронизировать  

почему мой код не работает - можно по-подробней?

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

Ваш код плох:
1) сам по себе
2) медленный
3) не работает

Было:

стало:


было:

стало:


было:

(в конце перенос строки, однобайтовый \n). стало:

(непечатаемые символы). в хексе:


Причину я уже называл выше.
Было очень приятно поработать тестером. Счастливой отладки;).

djamshud, я б назвал это вставкой, но не сдвигом. но эт вопрос терминологии. пусть будет сдвигом. для файлов такого сделать низя, так что придется обходиться "обычным" сдвигом или копированием.
за работу спасибо, жаль она была проделана зря - приведенный код - не готовое решение, а некая отправная точка.
в таком свете остается только пункт 2. так вот - медленный по сравнению с чем?
и помниться Вы про sync говорили - что Вы имели в виду и как это отразиться на работе кода?

вот результат небольшой доработки рашпилем:

вот этот вариант умудрился из 
"hello
world"
сделать
"khello
world"
  

чего нет в этом варианте - если двигать на несколько символов (SHIFT_SIZE > 1) и размер файла не кратен SHIFT_SIZE будет жопа на последнем сдвиге, то есть когда двигается самое начало файла, думаю топикастер сможет допилить этот косяк.
*по идее SHIFT_SIZE равен длине строки, которую надо вставить плюс длина "\n".



Это сообщение отредактировал(а) 17dufa - 15.4.2010, 15:17

>за работу спасибо, жаль она была проделана зря

Почему же зря? Вы привели код в более работоспособное состояние. Правда его адская арифметика нагоняет на меня тоску, разбирать его не хочу.

>медленный по сравнению с чем?

По сравнению с более верным решением, основанном на перемещении буферов и еще более годном - mmap-а файла и двигания его данных. Буфер вы уже сделали, но сами признаете, что работает не всегда. Mmap платформозависимое решение,.. Хотя в boost-е может быть и есть какие-нибудь кроссплатформенные костыли. С другой стороны, в данной задаче упор на скорость записи данных, поэтому буферизированное (буферы должны быть большими, Mb например) копирование не проиграет.

>и помниться Вы про sync говорили - что Вы имели в виду и как это отразиться на работе кода?

Была проблема сбоя стримов при сбросе данных на диск, который у меня происходил на каждой новой строке.

Далее пример решения этой задачи при использовании mmap(в Linux). Примечателен простотой - отсутствием магических констант и безумных вычислений seek-ов.




Это сообщение отредактировал(а) djamshud - 15.4.2010, 16:52

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

какая именно константа является магической? ну акромя имени файла?

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

мап файла на память и правда быстрей работает? проверяли? можно в цифрах? хотелось бы еще и сравнение расходов по памяти, ну чисто для полноты картины.

17dufa, ну да, меня что-то перклинило на мысли, что вы хотели просто присоединить данные в начало файла.

>какая именно константа является магической? ну акромя имени файла?

Там дело не в магии оказалось, разобрал код, понял.

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

Вы там весь файл побайтово двигали.


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

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

В данном случае я просто показал более простой на мой взгял и почти рабочий способ решения задачи. Почти, потому что есть какое-то ограничение на размер файла для функции open, которое впрочем можно обойти.

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

17dufa, Если первоначальная задача была "смотрите! я умею копировать данные внутри файла!", то да, задача другая;). Но что-то мне подсказывает, что вы хотели хорошенько их двинуть.

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

Если хотите циферки, то доделайте свой вариант, и сравним, мне тоже интересно. Для завтравки вот небольшой тест сравнения побайтового чтения, буферизированного чтения (1Mb) и отражения файла в память. В качестве небольшой внешней нагрузки и проверки правильности работы методов решается задача поиска количества вхождения байта '1' в файл. Использовался видеофайл размером 1000Mb. Перед каждым измерением файловые буферы операционной системы сбрасывались.

Побайтовое:
Alg: byte, count: 4195218
Время выполнения 14.299s
Программа занимала 64кб.

Буферизированное:
Alg: buf, count: 4195218
Время выполнения 1.632s
Программа занимала 1064кб.

Отображение в память:
Alg: mmap, count: 4195218
Время выполнения 0.729s
Программа занимала 64кб.

Во втором тесте эксперементальным путем был найден еще и "идеальный" размер буфера - 8кб, при его использовании время сокращалось до 0.75с, т.е. в плотную приближалось к mmap. Это скорее всего уже тесно связано с типом и настройкой файловой системы, а то и аппаратными особенностями носителя информации.