Озадачился поиском ошибок памяти. Решил, что надо разделить программу логически так, чтобы сначала данные для объекта накапливались ("писались"), а потом использовались ("читались"). Это позволит:

1. Не допустить записи после первой части программы (путем удаления первого интерфейса).
2. После записи рассчитать контрольную сумму и после всех чтений (вторая часть программы) произвести сравнение на поиск модификаций данных объекта другими частями программы.

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

Никак не придумаю схему, чтобы ОДИН объект обладал одним набором переменных (в моем случае- гигантские массивы), но разным набором функций для каждой части программы. Например, создать виртуальный базовый класс "Data" с переменными и от него унаследовать два класса "Read" и "Write" будет ошибкой, поскольку данных во время выполнения программы будет два комплекта.

Как сделать подобное функциональное разделение?

maytonО каких ошибках памяти идёт речь?

1. Ошибка программирования: я вызываю метод объекта для записи данных, где этой записи быть не должно (при больших программах, состоящих из нескольких модулей, подобное трудно отследить).
2. С помощью прямого доступа к памяти какой-то метод записывает данные в private члены моего объекта.

Походу получится создать три объекта "Data", "Write" и"Read", причем два последних в качестве поля будут содержать общий ранее созданный первый объект "Data". Так удастся сохранить уникальность данных и в тоже время в нужный момент создавать/удалять возможности записи/чтения.

Нет подводных камней (типа падения производительности или еще чего)?

kosh the bestпо идее уже в конструкторе вы должны создать "полноценный" объект с таким состоянием, что любые попытки "чтения" из класса, то есть вызовы методов, возвращающих некие данные, будут завершены успешно
далее, все вызовы методов, "помещающие" данные в классы, должны писаться так, чтобы не нарушать согласованное состояние данных в классе
таким образом, достаточно правильно написанных конструкторов и проверок на корректность (обычные if плохие данные в параметрах, то сгенерить исключение или вернуть ошибку) в тех методах, которые меняют состояние объекта


Ну по-моему 100% мимо кассы:

1. Конструкторы объектам "Write" и "Read" не нужны, так как они всего-лишь добавляют методы работы с данными "Data".
2. Проверка на корректность в методах изменения состояния объекта также не нужна, поскольку она будет проведена при расчете контрольной суммы после после всех записей в конце первой части программы. А сравнение контрольных сумм после всех чтений (в конце второй части программы) подтвердит, что все данные сохранились корректно.

kosh the best> Ну по-моему 100% мимо кассы
ну ваше дело
изобретайте велосипед

Не обижайся, бро :)

maytonGermanVпропущено...


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

Значит это не ошибка памяти а ошибка программирования?

Это ошибка доступа к памяти: в данном месте кода не должно быть записи (или чтения). Называйте это как хотите.

Dimitry SibiryakovGermanV1. Ошибка программирования: я вызываю метод объекта для записи данных, где
этой записи быть не должно
Сделай объект с одним объявлением и двумя реализации. Программу собирай с той реализацией,
где любой метод записи выбрасывает ошибку.


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

kosh the bestуж если хотите, то можете сделать к вашему объету Foo два интерфейса, положим FooWrite и FooRead, на этапе заполнения данными работать через FooWrite, в конце записи вызовете метод проверки целостности записанных данных, далее работать только через интерфейс FooRead, который будет предоставлять только методы на чтение, не изменяющие состояния объекта
hint: интерфейсы в с++ реализуются через базовые абстрактные классы
но, повторяюсь, этого совсем не нужно делать, делайте проще

Если я создам два абстрактных базовых класса "Write" и "Read", от которых унаследую два класса с данными "Write_Data" и "Read_Data", то у меня получится ДВА объекта. А надо, чтобы сущность была одна.

Dimitry SibiryakovGermanVА надо, чтобы сущность была одна.
Тогда оберни доступ к объекту в процедуры и объяви эти процедуры в разных заголовках.
Директивами препроцессора сделай так, чтобы эти заголовки не могли быть подключены
одновременно. Попытка обратиться к процедурам из неподключенного заголовка будет вызывать
ошибку компиляции.


А как потом в модуле "отключить" заголовок с файлом, реализующим запись?

Да и коряво это: структура файлов должна отражать модульность программы и коррелировать с пространствами имен (Страуструп, Глава 9 Исходные файлы и программы).

MasterZivGermanV,

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

Можно подробнее?
1. Что означают слова: "там это всё ищется на раз, без всяких переделок программы"?
2. Какие средства есть у кроссплатформенных программ, по сравнению с Win32- программами, позволяющие данные действия?

Dimitry SibiryakovGermanVА как потом в модуле "отключить" заголовок с файлом, реализующим запись?

Зачем его отключать? У тебя по постановке задачи один модуль должен осуществлять только
запись в объект, а другой - только чтение. Именно это и отражает структура файлов.

Как ни крути, из первоначального модуля мне нужно сначала дать команду "записать" (значит файл с процедурами записи данных должен быть доступен), а потом дать команду "прочитать" (значит файл чтения данных должен быть доступен, а записи данных- нет). И как не "углубляй" эти вызовы, все равно запись во время чтения будет доступна.

Dimitry SibiryakovGermanVиз первоначального модуля мне нужно сначала дать команду "записать" (значит
файл с процедурами записи данных должен быть доступен), а потом дать команду "прочитать"
(значит файл чтения данных должен быть доступен, а записи данных- нет). И как не
"углубляй" эти вызовы, все равно запись во время чтения будет доступна.
Это неправильно. Это недостаточная модульность. Раздели свой модуль на два и будет всё по
Страуструпу.


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