2015-05-05 1 views
2

В последнее время я столкнулся со странной проблемой, которую простой источник не хотел компилировать. Я искал решения (и причины) на многих сайтах, но без хороших эффектов (кроме сообщений об ошибках, но я не нашел там прямой причины).Внутренняя ошибка компилятора в состоянии с условием bool

Ниже я привожу простой код, чтобы воспроизвести эту ситуацию:

struct Foo { 
    Foo() : m_x(true) {} 
    __property bool x = { read=m_x }; 

    private: 
    bool m_x; 
}; 

template<typename T> 
struct TMyPointer { 
    T * m_ptr; 
    TMyPointer(T * ptr) : m_ptr(ptr) {} 
    ~TMyPointer() 
    { 
    delete m_ptr; 
    } 

    T * operator->() const 
    { 
    return Get(); 
    } 

    T * Get() const 
    { 
    if(m_ptr == NULL) 
     ; // some error handling 

    return m_ptr; 
    } 
}; 

int _tmain(int argc, _TCHAR* argv[]) 
{ 
    TMyPointer<Foo> bar(new Foo); 

    if(bar->x && 1 == 1) ; // Failed 
    if(1 == 1 && bar->x) ; // OK 
    if(!!bar->x && 1 == 1) ; // OK 
    if(bar->x == true && 1 == 1) ; // OK 
    if((bar->x) && 1 == 1) ; // OK 

    return 0; 
} 

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

Это поведение У меня есть только во время компиляции выпуска. Для воспроизведения я использовал Embarcadero® C++ Builder® xe5 Версия 19.0.13476.4176

Сообщение об ошибке: [bcc32 Fatal Error] File1.cpp (43): F1004 Внутренняя ошибка компилятора при 0x14470090 с базой 0x14410000

Кто-нибудь знает, в чем проблема в приведенном выше примере? Может быть, шаблоны использования с механизмом свойств являются причиной?

+4

ICE следует всегда сообщать поставщику/поставщику компилятора. Это означает, что компилятор признает, что что-то пошло не так. По определению, этого не должно было быть; поставщик, вероятно, захочет его исправить, особенно если у вас небольшое чистое воспроизведение (MCVE ([Как создать минимальный, полный и проверенный пример?] (http://stackoverflow.com/help/mcve)) это термин, используемый при переполнении стека). Им будет очень важно исправить это в текущей версии; поскольку ваша версия компилятора более древняя, они будут менее заинтересованы в ее исправлении, если это также не вызовет проблемы в текущей версии. –

+0

Просто любопытно - почему вы заново изобретаете 'std :: auto_ptr' /' std :: unique_ptr' вместо того, чтобы использовать их как есть? –

+0

@Remy Lebeau Да, у вас все получилось, но это не зависит от меня. Я работаю в большей команде, которая поддерживает довольно старое приложение. Многие механизмы были написаны много лет назад и без проблем прошли через годы. В последнее время коллега из команды написал новую функциональность, которая вызывает проблему компиляции. Во время отладки я пришел к выводу, что причиной является условие. Помните, что приведенный выше код является лишь простым примером, который воспроизводит эту ситуацию. Конечно, мои коллеги знают, что существуют умные указатели, но я думаю, что это не имеет значения для этой темы :) –

ответ

0

В моем случае это простое решение, кажется, это проблемное состояние внутри метода Get. Когда я изменяю

if(m_ptr == NULL) 

в эквивалентной форме

if(!m_ptr) 

все компилируется без ошибок.

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

+0

Как говорили другие, вы должны сообщить об этом Embarcadero, чтобы они могли узнать об этой ошибке. Если нет, у них не так много возможностей их фиксации. В любом случае, они, безусловно, не будут исправлять что-либо на XE5 (а не 6 или 7), поэтому хорошо, что вы обходным путем, как вы показали. –

Смежные вопросы