Я пытаюсь решить следующую проблему: имея пользовательский контейнер данных, который управляет универсальным типом, мне нужно разрешить другим компонентам приложения извлекать внутренний указатель контейнера и использовать его, как если бы это была простая область массива T*
(без его обработки как более интеллектуальный держатель массива). Проблема в том, что эта память в особом случае перемещается в другое место и стирается. Таким образом, существует множество компонентов, которые знают о старом указателе данных и будут использовать его для доступа к необходимой им информации.
Установка выглядит псевдокодово примерно так:
container<T>
{
T* ptr;
public:
ContainerInterfaceCode..
}
Гипотеза:
T* ptr
— это псевдоадрес (можно назвать его «виртуальным»?), который отображается в физическом пространстве A.
Когда возникает событие, отображение T* ptr
будет установлено для другого физического пространства, B.
Любой компонент, использующий T* ptr
, не замечает изменения физического местоположения, «думая», что его данные хранятся по этому виртуальному адресу.
Вывод:
Поэтому я хотел бы знать, есть ли механизм, включающий отображение памяти (виртуальной в физическую), который позволит жонглировать отображением T* ptr
, оставляя другие компоненты приложения нетронутыми. Проще говоря, T* ptr
должен указывать на область памяти, которая отображается в определенной части, и, по запросу, тот же самый указатель будет отображаться в другом месте (где базовые данные должны быть скопированы для согласованности). Это должно обеспечивать плавные переходы.
Примечание. Я не могу использовать обертки, интеллектуальные указатели, дескрипторы и т. д. по той простой причине, что это означает изменение огромной кодовой базы только для одной, довольно незначительной модификации.
Поскольку я не нашел достаточно ресурсов, посвященных этому сценарию, может ли кто-нибудь представить краткую вебографию с некоторыми соответствующими материалами для чтения по этому вопросу?
OSMapMemory()
, упомянутая в этой теме osdir. com/ml/linux.drivers.modem.hcf/2002-07/msg00005.html звучит как потенциальное решение для моего гипотетического сценария. Вот почему у меня возникло ощущение, что такая вещь действительна и может быть реализована на C++... но у меня нет другого выхода. - person teodron   schedule 26.07.2013