предотвратить создание объекта со статическим временем жизни - PullRequest
Новая
       24

предотвратить создание объекта со статическим временем жизни

2 голосов
/ 05 июля 2011

Можем ли мы предотвратить создание объектов со статическим временем жизни, и в то же время разрешить создание объектов с автоматическим временем жизни?

Если мы хотим запретить пользователям создавать экземпляры класса с автоматической продолжительностью, мы можем сделать деструктор закрытым. и если мы хотим запретить пользователям создавать экземпляры с динамическим размещением, мы можем сделать operator new приватным.

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

Ответы [ 2 ]

3 голосов
/ 06 июля 2011

Существует нет языка средство, которое помогает во время компиляции.Но во время выполнения вы можете использовать приведенную ниже технику, чтобы ограничить ее .Предположим, вы не хотите MyObject в static области хранения, затем добавьте код в деструктор как: 

bool ALLOW_OBJECTS = false;  // global variable
struct MyObject  // class body
{
 ~MyObject ()
  {
    if(ALLOW_OBJECTS == false)
      <print error message>
    // ...
  }
};

Теперь, в вашем методе main() вы можете иметь ALLOW_OBJECTS как, 

int main ()
{
  ALLOW_OBJECTS = true;  // objects can be created now
// ... other code
  ALLOW_OBJECTS  = false;  // reset to 'false' before main() ends
}

Теперь факт, что переменные, объявленные в static хранилище, исчезают из своего времени жизни (вызов деструктора) после завершения main().Таким образом, если переменная была объявлена ​​в static хранилище, ее деструктор выведет сообщение об ошибке (в файле или в stdout).

При этой проверке ваш 1 запуск теста выполнения может завершиться неудачно, но вы можете вручную исправитькод после того, как вы найдете количество сообщений об ошибках.Таким образом, в вашем рабочем коде вы можете удалить все эти операторы отладки, и у вас будет свой код без какого-либо static объекта хранения !!!(неприменимо для POD и указателей).

0 голосов
/ 10 сентября 2018

В wikibooks есть квитанция Требование или запрещение объектов на основе кучи .

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

class HeapOnly {
  public:
    HeapOnly() {} 
    void destroy() const { delete this; }
  protected:
    ~HeapOnly() {}
};
HeapOnly h1;     // Destructor is protected so h1 can't be created globally
HeapOnly func()  // Compiler error because destructor of temporary is protected
{
  HeapOnly *hoptr = new HeapOnly; // This is ok. No destructor is invoked automatically for heap-based objects
  return *hoptr;
}
int main(void) {
  HeapOnly h2; // Destructor is protected so h2 can't be created on stack
}
...