По первому примеру много вопросов: 1. Уже озвученный. Как анализатор реагирует, если класс унаследован от FGCObject? 2. А что, если унаследован, но в методе CollectReferencedObjects конкретно этот UObject не перечисляется? 3. Если класс таки унаследован от UObject, а вот объект-поле забыли пометить как UPROPERTY или использовать другие способы обозначить реф? Из опыта это гораздо более часто встречающаяся ошибка, чем приведенный вами пример
Второй пример странный. Настройками проекта можно сделать так, чтобы объекты, не соответствующие названию, выдавали ошибку компиляции. Не совсем понятно, зачем тогда статическому анализатору нужна такая проверка.
Из дополнительных идей по GC. Если появилось желание уничтожить объект вручную, то офф. документация рекомендует использовать BeginDestroy. Но при этом умалчивает, что рефу на объект нужно обязательно присвоить nullptr или как-то иначе уничтожить реф на него. Иначе GC никогда не дойдет до уничтожения объекта. И если кто-то другой попытается снова сделать BeginDestroy, то получится краш.
Звучит как маловероятный сценарий, но тем не менее за последние 4 года работы с движком я постоянно сталкивался с этим. Было бы здорово, если бы такое можно было обнаружить заранее, а не в рантайме, когда имя объекта и полная информация об овнерах уже утеряна.
1. Анализатор не ругается если класс унаследован от FGCObject. 2. Пока анализатор никак не реагирует если в методе CollectReferencedObjects, конкретно этот UObject не перечисляется, на такой случай планируется новая диагностика. 3. Также новая диагностика будет обрабатывать случай, если объект-поле унаследованного от UObject забыли пометить как UPROPERTY. Диагностическое правило было добавлено по просьбе клиента, который хотел находить случаи, когда в классе ненаследнике от UObject есть указатель на тип, наследуемый от UObject.
По первому примеру много вопросов:
1. Уже озвученный. Как анализатор реагирует, если класс унаследован от FGCObject?
2. А что, если унаследован, но в методе CollectReferencedObjects конкретно этот UObject не перечисляется?
3. Если класс таки унаследован от UObject, а вот объект-поле забыли пометить как UPROPERTY или использовать другие способы обозначить реф? Из опыта это гораздо более часто встречающаяся ошибка, чем приведенный вами пример
Второй пример странный. Настройками проекта можно сделать так, чтобы объекты, не соответствующие названию, выдавали ошибку компиляции. Не совсем понятно, зачем тогда статическому анализатору нужна такая проверка.
Из дополнительных идей по GC. Если появилось желание уничтожить объект вручную, то офф. документация рекомендует использовать BeginDestroy. Но при этом умалчивает, что рефу на объект нужно обязательно присвоить nullptr или как-то иначе уничтожить реф на него. Иначе GC никогда не дойдет до уничтожения объекта. И если кто-то другой попытается снова сделать BeginDestroy, то получится краш.
Звучит как маловероятный сценарий, но тем не менее за последние 4 года работы с движком я постоянно сталкивался с этим. Было бы здорово, если бы такое можно было обнаружить заранее, а не в рантайме, когда имя объекта и полная информация об овнерах уже утеряна.
1. Анализатор не ругается если класс унаследован от FGCObject.
2. Пока анализатор никак не реагирует если в методе CollectReferencedObjects, конкретно этот UObject не перечисляется, на такой случай планируется новая диагностика.
3. Также новая диагностика будет обрабатывать случай, если объект-поле унаследованного от UObject забыли пометить как UPROPERTY.
Диагностическое правило было добавлено по просьбе клиента, который хотел находить случаи, когда в классе ненаследнике от UObject есть указатель на тип, наследуемый от UObject.