Суть такая, что формат есть формат файла, который весьма сложный и не простой. 
Нужно иметь  читать и писать в файлы этого формата. Однако удобно говорить не файлы, 
а файловый образ. Таким образом вводя термин "образ" и абстрагируемся от понятия "файл".

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

При реализации захотел организовать работу с "образом", чтобы последний не знал о
том, что в конечном итоге это ? Файл или память?

В виду того, что нехочу мудрить свой велосипед с И/О решил подать на вход класса образа ссылку
или указатель на некий слой абстракции имеющий И/О опреации и тут очень хорошо выступает
библиотека стримов std::iostream.

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

Пока моя архитектура выглядит так:

class Image
{
public:
    Image( std::iostream& streamRef )
        : stream( streamRef )
    {}
private:
    std::iostream& stream;
};

class Calculator
{
public:
    Calculator()
        : srcImage( srcFile )
        , destImage( destFile )
    {}

    void openSource( const std::string& filename )
    {
        int mode = fstream::in | fstream::binary;
        srcFile.open( filename.c_str(), mode );
        if( !srcFile )
        {
            throw std::runtime_error( "File wasn't opened" );
        }
    }
    
    void openOutput( const std::string& filename )
    {
        int mode = fstream::in | fstream::out | fstream::trunc | fstream::binary;
        destFile.open( filename.c_str(), mode );
        if( !destFile )
        {
            throw std::runtime_error( "File wasn't opened" );
        }
    }

private:
    std::fstream   srcFile;
    std::fstream   destFile;
    Image          srcImage;
    Image          destImage;
};

Ьожет ли кто-то просмотреть что-то лучше или дать какую-нибудь критику?

ну тогда расскжите немного об образе.. чем он представлен и как с ним работать ..

Добавлено @ 19:43

ну так работайте с потоком, только не прячьте его внутрь..

Добавлено @ 19:45

имелось ввиду это.. оно никак не должно быть запрятано так далеко от юзера..

Добавлено @ 19:46

вот с него надо и начинать.. подумать каким удобным видом можно представить этот формат пользователю.. 

Это сообщение отредактировал(а) mes - 21.8.2011, 19:46

mes, 

Это формат файла Portable Executable. Структурно состоит из объектов служебных структур которые задекларированы
в winnt.h входящим в Microsof Platform SDK и как правило идет в поставке с любой Visual Studio.


Так я вроде как не прячу. Класс образа ничего не знает о том чем является стрим по сути? Он просто его  берет
и использует. А вот сам стрим создается в классе более высокого уровня, который вполне имеет право знать, что за
стрим, толи stdin, толи файл?!


Не совсем понял мысль. Прошу подробней

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


если даже и объзан знать, он не должен отбирать возможность открыть и подготовить поток так, как это требуется пользователю..

Добавлено @ 20:02

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



Это сообщение отредактировал(а) mes - 21.8.2011, 20:05

mes, 



Класс Calculator  это уже пользовательский код, класс входящий в инфраструктуру приложения, а не библиотеки.
Сорри, что не  упомянул этого!



Возможно сказанное мною уточнений выше улучшит понимание. 



В принципе это уже детали. Смысл их знать? Ведь скажи я ELF или Macho-O, то суть задачи бы не поменялась! Архитектура во
всех случаях подошла бы!

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

не вижу надобности хранения потока в image.. 

mes, 


Image это класс по работе с форматом. Возможно будет куда лучше его перименовать в PortableExecutable или еще во что-нить.

Цель и назначение это класса парсить служебные структуры и возвращать их на выход.
Именно он должен знать по какому смещению искать IMAGE_DOS_HEADER, именно он должен посмотреть в dosHeader взять его
член e_lfnew и используя это значение как смещение в потоке прочитать новый хидер IMAGE_NT_HEADERS32 или IMAGE_NT_HEADERS64,
а какой именно 32 или 64, опять же Image должен узнать и по результату проверки прочитать. Ну и другие действия.

Но для этого ему нужно  уметь работать с потоком! А для этого ему нужно получить как-то этот поток, как иначе, если не:

Как иначе-то передавать в класс поток чтобы он не знал об исходном стриме? Только по указателю или ссылке на базовый, разве не так?

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

mes, 

Да, это верно. Образ будет "умным". Думаю тема исчерпывается, но  пока тему не закрою. Кто знает, может еще один более опытный чем я товарищ
заглянет и скажет имхо.

Ну а если не привязываясь к формату PE, как бы вы сделали для ELF ?

Я бы сделал библиотеку из двух частей: 1) ELFimage и 2) инструментальные функции, к примеру addCodeSection( ELFImage &, void* , size_t ) , etc.
Но даже тут, ELF формат не такой уж и тривиальный и следовательно  класс "образа" придется делать интеллектуальным!

для "умного" образа желательно прямое чтение, а значит концепция потока не самое удачное решение..

Добавлено через 6 минут и 7 секунд
если хотите использовать потоки на входе, то тогда Вам нужно либо хранить все данные, либо предоставить потоковую возможность на выходе..

Добавлено через 8 минут и 41 секунду
например можно при чтении потока для каждого поля вызывать соответсвующей ему метод интерфейса.. 
тогда получится "сквозная" обработка данных.. но мне кажется это не то что Вы хотите..

Добавлено через 10 минут и 53 секунды
вначале надо попробовать представить и объяснить словами какой интерфейс нужен пользователю.. что за инструментарий он должен предоставлять, и как это должно выглядить логически,  а уж после думать как его реализовавать технически..

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

Добавлено через 14 минут и 49 секунд
например задача условно  может быть такая : посчитать сколько секций,  и добавить еще одну.. 
вот попробуйте записать подобное вначале условным пользовательским кодом, потом с условной библиотечнойреализацией.. 
имхо должно помочь приблизится к цели.. 

 

Это сообщение отредактировал(а) mes - 21.8.2011, 20:58