Ваши вопросы немного абстрактны, и я не уверен, что могу ответить вообще хорошо, но вот мои мысли по каждому из них.Лично я не согласен, что некоторые из этих вещей - лучший дизайн для работы, но это не ваш вопрос, а вопрос мнения.
Виртуальные прокси Я непонять, что вы пытаетесь сказать здесь вообще.Суть паттерна здесь в том, что у вас может быть объект A, который, как вы знаете, будет занимать 100 МБ, и вы не знаете наверняка, что вам когда-нибудь понадобится использовать этот объект.
Чтобы избежать выделения памяти длядо тех пор пока этот объект не понадобится, вы создаете фиктивный объект B, который реализует тот же интерфейс, что и A, и если любой из его методов вызывается B, создает экземпляр A, таким образом избегая выделения памяти до тех пор, пока он не понадобится.
Защита прокси Здесь я думаю, что вы неправильно поняли использование шаблона.Идея состоит в том, чтобы иметь возможность динамически контролировать доступ к объекту.Например, вы можете захотеть, чтобы класс A имел доступ к методам класса B , если условие C не является истинным.Как я уверен, вы можете видеть, что этого нельзя достичь с помощью спецификаторов доступа.
Умные ссылки Здесь я думаю, что вы неправильно понимаете необходимость умных указателей.Поскольку это довольно сложная тема, я просто предоставлю ссылку на вопрос о них: RAII и умные указатели на C ++
Если вы никогда не программировали на языке, подобном C, где вы управляетеВаша память сама по себе, это может объяснить путаницу.
Я надеюсь, что это поможет ответить на некоторые ваши вопросы.
РЕДАКТИРОВАТЬ:
Я не заметил, что это было помеченоС ++, так что я предполагаю, что вы действительно понимаете необходимость очистки динамической памяти.Один статический счетчик ссылок будет работать, только если вы намереваетесь когда-либо иметь один экземпляр вашего объекта.Если вы создаете 2000 экземпляров объекта, а затем удаляете 1999 из них, ни у одного из них не освободится память до последнего оставленного объема, что явно нежелательно (предполагается, что вы отслеживали расположение всей выделенной памяти).чтобы иметь возможность освободить его!).
РЕДАКТИРОВАТЬ 2:
Скажем, у вас есть класс следующим образом:
class A {
public:
static int refcount;
int* allocated_memory;
A() {
++refcount;
allocated_memory = new int[100000000];
}
~A() {
if(! --refcount) {
delete [] allocated_memory;
}
}
}
И некоторый код, который использует его:
int main() {
A problem_child; // After this line refcount == 1
while(true) {
A in_scope; // Here refcount == 2
} // We leave scope and refcount == 1.
// NOTE: in_scope.allocated_memory is not deleted
// and we now have no pointer to it. Leak!
return;
}
Как видно из кода, refcount считает все ссылки на все объекты, что приводит к утечке памяти.Я могу объяснить подробнее, если вам нужно, но это действительно отдельный вопрос.