Всем привет!

Проектирую библиотеку по работе с файлами и потому интересно какие собственно известны способы работы с файлами ? Пока знаю работа с потоками iostream и работа на уровне ф-ций fseek, fread, fwrite из stdio.h. Также полагаю что есть что-то в бусте.

Вопрос №1: Какие вы знаете способы работы с файлами ?


Опишу свою ситуацию на чем заморачиваюсь. Ввиду того что пишу библиотеку по работе с исполнимыми файлами и пишу ее с учетом портабельности, то вынужден задать единную систему типов. Пока остановился на stdint.h и ее uint32_t, int64_t, etc , но на будущее напишу свою библиотеку типов, которая будет учитывать еще и порядок байта, типа LE, BE.
Помимо типов еще нужно учитывать, что средства разработки программ под разные платформы(читай компиллеры и ОС) имеют разные ф-ции по доступу и работе с файлами и поэтому написал библиотеку ф-ций врапперов wrappers_io.h и задал ее в типах stdint.h , написал первую частную реализцию wrappers_io_win32.cpp , а теперь хочу применить эти враппере в более высокой по абстракции библиотеке!

Вопрос №2:
Типы по сути-то нужны, для того чтобы корректно читать файловые концепции, к примеру какой-нить заголовок. Но в каких типах задавать ф-ции врапперы(возвращаемые типы, аргументы ф-ции)? Может имеет смысл их уже задавать через обычные С++ - типы, не повредит ли это портабельности ?

Подумал и выяснил, что работа будет вестись не только с файлами, но и с памятью, то возможно мне будет удобней задать всю работу через так называемы потоки! А уж они будут подразделяться на работающие с файлами и с памятью, в будущем возможно задам и работающие с сетью(для того чтобы несколько реверсеров могли трудиться надо одним файлом совместно). Поэтому возникает следующая иерархия: 

class I_Stream;
class C_FileStream : public I_Stream;
class C_MemoryStream : public I_Stream;

Сразу же напрашивается, что буду читать, писать, ставить указатель, то первые вирт. ф-ции это:
Read, Write, Seek.

Вопрос №3:
Может имеет смысл разделить на I_StreamInput и I_OutputStream , или же лучше все-таки держать в одном классе, а в будущем перегрузить операторы << , >> для удобства работы ?

ЗЫ:
Прошу подмогнуть, а то извилины мозга уже настолько завязаны, что думать эффективно уже не получается. Может кто-то имел опыт, буду рад если поделитесь мыслями, можно в личку или по аське! ;) Надеюсь что появятся опытные люди, т.к. нацелен на выявление малвары, т.е. благие намерения! ;)

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

http://forum.vingrad.ru/index.php?showtopi...t&p=2033290

Спасибо, буду вникать! ;) Но также буду рад мыслям и других форумчан, почему-то верю, что тут есть еще опытные люди! ;)

boost filesystem

unicuum, boost.filesystem работает с путями к файлам, а не с файлами

С файлами работает STL, что ещё надо?

Чем не устроили банальные iostream?

Отпишусь по состоянию дел на данный момент ;) В виду того, что эта библиотека не моя работа, а мое хобби возвращаюсь к ней не так часто.

Выбрал путь разработки стримов, как вывод есть два пути:

Путь №1 (частичное ООП):

1)
Разрабатывается libio со след. иерархией интерфейсов:

class i_stream_base;
class i_file_stream : public i_stream_base;
class i_memory_stream : public i_stream_base;

2)
далее разрабатываются конкретные классы-реализаторы:

class c_file_stream_win32 : public c_file_stream;
class c_file_stream_linux : public c_file_stream;
class c_file_stream_maxos : public c_file_stream;
etc.
аналогично и для c_memory_stream


Путь №2 (не полный ООП):

1)
разрабатывается библиотека врапперов вокруг нативных АПИ-функций для ОС, к примеру во круг CloseHandle() враппер closefile(). Есно дело несколько реализаций одного и того же протипа враппера, потому что различные ОС!!!

2)
разрабатывается интерфейся, аналогичные п.1 в Пути №1

3)
Реализовываются классы c_file_stream, c_memory_stream используя ф-ции врапперы!


В чем прелесть первого пути ? - в том что это более логично для ООП.
В чем прелесть второго ? - в том что врапперы проще отлаживать и не так часто, плюс классы реализаторы c_file_stream , c_memory_stream не так часто придется править

Я пошел путем №2 мне он ближе и удобней. Вообще, если кто-нибудь уже реализовывал подобное буду рад услышать его опыт!

Все предложенные пути ПОЛНОСТЬЮ покрываются стандартными стримами С++ (std::iostream) причем гораздо лучше. В чем цимус изобретения еще одного велосипеда с квадратными колесами?   

