Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

“Правило ноля”

Anna | 24.06.2014 | нет комментариев

Применительно к с 03 существует “правило трех”, с возникновением с 11 оно трансформировалось в “правило 5ти”. И правда эти правила по сути являются не больше чем неформальными рекомендациями к проектированию собственных типов данных, но тем не менее Зачастую бывают пригодны. “Правило ноля” продолжает ряд этих рекомендаций. В этом посте я напомню о чем, собственно, первые 2 правила, а также испробую объяснить идею, стоящую за “правилом ноля”.

Мотивация

Все упомянутые выше правила написаны в основном (но не неизменно) для обстановок, когда объект нашего класса обладает каким-либо источником (хендлером, указателем на источник) и необходимо каким-то образом решить что будет протекать с этим хендлером и с самим источником при копировании/перемещении нашего объекта.
По умолчанию, если мы не объявляем ни одну из “специальных” функций (конструктор копирования, оператор присваивания, деструктор и т.п.), компилятор сгенерирует их код механически. При этом они будут вести себя в всеобщем-то ожидаемо. Скажем, конструктор копирования будет пытаться скопировать не POD члены класса вызывая их соответсвующие конструкторы копирования и побитово копировать члены POD типов. Такое поведение абсолютно терпимо для примитивных классов, содержащих всех своих членов в себе самих.

Стратегии владения

В случае же крупных трудных классов, либо классов, в качестве члена которого выступает хендлер внешнего источника поведение, реализуемое компилятором по умолчанию, нас теснее может не устроить. К счастью мы можем независимо определить особые функции, реализовав надобную в данной обстановки тактику владения источником. Условно дозволено выделить несколько основных таких стратегий:
1. закроет копирования и перемещения;
2. копирование разделяемого источника совместно с хендлером (deep copy);
3. закроет копирования, но разрешение перемещения;
4. совместное владение (регулируется, скажем, подсчетом ссылок).

“Правило трех” и “правило пяти”

Так вот “правило трех” и “правило 5ти” говорят о том, что в всеобщем случае, если появилась надобность независимого определения одной из операций копирования, перемещения либо уничтожения нашего объекта в соответстие с одной из выбранных стратегий, то скорее каждого для правильной работы необходимо будет определить все остальные функции тоже.
Отчего это так, легко увидеть на дальнейшем примере. Возможен членом нашего класса является указатель на объект в куче.

class my_handler {
public:
	my_handler(int c) : counter_(new int(c)) {}
private:
	int* counter_;
};

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

my_handler::~my_handler() {delete counter_;}

Но что сейчас произойдет при попытке скопировать объект нашего класса? Вызовется определенный по умолчанию конструктор копирования, тот, что Добросовестно скопирует указатель и в результате у нас будет 2 объекта, обладающих указателем на один и тот же источник. Это нехорошо по внятным причинам. Значит нам необходимо определить личные конструктор копирования, оператор присваивания и т.д.
Ну так в чем же дело? Давайте неизменно будем определять все 5 “специальных” функций и все будет ок. Дозволено, но, Добросовестно говоря, достаточно изнурительно и чревато ошибками. Тогда давайте будем определять только те, что подлинно нужны в нынешней обстановки, а остальные пускай генерируются компилятором? Тоже вариант, но во-первых “ситуация” в которой применяется наш код абсолютно может измениться без нашего ведома, и наш класс окажется неспособным трудиться в новых условиях, а во-вторых есть специальные (и, как мне кажется, достаточно запутанные) правила подавляющие генерацию компилятором спец. функций. Скажем, “функции перемещения не будут неявно сгенерированы компилятором, если есть правда бы одна очевидно объявленная функция из 5ки” либо “функции копирования не будут сгененированы, если есть правда бы одна очевидно объявленная функция перемещения”.

“Правило ноля”

Один из допустимых выходов был озвучен Мартино Фернандесом в виде “правила ноля” и коротко может быть cформулирован дальнейшим образом: “не определяйте независимо ни одну из функций 5ки, взамен этого возложите опеку о вла

 

Источник: programmingmaster.ru

 

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB