Не только диагностики. Из самого значимого, что будет в следующем релизе:
Однако, я намеренно не добавляю этот функционал в свои "неофициальные" релизы, чтобы избежать случаев, когда пользователи преждевременно подстраивают свои скрипты к новым возможностям компилятора.
Например, если нужно использовать в макросе новый функционал
__pragma, но при этом сохранить совместимость со старыми версиями компилятора, то в следующей версии (3.10.11) это можно будет сделать так:
#if __Pawn >= 0x030A && defined __PawnBuild
#if __PawnBuild >= 11
#define _MAYBE_UNUSED_ __pragma("unused")
#endif
#endif
#if !defined _MAYBE_UNUSED_
#define _MAYBE_UNUSED_
#endif
// ...
new _MAYBE_UNUSED_ x; // компилятор не будет жаловаться, что переменная не используется
Однако мои билды распознаются как текущая версия (3.10.10), поэтому если я добавлю туда что-то из нового функционала, пользователи начнут адаптировать под него скрипты так, как будто он появился в текущей версии, а не в следующей:
#if __Pawn >= 0x030A && defined __PawnBuild
#if __PawnBuild >= 10
#define _MAYBE_UNUSED_ __pragma("unused")
#endif
#endif
Такая фрагментация среди сообщества недопустима и я не хотел бы вносить в неё вклад. Именно поэтому я специально не включаю новый функционал в свои билды, а добавляю только самое необходимое: багфиксы и новые диагностики.
В принципе про диагностики тоже можно заявить, что они нарушают совместимость, но на самом деле с ними всё проще: для их отключения не обязательно полагаться на конкретную версию компилятора, достаточно лишь проверить объявление
__PawnBuild (появилось в релизе 3.10.1, вышедшем 4 года назад), чтобы убедиться, что это не слишком старая версия компилятора и мы можем использовать
#pragma warning:
#if __Pawn >= 0x30A && defined __PawnBuild
#pragma warning disable 249
#endif
Если в компиляторе есть 249-я диагностика, она будет отключена, если нет - строка с
#pragma будет проигнорирована.
По-моему, я уже как-то говорил на этом форуме, что это не просто баг, а недоработка в коде чтения/препроцессирования исходных файлов. Изменения в столь фундаментальном механизме могут отразиться на совместимости с некоторыми скриптами/инклудами, или же замедлить компиляцию.
Уже поддерживается до четырёх измерений. Если есть какие-то реалистичные примеры, в которых может понадобиться 5 или более измерений - я готов выслушать их и при необходимости запросить у сопровождающих компилятора, чтобы увеличили лимит.
Тоже уже говорил об этом раньше, что в последний раз, когда смотрел на код инициализации массивов, ничего из этого спагетти толком разобрать не смог.
Проблемы, перечисленные выше, я оставляю на потом не из вредности. То, что я исправляю баги и делаю какие-то новые фичи для компилятора, не значит, что я всемогущий. Бывают проблемы, в правильном решении которых я не уверен, или какие-то вещи, в которых не разбираюсь - к таким вещам я привык возвращаться позже, когда лучше разберусь в вопросе, дабы не терять время на бесполезные поиски решения, а с гораздо большей эффективностью потратить его на устранение других проблем.
Ответить с цитированием
Сообщение от Daniel_Cortez