xvr, 
Если чел заморочился, значит так надо! Не зачем выяснять обходные пути, надо или помочь если умеешь или пройти мимо!
У меня этот проект расчитан не только на обычные компы, но и на железки. А там при малейшем изменении crt, т.е. стандартных вещей сразу же придется чуть ли не все ядро перекомпиливать. Нахера мне это надо ? Уж проще прогружать своего рода плагины, чем ядро! Ядро, отладить и сделать "стабл".
Его же использовать и для обычных стационарных компов, чтобы в случае обнаружении баги, можно было включить  очередной фикс в очередное перепрошивание ;)

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


Ну это хорошо, что Вы сразу раставили, что грозит человеку, когда он пытается вернуть вас с обходных путей, на ровную дорогу..


Не вижу логики в том, чтоб отказываться от стл. Нужно стабильное ядро - делайте, но зачем изобретать велосипеды ?!

хотя нет, не обращайте внимание на сказанное .. я лучше пройду мимо..


Это сообщение отредактировал(а) mes - 3.4.2010, 00:31

>>не кажется Вам что это звучит грубовато, по отношению к человеку, который от всей души хотел Вам помочь ?
согласен, грубовато! Но честно говоря устал пояснять каждому свою ситуацию и пришел к выводу, что ООП все-таки классная штука и если ты клиентский код, то тебе нафиг не надо знать как устроено и что там, главно что есть! )))
Так и в задаче, если есть дано, то не надо искать обходное!

Ведь по сути, когда мы выполняем задачи заказчика, то мы делаем то что нам заказали, а не чтото другое!

Думаю вполне обосновано раздражение спрашивающему про одно, а ему про другое! Ведь в исходном сообщении, строго задано направление "прошу помочь разработать", а не "найти альтернативу" ;)

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

Поработаете с ним больше и иллюзия сойдет.. Да ООП хорошо, да лучше чем простое процедурное проектирование, но одного ООП мало, чтоб нормально решить задачу.


Не пойму как  это связано с ООП, но ладно.. давйте посмотрим что дано :

прежде всего название

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

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

Может я чего и не увидел, тогда не могли бы Вы показать, какое из Ваших высказываний делает цитату 

,так сказать, неадекватной применительно к Вашей теме ?

Это я вижу
А вот этого я не вижу.
iostream - это не 'обходной путь'. Он ПОЛНОСТЬЮ соотвествует вашим требованием из первого поста
Пытаюсь помочь - посмотрите хотя бы документацию на iostream   
Какое ядро? Вы о чем?! iostream часть стандартной библиотеки С++, к ядру отношения не имеет.
Видимо тяга к изобретательству   
Вы хотите сказать, что самописная библиотека будет отлаженнее и стабильнее чем стандартная библиотека С++ ?   
iostream   

Не хотите брать ее целиком - хотя бы посмотрите на дезайн, он отличается от вашего, причем в лучшую сторону. Ваш дезайн мягко говоря кривоват   В вашем понимании ООП подхода классы будут плодится в геометрической прогрессии

Открыли для себя ООП? Тогда понятно стремление что нибудь написать   Открою вам страшную тайну - iostream тоже ООП   А еще есть шаблоны .... 

  
Был у меня давным давно один приятель (в году так 1989). Большой любитель узнавать что то новое. Я тогда как раз написал некую текстовую оконную систему (на самописных thread'ах под DOS). По идеологии построения она очень напоминала Windows (окна, события, очереди, потоки). Его так поразил этот дизайн, что он недели 2 писал всякие окошки, ходил восторгался и пр. Потом он открыл для себя Windows (тогда это была 3.1). Тут уж он восторгался и игрался не меньше месяца. Свою основную работу он на это время полностью забросил, в результате чего, когда пришли сроки, работа оказалась не выполненной. Все планы лаборатории, где он работал, оказались сорванными, а его самого чуть не уволили.
Мораль - восторгаться нужно осторожно   


Про тоже самое
Посмотрите дезайн iostream и скопируйте оттуда

Единственное, что в ваших требованиях стоит 'выше'  iostream, это работа с форматами файлов (endianess, структуры и пр). Вот это разрабатывать можно, но оно не имеет НИКАКОГО отношения к собственно доступу к файлу (iostream или аналог этот доступ замечательно обеспечат). Вот только я не увидел нигде даже намеков, как это может быть сделанно   

  
Приходит к иллюзионисту мужик, и говорит:
- Я вам придумал отличный фокус. Представьте себе - арена, оркестр играет марш. На арену выходят 10 униформистов в строгой черной униформе. Они делают круг и становятся вокруг арены. Сверху падает лестница. Тут, под барабанную дробь, на арену выходите вы, весь в белом, и начинаете медленно подниматься по лестнице в лучах софитов. И вдруг на середине подъема исчезаете. 
- Замечательно, и как же это сделать?
- А я откуда знаю, вы фокусник, вы и думайте!

Добавлено через 1 минуту и 56 секунд
Кстати, о птичках -
 Если вашу ситуацию приходится пояснять каждому есть повод задуматься, возможно в вашей ситуации что то неправильно