Классы C++ как переменные экземпляра класса Objective C
volatile означает, что хранилище может измениться в любое время и измениться, но что-то вне контроля пользовательской программы. Это означает, что если вы ссылаетесь на переменную, программа должна всегда проверять физический адрес (то есть отображенный ввод fifo), а не использовать его в кэшированном виде.
4 ответа
Звучит как классическое использование протокола interface / @. Определите протокол Objective-C для API, а затем предоставьте реализацию этого протокола, используя свой класс Objective-C ++. Таким образом, клиентам нужно знать только о протоколе, а не о заголовке реализации. Поэтому, учитывая исходную реализацию
@interface Foo : NSObject
{
id regularObjectiveCProperty;
CPPClass cppStuff;
}
@end
, я бы определил протокол
//Extending the NSObject protocol gives the NSObject
// protocol methods. If not all implementations are
// descended from NSObject, skip this.
@protocol IFoo <NSObject>
// Foo methods here
@end
и изменил исходное объявление Foo на
@interface Foo : NSObject <IFoo>
{
id regularObjectiveCProperty;
CPPClass cppStuff;
}
@end
. Клиентский код затем мог работать с типом id и не нужно компилировать как Objective-C ++. Очевидно, вы можете передать этим клиентам экземпляр Foo .
Есть ли какая-то конкретная причина, по которой вы не можете просто использовать Objective C ++ для всего? Просто переключите компилятор на Compile Sources As: Objective C ++ (или переименуйте все ваши исходные файлы с .cpp или .m в .mm). Затем вы можете свободно смешивать свой C ++ и Objective C.
C ++ начинает распространяться на все application
What problem is there with that? If your Objective C code is doing only C/Objective C code in general, then it will almost certainly not be affected at all by being compiled as C++. There is no appreciable size or speed performance issues.
The only two downsides I've found are: you cannot (yet) use clang static analyser to analyseC++; some (relatively weird) C code wont work in C++, which is occasionally an issue when using third party C code.
Вы можете обнаружить, что у вас есть проблемы с этим - из того, что я помню о ObjectiveC ++, вы можете обнаружить, что конструктор и деструктор для вашего вложенного объекта C ++ не вызываются.
Недавно я тоже столкнулся с этой проблемой. В моем случае протокол был излишним. Мне просто нужно было сохранить указатель на объект доступа к данным, который оказался объектом C ++.
Я объявил класс с переменной экземпляра void * и преобразовал его, когда я использую его в методы экземпляра.
Это немного хитроумно, но концептуально очень похоже на тип Objective-C id .