Comments 13
А так?
@implementation MyClass
{
std::map<int, id> lookupTable;
}
...
@end
Сам использую .mm подход
Не уловил реальных минусов это подхода в рассуждениях автора статьи.
1) Переименовать файлы — не проблема (а особенно если заранее их создавать с таким расширением)
2) Вы единственный программист с++ — какая разница какое расширение у файлов, для программистов Objective-C — тоже не проблема (только если они не молятся на это)
Не уловил реальных минусов это подхода в рассуждениях автора статьи.
1) Переименовать файлы — не проблема (а особенно если заранее их создавать с таким расширением)
2) Вы единственный программист с++ — какая разница какое расширение у файлов, для программистов Objective-C — тоже не проблема (только если они не молятся на это)
Есть еще пару минусов:
«Кроме того, проблемы могут возникнуть при компиляции кода на чистом С компилятором С++, редко случается, что такое проходит полностью безболезненно. Сверх того, это значит, что код нельзя будет повторно использовать автоматически в других проектах Objective-C».
Лично у меня проблем с этим не было, но С++ не является надмножеством С, поэтому теоретически возможен случай, когда эта разница станет фатальной.
И если мы будем использовать этот проект в других, то в них тоже по цепочке придется переименовывать файлы :) конечно, Вы правы, и это не такая уж проблема, но если исходный проект используется как, например, open-source основа во многих других, то лучше будет не заставлять людей менять что-то у себя в проектах.
«Кроме того, проблемы могут возникнуть при компиляции кода на чистом С компилятором С++, редко случается, что такое проходит полностью безболезненно. Сверх того, это значит, что код нельзя будет повторно использовать автоматически в других проектах Objective-C».
Лично у меня проблем с этим не было, но С++ не является надмножеством С, поэтому теоретически возможен случай, когда эта разница станет фатальной.
И если мы будем использовать этот проект в других, то в них тоже по цепочке придется переименовывать файлы :) конечно, Вы правы, и это не такая уж проблема, но если исходный проект используется как, например, open-source основа во многих других, то лучше будет не заставлять людей менять что-то у себя в проектах.
Если использовать в других своих «своих» продуктах — это не проблема.
Если ваша библиотека используется в других сторонних проектах как база, тут конечно вам надо позаботится об обратно совместимости
Но и тут тоже возникает вопрос, зачем вам вдруг понадобился С/C++ (пример с std::map мне показался неудачным).
Ситуация ".m" и ".mm" полностью такая же как и с ".c" и ".cpp"
P.S. Я полностью согласен с тем, что ситуация описанная в статье реальна (редко, но тем не менее). И для lеgacy кода это вариант.
Если ваша библиотека используется в других сторонних проектах как база, тут конечно вам надо позаботится об обратно совместимости
Но и тут тоже возникает вопрос, зачем вам вдруг понадобился С/C++ (пример с std::map мне показался неудачным).
Ситуация ".m" и ".mm" полностью такая же как и с ".c" и ".cpp"
P.S. Я полностью согласен с тем, что ситуация описанная в статье реальна (редко, но тем не менее). И для lеgacy кода это вариант.
Если прочитать оригинал статьи, и посмотреть реальное использование PImpl Objective-C wrapper for the Open-VCDiff decoder.
Такое использование очень даже оправданно и красивое.
Такое использование очень даже оправданно и красивое.
Есть еще минусы:
1. NSAssert не останавливает выполнение программы, да и вообще ведет себя неадекватно
2. Придется отказаться от ARC во всем проекте
3. Невозможность автоматического рефакторинка в xcode для mm файлов.
1. NSAssert не останавливает выполнение программы, да и вообще ведет себя неадекватно
2. Придется отказаться от ARC во всем проекте
3. Невозможность автоматического рефакторинка в xcode для mm файлов.
- (void)dealloc
{
delete impl;
[self dealloc];
}= stack overflow.
> Objective-C также довольно агрессивен в плане управления памятью, когда нет, например, сборщика мусора
> захламлять код release'ами и retain'ами
facepalm.jpg
По опыту, лучше любыми способами избегать C++ в ObjC-коде, а если уж совсем прижимает, писать ObjC-обертки.
> захламлять код release'ами и retain'ами
facepalm.jpg
По опыту, лучше любыми способами избегать C++ в ObjC-коде, а если уж совсем прижимает, писать ObjC-обертки.
Много воды уже утекло с момента публикации перевода, но для актуальности добавлю ссылку на дополнение к оригинальной статье. www.philjordan.eu/article/mixing-objective-c-c++-and-objective-c++
Sign up to leave a comment.
Способы встраивания C++ в Objective-C проекты