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

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

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

Опишу и дополню первоначальную задачу поста.

Цель: Разработка класса\библиотеки по работе с форматом файла. Нужно читать\писать из файла этого формата. Условно назовем формат файла SuperFormat.

Некоторые нюансы формата:
1) Существует разные вариации для 32 и 64 бита.
2) Все заголовки(структуры) используемые в формате имеют одинаковый набор структур и названий полей в структурах для обоих режимов. Отличия в том, что в некоторых типов полей uint32_t или uint64_t зависит от битности файла.
3) Расположение некоторых заголовков в файле можно узнать только прочитав некоторые другие заголовки

Формат описывается следующими структурами:



Требования к коду:
Писать обобщенно независимо от битности формата. У меня пока это достигнуто с помощью C++ идиомы traits.

P.S.:
Подобные вещи встречаются на практике. К примеру если посмотреть в WinNt.h хидер идущий с MSVS то можно увидеть структуры IMAGE_NT_HEADERS32 и IMAGE_NT_HEADERS64. Эти структуры имеют один и тот же набор полей и имен этих полей, но некоторые поля отличаются типом. Эти структуры описывают PE32\PE32+ форматы. Но точно такая же ситуация и с Elf, Mach-O.

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



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

т.е. 

выглядит необоснованно однобоко, в отличии  от 

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

и так сбоку помимо traits есть еще if_-селекция.. 

Ну если присмотреть к объявлению FirstHeader_t, то видно что от битности не зависит! Смысл его загонять в traits-типы?


Не те что нравятся, а те что нуждаются в этом обобщении!
Как я уже привел выше FirstHeader_t в этом обобщении не нуждается. Зато типы SecondHeader32_t и SecondHeader64_t к общему SecondHeader_t нуждаются!

P.S.:

Ну как вся наша жизнь состоит из мелочей! ;) Куда уж без них?

ВЫ об идиоме упомянули type selection ?

да об ней 

Добавлено через 5 минут и 18 секунд

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


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

вот пример на скорую руку :
http://codepad.org/fJ5HPr0u

Это сообщение отредактировал(а) mes - 7.7.2013, 23:36

а не могли б код сюда выложить? унекоторых на работе не все сайты открыты 

Не думаю, что mes обидится если выполню просьбу вместо него. Вот:

    

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



Это сообщение отредактировал(а) mes - 8.7.2013, 13:47

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

Это сообщение отредактировал(а) EvilsInterrupt - 9.7.2013, 12:38

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

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

Добавлено через 6 минут и 18 секунд
image

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