Данное диагностическое правило основано на руководстве 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'.
Чтобы избежать путаницы, анализатор также предупреждает о таких объявлениях.
Данная диагностика классифицируется как:
|