Поделиться через


Функции MFC ASSERT_VALID и CObject::AssertValid

Обновлен: Ноябрь 2007

Этот раздел применим к:

Выпуск

Visual Basic

C#

C++

Web Developer

Экспресс-выпуск

Тема не применяется Тема не применяется

Только машинные коды

Тема не применяется

Standard

Тема не применяется Тема не применяется

Только машинные коды

Тема не применяется

Pro и Team

Тема не применяется Тема не применяется

Только машинные коды

Тема не применяется

Обозначения:

Тема применяется

Применяется

Тема не применяется

Неприменимо

Тема применяется, но команда по умолчанию сокрыта

Команда или команды скрытые по умолчанию.

Функция-член CObject::AssertValid периодически проверяет внутреннее состояние объекта во время выполнения. Хотя обычно и не требуется переопределять AssertValid при получении класса, производного от CObject, но все же это действие сделает класс более безопасным и надежным. Функция AssertValid должна выполнять утверждения для всех переменных-членов объекта, чтобы проверить их значения на допустимость. Например, с ее помощью следует проверить, что переменные-члены указателя не равны NULL.

В следующем примере показан способ объявления функции AssertValid:

class CPerson : public CObject
{
protected:
    CString m_strName;
    float   m_salary;
public:
#ifdef _DEBUG
    // Override
    virtual void AssertValid() const;
#endif
    // ...
};

При переопределении AssertValid перед выполнением собственных проверок вызовите версию AssertValid базового класса. Затем примените макрос ASSERT для проверки членов, уникальных для данного производного класса, как показано ниже:

#ifdef _DEBUG
void CPerson::AssertValid() const
{
    // Call inherited AssertValid first.
    CObject::AssertValid();

    // Check CPerson members...
    // Must have a name.
    ASSERT( !m_strName.IsEmpty());
    // Must have an income.
    ASSERT( m_salary > 0 );
}
#endif

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

Например, рассмотрим класс CMyData, содержащий CObList в одной из своих переменных-членов. В переменной CObList, m_DataList, хранится коллекция объектов CPerson. Сокращенное объявление CMyData выглядит следующим образом:

class CMyData : public CObject
{
    // Constructor and other members ...
    protected:
        CObList* m_pDataList;
    // Other declarations ...
    public:
#ifdef _DEBUG
        // Override:
        virtual void AssertValid( ) const;
#endif
    // And so on ...
};

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

#ifdef _DEBUG
void CMyData::AssertValid( ) const
{
    // Call inherited AssertValid.
    CObject::AssertValid( );
    // Check validity of CMyData members.
    ASSERT_VALID( m_pDataList );
    // ...
}
#endif

CMyData использует механизм AssertValid для проверки допустимости объектов, хранящихся в его членах данных. Метод переопределения AssertValid из CMyData вызывает макрос ASSERT_VALID для собственной переменной-члена m_pDataList.

Проверка допустимости на этом уровне не останавливается, так как класс CObList тоже переопределяет AssertValid. Это переопределение выполняет добавочную проверку допустимости внутреннего состояния списка. Таким образом, тест допустимости для объекта CMyData вызывает дополнительную проверку внутреннего состояния сохраненного объекта списка CObList.

Приложив еще немного усилий, точно так же можно добавить тесты допустимости для объектов CPerson, хранящихся в списке. Можно создать класс CPersonList из CObList и переопределить AssertValid. В переопределении можно вызвать CObject::AssertValid и затем итерировать все элементы списка, вызывая AssertValid по каждому объекту CPerson в списке. Класс CPerson, показанный в начале этого раздела, содержит уже переопределенный AssertValid.

Это очень мощный механизм для построения отладки. А при построении окончательной версии этот механизм автоматически отключается.

Ограничения AssertValid

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

См. также

Основные понятия

Утверждения MFC