Конструкторы и Деструкторы

  • Предостережение
  • Статическая Память
  • Свободная Память
  • Объекты Класса и Члены
  • Вектора Объектов Класса
  • Небольшие Объекты
  • Предостережение
  • Объекты Переменного Размера


Если у класса есть конструктор, то он вызывается всегда, когда создается объект класса. Если у класса есть деструктор, то он вызывается всегда, когда объект класса уничтожается. Объекты могут создаваться как:

  1. Автоматический объект: создается каждый раз, когда его описание встречается при выполнении программы, и уничтожается каждый раз при выходе из блока, в котором оно появилось;
     
  2. Статический объект: создается один раз, при запуске программы, и уничтожается один раз, при ее завершении;
     
  3. Объект в свободной памяти: создается с помощью операции new и уничтожается с помощью операции delete;
     
  4. Объект член: как объект другого класса или как элемент вектора.


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

Предостережение

Если x и y - объекты класса cl, то x=y в стандартном случае означает побитовое копирование y в x . Такая интерпретация присваивания может привести к изумляющему (и обычно нежелательному) результату, если оно применяется к объектам класса, для которого определены конструктор и деструктор.

Например:
 

 


class char_stack {
int size;
char* top;
char* s;


public:
char_stack(int sz) { top=s=new char[size=sz]; }
~char_stack() { delete s; } // деструктор
void push(char c) { *top++ = c; }
char pop() { return *--top; }
};


void h()
{
char_stack s1(100);
char_stack s2 = s1; // неприятность
char_stack s3(99);
s3 = s2; // неприятность
}
 

 


Здесь конструктор char_stack::char_stack() вызывается дважды: для s1 и для s3. Для s2 он не вызывается, поскольку эта переменная инициализируется присваиванием. Однако деструктор char_stack::~char_stack() вызывается трижды: для s1, s2 и s3! Кроме того, по умолчанию действует интерпретация присваивания как побитовое копирование, поэтому в конце h() каждый из s1, s2 и s3 будет содержать указатель на вектор символов, размещенный в свободной памяти при создании s1. Не останется никакого указателя на вектор символов, выделенный при создании s3.

Статическая Память

Рассмотрим следующее:
 

 


table tbl1(100);


void f() {
static table tbl2(200);
}


main()
{
f();
}
 

 


Здесь конструктор table::table() будет вызываться дважды: один раз для tbl1 и один раз для tbl2. Деструктор table::~table() также будет вызван дважды: для уничтожения tbl1 и tbl2 после выхода из main(). Конструкторы для глобальных статических объектов в файле выполняются в том порядке, в котором встречаются описания; деструкторы вызываются в обратном порядке. Не определено, вызывается ли конструктор для локального статического объекта, если функция, в которой этот объект описан, не вызывается. Если конструктор для локального статического объекта вызывается, то он вызывается после того, как вызваны конструкторы для лексически предшествующих ему глобальных статических объектов.

Параметры конструкторов для статических объектов должны быть константными выражениями:
 

 


void g(int a)
{
static table t(a); // ошибка
}
 

 


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

Вызов конструкторов и деструкторов для статических объектов играет в C++ чрезвычайно важную роль. Это способ обеспечить надлежащую инициализацию и очистку структур данных в библиотеках. Рассмотрим . Откуда берутся cin, cout и cerr? Где они получают инициализацию? И, что самое главное, поскольку потоки вывода имеют внутренние буферы символов, как же эти буферы становятся заполненными? Простой и очевидный ответ, что эта работа осуществляется соответствующими конструкторами и деструкторами до и после выполнения main(). Для инициализации и очистки библиотечных средств есть возможности, альтернативные использованию конструкторов и деструкторов. Все они или очень специальные, или очень уродливые.

Если программа завершается с помощью функции exit(), то деструкторы для статических объектов будут вызваны, а если она завершается с помощью abort(), то не будут. Заметьте, что это подразумевает, что exit() не завершает программу мгновенно. Вызов exit() в деструкторе может привести к бесконечной рекурсии.

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

Свободная Память

Рассмотрим:
 

 


main() {
table* p = new table(100);
table* q = new table(200);
delete p;
delete p; // возможно, ошибка
}
 

 


