Кто удаляет память, выделенную во время новой операции, которая имеет исключение в конструкторе?

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

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

Затем, если объект был выделен с помощью new, соответствующая функция освобождения (operator delete) вызывается с теми же дополнительными аргументами, которые были переданы operator new. Например, new (std::nothrow) SomethingThatThrows() выделит память с помощью operator new (size_of_ob, nothrow), попытается построить SomethingThatThrows, уничтожит все элементы, которые были успешно созданы, а затем вызовет operator delete (ptr_to_obj, nothrow) при распространении исключения - утечки памяти не будет.

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

Если Конструктор выбрасывает выделенную для объекта память, она автоматически возвращается в систему.

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

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

Члены, которые были полностью инициализированы, будут иметь свои деструкторы, но если у вас есть какие-либо члены указателя RAW, которыми вы владеете (т.е. удалите в деструкторе), вам придется выполнить некоторую очистку, прежде чем выполнять бросок (еще одна причина не использовать принадлежащие Указатели RAW в вашем классе).

#include <iostream>

class Base
{
    public:
        Base()  {std::cout << "Create  Base\n";}
        ~Base() {std::cout << "Destroy Base\n";}
};

class Deriv: public Base
{
    public:
        Deriv(int x)    {std::cout << "Create  Deriv\n";if (x > 0) throw int(x);}
        ~Deriv()        {std::cout << "Destroy Deriv\n";}
};

int main()
{
    try
    {
        {
            Deriv       d0(0);  // All constructors/Destructors called.
        }
        {
            Deriv       d1(1);  // Base constructor and destructor called.
                                // Derived constructor called (not destructor)
        }
    }
    catch(...)
    {
        throw;
        // Also note here.
        // If an exception escapes main it is implementation defined
        // whether the stack is unwound. By catching in main() you force
        // the stack to unwind to this point. If you can't handle re-throw
        // so the system exception handling can provide the appropriate
        // error handling (such as user messages).
    }
}

Из стандарта C ++ 2003 5.3.4 / 17 - Новое:

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

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

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

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

Цитируется из FAQ по C ++ (parashift.com):

[17.4] Как мне обрабатывать ресурсы, если мои конструкторы могут вызывать исключения?

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

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

Например, вместо того, чтобы выделять память в необработанном Fred* элементе данных, поместите выделенную память в объект-член «умного указателя», и деструктор этого умного указателя будет delete объект Fred, когда умный указатель умрет. Шаблон std::auto_ptr является примером такого, как «умный указатель». Вы также можете написать собственный умный указатель для подсчета ссылок . Вы также можете использовать интеллектуальные указатели, чтобы «указывать» на диск. записи или объекты на других машинах.

Кстати, если вы думаете, что ваш Fred класс будет выделен в интеллектуальный указатель, будьте вежливы со своими пользователями и создайте typedef в своем Fred классе:

 #include <memory>

 class Fred {
 public:
   typedef std::auto_ptr<Fred> Ptr;
   ...
 };

Этот typedef упрощает синтаксис всего кода, который использует ваши объекты: ваши пользователи могут говорить Fred::Ptr вместо std::auto_ptr<Fred>:

 #include "Fred.h"

 void f(std::auto_ptr<Fred> p);  // explicit but verbose
 void f(Fred::Ptr           p);  // simpler

 void g()
 {
   std::auto_ptr<Fred> p1( new Fred() );  // explicit but verbose
   Fred::Ptr           p2( new Fred() );  // simpler
   ...
 }

Описанная проблема стара, как дорога в Рим, если пользоваться голландской поговоркой. Я решил проблему, и выделение памяти для объекта, который может вызвать исключение, выглядит следующим образом:

try
{
    std::string *l_string =
        (_heap_cleanup_tpl<std::string>(&l_string),
        new std::string(0xf0000000, ' '));
    delete l_string;
}
catch(std::exception &)
{
}

Перед фактическим вызовом new-оператора создается безымянный (временный) объект, который получает адрес выделенной памяти через определяемый пользователем новый оператор (см. Остальную часть этого ответа). В случае нормального выполнения программы временный объект передает результат нового оператора (вновь созданный и полностью сконструированный объект, в нашем случае очень-очень длинная строка) переменной l_string. В случае исключения значение не передается, но деструктор временного объекта удаляет память (конечно, без вызова деструктора основного объекта).

Это немного нечеткий способ решения проблемы, но он работает. Проблемы могут возникнуть, потому что это решение требует, чтобы определяемый пользователем новый оператор и определяемый пользователем оператор удаления работали вместе с ним. Определяемые пользователем операторы new / delete должны будут вызывать реализацию операторов new / delete в стандартной библиотеке C ++, но я оставил это для краткости и вместо этого полагался на malloc() и free().

Это не окончательный ответ, но я думаю, что над этим стоит подумать.

PS: В приведенном ниже коде была «недокументированная» функция, поэтому я сделал улучшение.

Код временного объекта следующий:

class _heap_cleanup_helper
{
    public:
    _heap_cleanup_helper(void **p_heap_block) :
        m_heap_block(p_heap_block),
        m_previous(m_last),
        m_guard_block(NULL)
    {
        *m_heap_block = NULL;
        m_last = this;
    }
    ~_heap_cleanup_helper()
    {
        if (*m_heap_block == NULL) operator delete(m_guard_block);
        m_last = m_previous;
    }
    void **m_heap_block, *m_guard_block;
    _heap_cleanup_helper *m_previous;
    static _heap_cleanup_helper *m_last;
};

_heap_cleanup_helper *_heap_cleanup_helper::m_last;

template <typename p_alloc_type>
class _heap_cleanup_tpl : public _heap_cleanup_helper
{
    public:
    _heap_cleanup_tpl(p_alloc_type **p_heap_block) :
        _heap_cleanup_helper((void **)p_heap_block)
    {
    }
};

Пользовательский новый оператор выглядит следующим образом:

void *operator new (size_t p_cbytes)
{
    void *l_retval = malloc(p_cbytes);

    if (
        l_retval != NULL &&
        *_heap_cleanup_helper::m_last->m_heap_block == NULL &&
        _heap_cleanup_helper::m_last->m_guard_block == NULL
    )
    {
        _heap_cleanup_helper::m_last->m_guard_block = l_retval;
    }
    if (p_cbytes != 0 && l_retval == NULL) throw std::bad_alloc();

    return l_retval;
}

void operator delete(void *p_buffer)
{
    if (p_buffer != NULL) free(p_buffer);
}

Я думаю, что конструктору было бы странно вызывать исключение. Не могли бы вы получить возвращаемое значение и протестировать его на своем главном сервере?

class Blah
{
   public:

   Blah()
       {
           if Error
           {
              this.Error = "oops";
           }
        }
};

void main()
{
Blah* b = NULL;

b = new Blah();

if (b.Error == "oops")
{
   delete (b);
   b = NULL;
}