Предупреждения при компиляции wxWidgets-3.0.5 пакетом MinGW-8.1.0

Разработчик уже его допустил. У вас всего несколько вариантов тут:

1) Вы либо качаете компилятор, на котором UB проявляется в нужную разработчикам сторону. Т.е. код, который получился, соответствует их ожиданиям и тестам. Очень важно понимать, что отсутствие предупреждений и проблем при тестировании не значит, что ошибки в коде нет. Она есть, просто не проявляет себя.

2) Либо вы заводите баг в их багтрекере и ждете исправления, затем берете исправленную версию.

3) Либо вы можете сами попробовать устранить проблему.

Добавлено через 6 минут

AlexKreep

, и да, предупреждения от ошибок в С++ отличаются только требованием в стандарте диагностики с отказом от компиляции, либо отсутствием такого требования.

Иными словами, в строгом смысле слова, ошибками в С++ является только то, что явно прописано в стандарте как ошибка. Все остальное остается на усмотрение разработчиков компилятора. Тем не менее, в стандарте обозначено полным полно явно ошибочных ситуаций для которых диагностика либо не обязательна, либо в принципе невозможна в общем случае.

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

Добавлено через 3 минуты

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

Добавлено через 29 минут

Проблему с проверкой this на нуль, кстати, относительно недавно мне пришлось решать в QtDesigner из Qt-3.

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

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

В общих чертах, цикл по связному списку

C++Выделить код

1
2
3
4
5

do 
{
    p->save();
}
while((p = p->next));

Если список пуст, т.е.

p == NULL

, то в

do

будет вызов

save

на нулевом указателе.

Внутри

save

стояла проверка

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

Собственно компилятор теперь выбросил бесполезную проверку, потому что this не может быть NULL никогда.

Компилятор виноват? Конечно нет. С самого начала, стандарт С++, код, который разыменовывает нулевой указатель, считал ошибочным, содержащим неопределенное поведение (UB), и оставлял его без обязательной диагностики (потому что ее невозможно сделать в общем случае). Раньше это работало, потому что this передавался в метод на общих основаниях, через стек. И не применялись подобного рода оптимизации. Ситуация изменилась: новая платформа дала возможность лучше оптимизировать код, и код с ошибкой сломался. А достаточно лишь было переписать его так, и не извращаться:

C++Выделить код

1
2
3
4
5

while(p)
{
    p->save();
    p = p->next;
}