Конструктор table::table() будет вызван дважды, как и деструктор table::~table(). То, что C++ не дает никаких гарантий, что для объекта, созданного с помощью new, когда-либо будет вызван деструктор, ничего не значит. В предыдущей программе q не уничтожается, а p уничтожается дважды! Программист может счесть это ошибкой, а может и не счесть, в зависимости от типа p и q. Обычно то, что объект не уничтожается, является не ошибкой, а просто лишней тратой памяти. Уничтожение p дважды будет , как правило, серьезной ошибкой. Обычно результатом применения delete дважды к одному указателю приводит к бесконечному циклу в подпрограмме управления свободной памятью, но определение языка не задает поведение в таком случае, и оно зависит от реализации.

Пользователь может определить новую реализацию операций new и delete. Можно также определить способ взаимодействия конструктора или деструктора с операциями new и delete

Объекты Класса и Члены

Рассмотрим
 

 


class classdef {
table members;
int no_of_members;
// ...
classdef(int size);
~classdef();
};
 

 


Очевидное намерение состоит в том, что classdef должен содержать таблицу длиной size из членов member, а сложность - в том, как сделать так, чтобы конструктор table::table() вызывался с параметром size. Это делается примерно так:
 

 


classdef::classdef(int size)
: members(size)
{
no_of_members = size;
// ...
}
 

 


Параметры для конструктора члена member (здесь это table::table()) помещаются в определение (не в описание) конструктора класса, вмещающего его (здесь это classdef::classdef()). После этого конструктор члена вызывается перед телом конструктора, задающего его список параметров.

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

Например:
 

 


class classdef {
table members;
table friends;
int no_of_members;
// ...
classdef(int size);
~classdef();
};
 

 


Список параметров для членов разделяется запятыми (а не двоеточиями), и список инициализаторов для членов может представляться в произвольном порядке:
 

 


classdef::classdef(int size)
: friends(size), members(size)
{
no_of_members = size;
// ...
}
 

 


Порядок, в котором вызываются конструкторы, не определен, поэтому не рекомендуется делать списки параметров с побочными эффектами:
 

 


classdef::classdef(int size)
: friends(size=size/2), members(size); // дурной стиль
{
no_of_members = size;
// ...
}
 

 


Если конструктору для члена не нужно ни одного параметра, то никакого списка параметров задавать не надо. Например, поскольку table::table был определен с параметром по умолчанию 15, следующая запись является правильной:
 

 


classdef::classdef(int size)
: members(size)
{
no_of_members = size;
// ...
}
 

 


и размер size таблицы friend"ов будет равен 15.

Когда объект класса, содержащий объект класса, (например, classdef) уничтожается, первым выполняется тело собственного деструктора объекта, а затем выполняются деструкторы членов.

Рассмотрим традиционную альтернативу тому, чтобы иметь объекты класса как члены, - иметь члены указатели и инициализировать их в конструкторе:
 

 


class classdef {
table* members;
table* friends;
int no_of_members;
// ...
classdef(int size);
~classdef();
};


classdef::classdef(int size)
{
members = new table(size);
friends = new table; // размер таблицы по умолчанию
no_of_members = size;
// ...
}
 

 


Так как таблицы создавались с помощью new, они должны уничтожаться с помощью delete:
 

 


classdef::~classdef()
{
// ...
delete members;
delete friends;
}

Раздельно создаваемые объекты вроде этих могут оказаться полезными, но учтите, что members и friends указывают на отдельные объекты, что требует для каждого из них действие по выделению памяти и ее освобождению. Кроме того, указатель плюс объект в свободной памяти занимают больше места, чем объект член.

Вектора Объектов Класса

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

Например:

table tblvec[10];

будет ошибкой, так как для table::table() требуется целый параметр. Нет способа задать параметры конструктора в описании вектора. Чтобы можно было описывать вектор таблиц table, можно модифицировать описание table  например так:
 

 


class table {
// ...
void init(int sz); // как старый конструктор
public:
table(int sz) // как раньше, но без по умолчанию
{ init(sz); }
table() // по умолчанию
{ init(15); }
}
 

 


Когда вектор уничтожается, деструктор должен вызываться для каждого элемента этого вектора. Для векторов, которые не были размещены с помощью new, это делается неявно. Однако для векторов в свободной памяти это не может быть сделано неявно, поскольку компилятор не может отличить указатель на один объект от указателя на первый элемент вектора объектов.

Например:
 

 


void f()
{
table* t1 = new table;
table* t2 = new table[10];
delete t1; // одна таблица
delete t2; // неприятность: 10 таблиц
}
 

 


В этом случае длину вектора должен задавать программист:
 

 


void g(int sz)
{
table* t1 = new table;
table* t2 = new table[sz];
delete t1;
delete[] t2;
}
 

 


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

Небольшие Объекты

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

Рассмотрим класс name, который использовался в примерах table. Его можно было бы определить так:
 

 


