История изменений

Можно, если текущий тип данных в левой части тоже. А для переопределения cin>> / cout<< уже требуется городить функции, причём в случае cin ещё и скорее всего дружественные.

В этом случае — да.

в C++ во время поиска по ключу в map не найдено значение, создаётся новая пара ключ-значение.

Но всегда можно воспользоваться методом find(). Хотя согласен с тем, что автоматическое добавление элемента при обращении к несуществующему ключу не очень логично.

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

С этим тоже в основном согласен. Но в крестах большинство этих ситуаций как раз являются ошибками. А в си этого не сделали, понятно, из-за большого объёма легаси. И это тоже логично. По крайней мере лучше, чем в питоне, где для разных скриптов приходится одновременно держать разные версии, постоянно путаясь в них, а когда старая версия перестанет поддерживаться — срочно всё переписывать.

например, GCC при неправильных фактических параметрах функций printf / scanf выдаёт предупреждение вместо молчаливого ухода в UB.

Имхо, такая реакция должна быть на любое ub.

Конечно же, упомянутый Вами алиасинг может «выстрелить в ногу» не в том месте, где произошло преобразование, поэтому на этапе компиляции это не отследить. Поэтому в данном случае использование неопределённого поведения оправдано.

Однако Visual C++ разрешает такое, не выстреливая в ногу. И gcc при задании опции -fno-strict-aliasing такое позволяет. Так что не всё так однозначно.

Статья даже отличная. Но я не понял, как из неё следует наблюдаемая мной ситуация с wxWidgets.

Непосредственно — никак. А опосредованно — через работу линкера, которая там подробно описывается.

Можно, если текущий тип данных в левой части тоже. А для переопределения cin>> / cout<< уже требуется городить функции, причём в случае cin ещё и скорее всего дружественные.

В этом случае — да.

в C++ во время поиска по ключу в map не найдено значение, создаётся новая пара ключ-значение.

Но всегда можно воспользоваться методом find(). Хотя согласен с тем, что автоматическое добавление элемента при обращении к несуществующему ключу не очень логично.

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

С этим тоже в основном согласен. Но в крестах большинство этих ситуаций как раз являются ошибками. А в си этого не сделали, понятно, из-за большого объёма легаси. И это тоже логично. По крайней мере лучше, чем в питоне, где для разных скриптов приходится одновременно держать разные версии, постоянно путаясь в них, а когда старая версия перестанет поддерживаться — срочно всё переписывать.

например, GCC при неправильных фактических параметрах функций printf / scanf выдаёт предупреждение вместо молчаливого ухода в UB.

Имхо, такая реакция должна быть на любое ub.

Конечно же, упомянутый Вами алиасинг может «выстрелить в ногу» не в том месте, где произошло преобразование, поэтому на этапе компиляции это не отследить. Поэтому в данном случае использование неопределённого поведения оправдано.

Однако Visual C++ разрешает такое, не выстреливая в ногу. И gcc при задании опции -fno-strict-aliasing такое позволяет. Так что не всё так однозначно.

Статья даже отличная. Но я не понял, как из неё следует наблюдаемая мной ситуация с wxWidgets.

Непосредственно — никак. А опосредованно через работу линкера, которая там подробно описывается.