Данное диагностическое правило основано на руководстве AUTOSAR (AUTomotive Open System ARchitecture) по разработке программного обеспечения.
Функция, объявленная в области видимости блока, будет видна также в пространстве имён, обрамляющем блок.
Пример кода:
namespace Foo { void func() { void bar(); // <= bar(); } } void Foo::bar() // Function 'bar' is visible here { }
Программист хотел сузить область видимости функции, задекларировав ее в блоке функции 'func'. Однако функция 'bar' видна также за пределами пространства имен 'Foo'. Поэтому следует задекларировать функцию явно в обрамляющем пространстве имен:
namespace Foo { void bar(); void func() { bar(); } } void Foo::bar() // Function 'bar' is visible { }
Также, вследствие неоднозначности грамматики языка C++, декларация функции может выглядеть как декларация объекта:
struct A { void foo(); }; int main() { A a(); a.foo(); // compile-time error }
Данная проблема известна как "Most vexing parse": компилятор разрешает данную неоднозначность "задекларировать функцию или объект" в пользу "задекларировать функцию". Поэтому, несмотря на ожидание программиста задекларировать объект класса 'A' и вызвать нестатическую функцию-член класса 'A::foo', компилятор воспримет это как объявление функции 'a', не принимающей параметров и возвращающей тип 'A'.
Чтобы избежать путаницы, анализатор также предупреждает о таких объявлениях.
Данная диагностика классифицируется как:
|