struct name {
char* string;
name* next;
double value;


name(char*, double, name*);
~name();
};

Программист может воспользоваться тем, что размещение и освобождение объектов заранее известного размера может обрабатываться гораздо эффективнее (и по памяти, и по времени), чем с помощью общей реализации new и delete. Общая идея состоит в том, чтобы предварительно разместить "куски" из объектов name, а затем сцеплять их, чтобы свести выделение и освобождение к простым операциям над связанным списком. Переменная nfree является вершиной списка неиспользованных name:

const NALL = 128;
name* nfree;

Распределитель, используемый операцией new, хранит размер объекта вместе с объектом, чтобы обеспечить правильную работу операции delete. С помощью распределителя, специализированного для типа, можно избежать этих накладных расходов. Например, на моей машине следующий распределитель использует для хранения name 16 байт, тогда как для стандартного распределителя свободной памяти нужно 20 байт. Вот как это можно сделать:
 

 


name::name(char* s, double v, name* n)
{
register name* p = nfree; // сначала выделить


if (p)
nfree = p->next;
else { // выделить и сцепить
name* q = (name*)new char[ NALL*sizeof(name) ];
for (p=nfree=&q[NALL-1]; qnext = p-1;
(p+1)->next = 0;
}

this = p; // затем инициализировать
string = s;
value = v;
next = n;
}

Присвоение указателю this информирует компилятор о том, что программист взял себе управление, и что не надо использовать стандартный механизм распределения памяти. Конструктор name::name() обрабатывает только тот случай, когда name размещается посредством new, но для большей части типов это всегда так.
Заметьте, что просто как

name* q = new name[NALL];

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

Освобождение памяти обычно тривиально:

name::~name()
{
next = nfree;
nfree = this;
this = 0;
}

Присваивание указателю this 0 в деструкторе обеспечивает, что стандартный распределитель памяти не используется.

Предостережение

Когда в конструкторе производится присваивание указателю this, значение this до этого присваивания не определено. Таким образом, ссылка на член до этого присваивания не определена и скорее всего приведет к катастрофе. Имеющийся компилятор не пытается убедиться в том, что присваивание указателю this происходит на всех траекториях выполнения:
 

 


mytype::mytype(int i)
{
if (i) this = mytype_alloc();
// присваивание членам
};
 

 


откомпилируется, и при i==0 никакой объект размещен не будет.

Конструктор может определить, был ли он вызван операцией new, или нет. Если он вызван new, то указатель this на входе имеет нулевое значение, в противном случае this указывает на пространство, уже выделенное для объекта (например, на стек). Поэтому можно просто написать конструктор, который выделяет память, если (и только если) он был вызван через new.

Например:
 

 


mytype::mytype(int i)
{
if (this == 0) this = mytype_alloc();
// присваивание членам
};
 

 


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

Если тот, кто реализует класс, является одновременно и его единственным пользователем, то имеет смысл упростить, исходя из предположений о его использовании. Когда класс разрабатывается для более широкого использования, таких допущений, как правило, лучше избегать.

Объекты Переменного Размера

Когда пользователь берет управление распределением и освобождением памяти, он может конструировать объекты, размер которых во время компиляции недетерминирован. В предыдущих примерах вмещающие (или контейнерные - перев.) классы vector, stack, intset и table реализовывались как структуры доступа фиксированного размера, содержание указатели на реальную память. Это подразумевает, что для создания таких объектов в свободной памяти необходимо две операции по выделению памяти, и что любое обращение к хранимой информации будет содержать дополнительную косвенную адресацию.

Например:

class char_stack {
int size;
char* top;
char* s;
public:
char_stack(int sz) { top=s=new char[size=sz]; }
~char_stack() { delete s; } // деструктор
void push(char c) { *top++ = c; }
char pop() { return *--top; }
};

Если каждый объект класса размещается в свободной памяти, это делать не нужно. Вот другой вариант:

class char_stack {
int size;
char* top;
char s[1];
public:
char_stack(int sz);
void push(char c) { *top++ = c; }
char pop() { return *--top; }
};


char_stack::char_stack(int sz)
{
if (this) error("стек не в свободной памяти");
if (sz < 1) error("размер стека < 1");
this = (char_stack*) new char[sizeof(char_stack)+sz-1];
size = sz;
top = s;
}

Заметьте, что деструктор больше не нужен, поскольку память, которую использует char_stack, может освободить delete без всякого содействия со стороны программиста.



Опубликовал admin
23 Мар, Вторник 2004г.



Программирование для чайников.