я о stream`e как о концепте последовательного очередного доступа.. 
работа с image предполагает (в приведенном примере) произвольный доступ. 

Я кажется понял о чем Вы. Потоки в идеале не имеют конца и операций произвольного перемещения указателя. То что применяется у меня в примерах это по сути Blob из мира Java. Однако хочу заметить, что далеко не все С++ программисты с этим согласны и приводят в пример std::fstream где вполне можно перемещать указатель куда хочешь с помощью seekg()/seekp()  ;)

Но я с Вашим примером не согласен и вот почему. Мне он кажется не объектно ориентированным. ООП мысль ставит во главу разработки "объекты", понимая под ними Абстрактные Типы Данных, т.е. набор данных и взаимосвязанных операций оперирующих с этим данными. Исходя из этого SFImage содержащий данные FileHeader, SecondHeaders , но не содержащий взаимосвязанных операций read()/write() не может являться объектом. Это просто некий storage, своего рода "коробка". В ООП на мой взгляд, если правильно понял Г.Буча объекты более интеллектуальны и именно поэтому read()/write() , которые Вы вынесли за пределы класса нужно вернуть обратно в пределы класса ;)

начну с конца :


следует поправить : мы вынесли за пределы SFImage методы read(N_Header).. 
разницы нет по сути , находится ли read в классе или вне его.. Разница есть в каком классе он находится )
Я против когда read для N_Header, находится в приватной области SFImage 


не все объекты должны/могут быть интеллектуальны.. более того объект не должен выходить за рамки своих полномочий.. впрочем со своими обязанностями он действительно должен справляться хорошо.. Но вот опять же со "своими" 


Ни в коем случае! ооп не определяется словом "содержит" ..Более того "содержит" уступает свое главенство "использует".. 


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


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

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

Добавлено через 2 минуты и 3 секунды

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

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

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

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

определитесь, что есть для вас image ?
 структура данных, считанная с потока или 
 набор функций применяемых к структуре(файла) определенного формата ?

Добавлено через 1 минуту и 15 секунд
хм.. дежавю  

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

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

Является ли функция объявленная и определенная вне класса частью интерфейса класса?

Есть две ситуации, когда такую функцию пишет :
1) Автор класса
2) Программист-пользователь

В том же пространстве имен, что и класс или нет?

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

EvilsInterrupt, ну собственно так оно и есть. У Саттера была глава, где он заострял внимание на то, что такое интерфейс, попутно рассказав как работает поиск Кенига. И там есть зависимость от того, где Вы объявляете функцию, внутри какого пространства имен.
Вот в Си, например, нет методов(членов функций) для структур. Но мы ведь считаем все функции в хидере структуры её интерфейсом, если они принимают указатель на структуру.

Вы про Argument Depend Lookup ?


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

То как работает ADL это-то понятно, но это же не значит что объект имеет метод если он с ним в одном и том же пространстве имен.

Добавлено через 12 минут и 14 секунд
Guinness, Спасибо за Саттера! Нашел то о чем ты говоришь. Это книга "Стандарты программирования на С++. 101 правило и рекомендации". Почитал сначала Правило №57 на стр.116 по началу был не согласен, но после Правила №44 стр. 93 понял, что выгодней считать свободные функции работающие с объектом, НО в пределах того пространства имен в котором объявлен объект.

Если в одном пространстве имён, то скорее всего он разрабатывался вместе с классом и является частью его интерфейса. Потому что разработчик данного класса разработал эту функцию для того, чтобы Вы её использовали при работе с классом, к которому она относится. Разве это не будет интерфейсом класса?
В объектных языках, таких как Java, такое невозможно , т.к. там нельзя создать функцию отдельно от класса. В Си, как я указал выше, это удинственная возможность ООП. Ну а С++ нечто среднее, и поэтому здесь интерфейс класса - это и то, что им является в Java, и то, что в Си.
Это мое мнение)

Вот! Об этом же и Гради Буч говорит. Java и насколько понимаю и C# тоже думают о функции вне класса что и я, пока думаю, но после Саттера что-то вера в это колеблется 
Думаю вопрос исчерпан, я достаточно гибок, как говорят: "Хоть горшком назови, только в печь не ставь". Мне никак не повредит если я буду считать интерфейсом то как его понимает Саттер, главное чтобы спустя время я осознал что так писать легче, а не труднее ;)

Остается уточнить у mes:


Что есть "оглавление" в Вашем понимании ?


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

немножко наоборот, интерфейс класса является частью , или частным случаем...

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

А если функция мультиметод ?  

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

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

Добавлено через 8 минут и 43 секунды
и да уже несколько раз говорил и еще раз повторю.. Абсолютно не важно как описаны функции, важно какие операции предоставляет обьект.. И я возмутился не из за того, что функции были членами класса,
а из за того что были приватными членами, хотя именно эти операции и характеризуют взаимодействие с объектом(форматом)  

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

header

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

Имхо, не С++ что то среднее, а в ява все пообрезали, чтоб своими несмышленными мыслями за пределы клеток не дай бог не упорхнули