Простые примеры мертвой блокировки

Простым (и возможно злоупотребил) пример RAII является класс Файла. Без RAII мог бы выглядеть примерно так код:

File file("/path/to/file");
// Do stuff with file
file.close();

, Другими словами, мы должны удостовериться, что закрываем файл, как только мы закончили с ним. Это имеет два недостатка - во-первых, везде, где мы используем Файл, мы будем иметь на названный File::close () - если мы забудем делать это, мы держим на файл дольше, чем мы должны. Вторая проблема что, если исключение выдается, прежде чем мы закроем файл?

Java решает вторую проблему с помощью наконец пункт:

try {
    File file = new File("/path/to/file");
    // Do stuff with file
} finally {
    file.close();
}

или начиная с Java 7, оператора попытки с ресурсом:

try (File file = new File("/path/to/file")) {
   // Do stuff with file
}

C++ решает обе проблемы с помощью RAII - то есть, закрывая файл в деструкторе Файла. Пока объект Файла уничтожается в нужное время (которым это должно быть так или иначе), закрытие файла заботится о для нас. Так, наш код теперь смотрит что-то как:

File file("/path/to/file");
// Do stuff with file
// No need to close it - destructor will do that for us

Это не может быть сделано в Java, так как нет никакой гарантии, когда объект будет уничтожен, таким образом, мы не сможем гарантировать, когда ресурс, такой как файл будет освобожден.

На интеллектуальные указатели - много времени, мы просто создаем объекты на стеке. Например (и кража примера из другого ответа):

void foo() {
    std::string str;
    // Do cool things to or using str
}

Это хорошо работает - но что, если мы хотим возвратить str? Мы могли записать это:

std::string foo() {
    std::string str;
    // Do cool things to or using str
    return str;
}

Так, что случилось с этим? Ну, тип возврата является станд.:: строка - таким образом, это означает, что мы возвращаемся значением. Это означает, что мы копируем str и на самом деле возвращаем копию. Это может быть дорого, и мы могли бы хотеть избежать стоимости копирования его. Поэтому мы могли бы придумать идею возвратиться ссылкой или указателем.

std::string* foo() {
    std::string str;
    // Do cool things to or using str
    return &str;
}

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

Так, каково решение? Мы могли создать str на "куче", использующей новый - тот путь, когда нечто () будет завершено, str не будет уничтожен.

std::string* foo() {
    std::string* str = new std::string();
    // Do cool things to or using str
    return str;
}

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

Это - то, где интеллектуальные указатели входят. Следующий пример использует shared_ptr - я предлагаю, чтобы Вы посмотрели на различные типы интеллектуальных указателей для изучения то, что Вы на самом деле хотите использовать.

shared_ptr<std::string> foo() {
    shared_ptr<std::string> str = new std::string();
    // Do cool things to or using str
    return str;
}

Теперь, shared_ptr будет считать количество ссылок на str. Например

shared_ptr<std::string> str = foo();
shared_ptr<std::string> str2 = str;

Теперь существует две ссылки на ту же строку. Однажды нет никаких остающихся ссылок на str, он будет удален. По сути, Вы больше не должны волноваться об удалении его сами.

Быстрое редактирование: как некоторые комментарии указали, этот пример не идеально подходит для (по крайней мере!) две причины. Во-первых, из-за реализации строк, копируя строку имеет тенденцию быть недорогим. Во-вторых, из-за то, что известно как именованная оптимизация возвращаемого значения, возвращающаяся значением, не может быть дорогим, так как компилятор может сделать некоторый ум для ускорения вещей.

Так, давайте попробуем различный пример с помощью нашего класса Файла.

Скажем, мы хотим использовать файл в качестве журнала. Это означает, что мы хотим открыться, наш файл в добавляют только режим:

File file("/path/to/file", File::append);
// The exact semantics of this aren't really important,
// just that we've got a file to be used as a log

Теперь, давайте установим наш файл как журнал для нескольких других объектов:

void setLog(const Foo & foo, const Bar & bar) {
    File file("/path/to/file", File::append);
    foo.setLogFile(file);
    bar.setLogFile(file);
}

, К сожалению, этот пример заканчивается ужасно - файл будет закрыт, как только этот метод заканчивается, означая, что нечто и панель теперь имеют недопустимый файл журнала. Мы могли создать файл на "куче" и передать указатель на файл и к нечто и к панели:

void setLog(const Foo & foo, const Bar & bar) {
    File* file = new File("/path/to/file", File::append);
    foo.setLogFile(file);
    bar.setLogFile(file);
}

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

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

void setLog(const Foo & foo, const Bar & bar) {
    shared_ptr<File> file = new File("/path/to/file", File::append);
    foo.setLogFile(file);
    bar.setLogFile(file);
}

Теперь, никто не должен волноваться об удалении файла - как только и нечто и панель закончили и больше не имеют ссылок на файл (вероятно, из-за нечто и уничтожаемой панели), файл будет автоматически удален.