Когда RAII имеет преимущество перед GC?

RAII, в отличие от GC, является детерминированным. Вы будете точно знать, когда ресурс будет выпущен, в отличие от «когда-нибудь в будущем он будет выпущен», в зависимости от того, когда сборщик мусора решит, что его нужно запустить снова.

Теперь перейдем к реальной проблеме, которая у вас возникла. Это обсуждение возникло недавно в чате Lounge ‹C ++› о том, что делать, если деструктор объекта RAII может дать сбой.

Был сделан вывод, что лучшим способом было бы предоставить конкретную close(), destroy() или аналогичную функцию-член, которая вызывается деструктором, но также может быть вызвана перед этим, если вы хотите обойти проблему «исключение во время раскрутки стека». Затем он установит флаг, который остановит его вызов в деструкторе. std::(i|o)fstream, например, делает именно это - закрывает файл в его деструкторе, но также предоставляет close() метод.

Это аргумент соломенного человека, потому что вы говорите не о сборке мусора (освобождении памяти), вы говорите об общем управлении ресурсами.

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

Точно такая же проблема возникает при сборке мусора.

Однако стоит отметить, что если в вашем коде или в коде библиотеки, которая поддерживает ваш код, нет ошибки, удаление ресурса никогда не приведет к сбою. delete никогда не дает сбоев, если вы не испортили кучу. Это одна и та же история для каждого ресурса. Неспособность уничтожить ресурс - это сбой, завершающий работу приложения, а не приятное исключение типа «обработай меня».

Исключения в деструкторах бесполезны по одной простой причине: деструкторы разрушают объекты, которые больше не нужны работающему коду. Любая ошибка, возникающая во время их освобождения, может быть безопасно обработана контекстно-независимым способом, например, ведение журнала, отображение пользователю, игнорирование или вызов std::terminate. Окружающему коду все равно, потому что объект ему больше не нужен. Следовательно, вам не нужно распространять исключение по стеку и прерывать текущее вычисление.

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

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

Во-первых: вы не можете сделать ничего полезного с ошибкой, если ваш файловый объект хранится в GCed и не может закрыть FILE *. Таким образом, эти два понятия эквивалентны.

Во-вторых, «правильный» шаблон выглядит следующим образом:

class X{
    FILE *fp;
  public:
    X(){
      fp=fopen("whatever","r");
      if(fp==NULL) throw some_exception();
    }
    ~X(){
        try {
            close();
        } catch (const FileError &) {
            // perhaps log, or do nothing
        }
    }
    void close() {
        if (fp != 0) {
            if(fclose(fp)!=0){
               // may need to handle EAGAIN and EINTR, otherwise
               throw FileError();
            }
            fp = 0;
        }
    }
};

Использование:

X x;
// do stuff involving x that might throw
x.close(); // also might throw, but if not then the file is successfully closed

Если выдает команду «делать что-нибудь», то практически не имеет значения, успешно ли закрыт дескриптор файла или нет. Операция завершилась неудачно, поэтому в любом случае файл обычно бесполезен. Кто-то выше в цепочке вызовов может знать, что с этим делать, в зависимости от того, как файл используется - возможно, его следует удалить, возможно, оставить в покое в частично записанном состоянии. Что бы они ни делали, они должны знать, что помимо ошибки, описанной в исключении, которое они видят, возможно, что файловый буфер не был очищен.

RAII используется здесь для управления ресурсами. Файл закрывается несмотря ни на что. Но RAII не используется для определения успешности операции - если вы хотите это сделать, вы вызываете x.close(). Сборщик мусора также не используется для определения успешности операции, поэтому по этому счету они равны.

Вы получаете аналогичную ситуацию всякий раз, когда вы используете RAII в контексте, где вы определяете какую-то транзакцию - RAII может откатить открытую транзакцию при исключении, но если все идет хорошо, программист должен явно зафиксировать транзакцию.

Ответ на ваш вопрос - преимущество RAII и причина, по которой вы в конечном итоге сбрасываете или закрываете файловые объекты в предложениях finally в Java, заключается в том, что иногда вы хотите, чтобы ресурс был очищен (насколько это возможно) немедленно после выйти из области видимости, чтобы следующий фрагмент кода знал, что это уже произошло. GC Mark-sweep этого не гарантирует.

Хочу высказать еще несколько мыслей, касающихся "RAII" и "GC". Аспекты использования какой-либо функции закрытия, уничтожения, завершения и любой другой уже объяснены, как и аспект детерминированного высвобождения ресурсов. Есть, по крайней мере, еще два важных средства, которые активируются с помощью деструкторов и, таким образом, отслеживают ресурсы контролируемым программистом способом:

1. В мире RAII может быть устаревший указатель, то есть указатель, указывающий на уже уничтоженный объект. То, что звучит как Плохая вещь, на самом деле позволяет расположить связанные объекты в памяти в непосредственной близости. Даже если они не помещаются в одну и ту же строку кэша, они, по крайней мере, помещаются на страницу памяти. В некоторой степени более близкое расположение может быть достигнуто и с помощью компактного сборщика мусора, но в мире C ++ это происходит естественным образом и определяется уже во время компиляции.
2. Хотя обычно память просто выделяется и высвобождается с использованием операторов new и delete, можно выделить память, например. из пула и организовать более компактное использование памяти объектами, которые, как известно, связаны. Это также можно использовать для размещения объектов в выделенных областях памяти, например разделяемая память или другие диапазоны адресов для специального оборудования.

Хотя эти способы использования не обязательно напрямую используют методы RAII, они становятся возможными благодаря более явному контролю над памятью. Тем не менее, есть также использование памяти, где сборка мусора имеет явное преимущество, например при передаче объектов между несколькими потоками. В идеальном мире были бы доступны оба метода, и C ++ предпринимает некоторые шаги для поддержки сборки мусора (иногда называемой «сборкой мусора», чтобы подчеркнуть, что он пытается дать бесконечное представление о системе в памяти, т. Е. Собранные объекты не уничтожены, но их расположение в памяти используется повторно). Обсуждения до сих пор не идут по пути, выбранному C ++ / CLI, по использованию двух разных типов ссылок и указателей.

В. Когда RAII имеет преимущество перед GC?

A. Во всех случаях, когда ошибки уничтожения не интересны (т.е. у вас все равно нет эффективного способа их исправить).

Обратите внимание, что даже со сборкой мусора вам придется вручную запустить действие dispose (закрыть, освободить что угодно), поэтому вы можете просто улучшить шаблон RIIA таким же образом:

class X{
    FILE *fp;
    X(){
      fp=fopen("whatever","r");
      if(fp==NULL) throw some_exception();
    }

    void close()
    {
        if (!fp)
            return;
        if(fclose(fp)!=0){
            throw some_exception();
        }
        fp = 0;
    }

    ~X(){
        if (fp)
        {
            if(fclose(fp)!=0){
                //An error. You're screwed, just throw or std::terminate
            }
        }
    }
}

Предполагается, что деструкторы всегда приносят успех. Почему бы просто не убедиться, что fclose не выйдет из строя?

Вы всегда можете сделать fflush или что-то еще вручную и проверить ошибку, чтобы убедиться, что fclose удастся позже.