Я часто создаю локальные вспомогательные классы внутри методов, везде, где такой класс локально полезен, но не имеет значения вне метода. Я просто наткнулся на случай, когда мне хотелось бы, чтобы два локальных класса были взаимозависимыми.взаимно зависимые локальные классы (или взаимно рекурсивные лямбда)
Идея заключается в том, чтобы иметь следующую закономерность:
void SomeClass::someMethod()
{
struct A
{
B * b;
void foo() { if(b) b->bar(); };
};
struct B
{
A * a;
void bar() { if(a) a->foo(); }
};
}
Но это не компилируется, потому что A
потребности B
. Вперед декларирование B
помогает скомпилировать строку B * b;
, но для этого метода A::foo()
требуется полное объявление B
, и компилятор жалуется.
Я вижу два обходные пути:
объявления и определения классов в SomeClass.cpp до
SomeClass::someMethod()
. Я чувствую, что это не изящно, поскольку не только классы не являются локальными дляSomeClass::someMethod()
, но даже не локальны дляSomeClass
.Объявление классов в SomeClass.h, вложенных в
SomeClass
, и определение их в SomeClass.cpp. Мне не нравится это решение либо потому, что не только классы не являются локальными дляSomeClass::someMethod()
, но он загрязняет SomeClass.h без уважительной причины, кроме ограничения языка.
Отсюда два вопроса: можно ли вообще иметь классы, локальные для SomeClass::someMethod()
? Если нет, вы видите более элегантные обходные пути?
Почему вам это нужно локально внутри метода? вы можете объявить/определить их только в файле .cpp и не загрязнять файл .h. –
@BryanChen: на самом деле это не значит, что я * нуждаюсь в этом, это просто более элегантно, если я могу: если класс детали реализации для метода, а затем определение его внутри метода - это место, где оно принадлежит. Просто хорошая инкапсуляция ООП. – Boris
@Boris Его инкапсуляция, но не OOP. – woolstar