Способы встраивания C++ в Objective-C проекты

[farcaller]

А так?

@implementation MyClass
{
std::map<int, id> lookupTable;
}

...

@end

[farcaller]

иногда мне кажется, что комментарии и превью рисуют два разных хабрапарсера >_<

[notxcain]

Вот именно, что нам мешает определить ivar в Class Extension непосредственно в .mm файле?

[PavloG]

Сам использую .mm подход
Не уловил реальных минусов это подхода в рассуждениях автора статьи.

1) Переименовать файлы — не проблема (а особенно если заранее их создавать с таким расширением)
2) Вы единственный программист с++ — какая разница какое расширение у файлов, для программистов Objective-C — тоже не проблема (только если они не молятся на это)

[medvednick]

Есть еще пару минусов:

«Кроме того, проблемы могут возникнуть при компиляции кода на чистом С компилятором С++, редко случается, что такое проходит полностью безболезненно. Сверх того, это значит, что код нельзя будет повторно использовать автоматически в других проектах Objective-C».

Лично у меня проблем с этим не было, но С++ не является надмножеством С, поэтому теоретически возможен случай, когда эта разница станет фатальной.

И если мы будем использовать этот проект в других, то в них тоже по цепочке придется переименовывать файлы :) конечно, Вы правы, и это не такая уж проблема, но если исходный проект используется как, например, open-source основа во многих других, то лучше будет не заставлять людей менять что-то у себя в проектах.

[PavloG]

Если использовать в других своих «своих» продуктах — это не проблема.
Если ваша библиотека используется в других сторонних проектах как база, тут конечно вам надо позаботится об обратно совместимости
Но и тут тоже возникает вопрос, зачем вам вдруг понадобился С/C++ (пример с std::map мне показался неудачным).

Ситуация ".m" и ".mm" полностью такая же как и с ".c" и ".cpp"

P.S. Я полностью согласен с тем, что ситуация описанная в статье реальна (редко, но тем не менее). И для lеgacy кода это вариант.

[PavloG]

Если прочитать оригинал статьи, и посмотреть реальное использование PImpl Objective-C wrapper for the Open-VCDiff decoder.
Такое использование очень даже оправданно и красивое.

[stel]

Есть еще минусы:
1. NSAssert не останавливает выполнение программы, да и вообще ведет себя неадекватно
2. Придется отказаться от ARC во всем проекте
3. Невозможность автоматического рефакторинка в xcode для mm файлов.

[Skie]

- (void)dealloc
{
delete impl;
[self dealloc];
}
= stack overflow.

[medvednick]

прошу прощения, конечно же

— (void)dealloc
{
delete impl;
[super dealloc];
}

[biseptol]

> Objective-C также довольно агрессивен в плане управления памятью, когда нет, например, сборщика мусора
> захламлять код release'ами и retain'ами

facepalm.jpg

По опыту, лучше любыми способами избегать C++ в ObjC-коде, а если уж совсем прижимает, писать ObjC-обертки.

[stel]

Поддерживаю, более того, не могу вспомнить ниодного примера из своей практики, где бы это реально было бы необходимо (особенно, касающиеся управления памятью). Исключения конечно составляют сторонние библиотеки.

[solarfly]

Много воды уже утекло с момента публикации перевода, но для актуальности добавлю ссылку на дополнение к оригинальной статье. www.philjordan.eu/article/mixing-objective-c-c++-and-objective-c++