Есть ли минус в том, что вы никогда не создадите файлы ObjC, но всегда будете создавать файлы ObjC ++?

Question

По умолчанию Xcode создает файлы .h и .m при запросе нового класса ObjC.Все работает нормально, пока вам не понадобится обратиться к любому файлу C ++ в другом месте вашего проекта и начать #import его в файл .h или .m

В этот момент компилятор ObjC сильно запутывается и бросает горыошибок синтаксического анализа, и вы, пользователь (то есть, я), становитесь еще более запутанными, пока не столкнетесь со мной: конечно, вместо этого я должен сделать этот файл файлом ObjC ++.

Возможны следующие варианты:

1. сообщает Xcode, что этот конкретный файл, даже если это файл .m, действительно является файлом ObjC ++, или
2. переименуйте этот файл в .mm.

Первый вариант не очень приятен для меня, потому что этот файл на самом деле является ObjC ++ независимо от того, что думает проект.

Второй вариант тоже не годится, поскольку он портит репозиторий Git, который затем «забывает», что раньше был другой файл .m, который действительно является историей этого «нового» файла .mm.

Поэтому я решил теперь всегда переименовывать любой файл .m, который Xcode создает для меня, в первую очередь .mm после его создания, чтобы я не потерял историю.

До сих пор это работало хорошо для меня, но у меня в голове есть небольшое беспокойство, что может быть какой-то угловой случай, когда я действительно хочу иметь файл ObjC, а не файл ObjC ++.

Какими будут эти угловые случаи?Кто-нибудь знает о любом файле ObjC ++, который, как оказалось, НЕ содержит никаких ссылок на C ++, но каким-то образом задушит компилятор ObjC, просто из-за того, что он является файлом .mm?

просто осудить использование .m навсегда и вместо этого придерживаться .mm?

Answer 1

Анализ C ++ намного медленнее, чем анализ ObjC, поэтому файлы ObjC ++ имеют значительно более длительное время компиляции.Я не уверен, будут ли эти накладные расходы применяться к файлам ObjC ++, не содержащим C ++, но было бы определенно разумно, что их сложнее анализировать только потому, что компилятору нужно искать конструкции C ++.

Такжесистема типов C ++ имеет несколько немного отличающиеся от C правила, которые также применяются к коду ObjC / C в файле C ++.Я не помню деталей, но это не будет вредно;просто может потребоваться несколько дополнительных бросков.

Answer 2

Создайте шаблон файла Objective-C ++, чтобы при создании нового файла вы получали файл .mm вместо файла .m. Сделайте копию шаблонов классов Apple Objective-C и переименуйте файлы .m в .mm. Более подробная информация о создании шаблонов файлов Xcode 4 доступна в следующей статье:

Создание пользовательских шаблонов файлов Xcode 4

Answer 3

Недостатков нет, хотя для вас созданы два метода (.cxx_construct и .cxx_destruct), но они используются только для создания и уничтожения объектов C ++ при создании / освобождении экземпляра. Если в вашем классе нет членов C ++, эти функции ничего не делают и добавляют только очень низкие издержки. В противном случае у вас все еще есть функции C, сгенерированные для ваших методов Objective C, а не функции C ++.

Answer 4

Я использую файл .mm исключительно для своего кода iOS и никогда не было проблем. Да, мои компиляции немного медленнее в том, что чистая компиляция занимает 15 секунд против 10 секунд. По крайней мере, на iMac это неважно.

Answer 5

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

Хороший способ избежать загромождения заголовков obj-c с помощью c ++ - это объявить переменные экземпляра в файле реализации (что разрешено в xcode 4.2 / clang 3.0, возможно, раньше),Например:

@implementation MyClass {
    std::vector<int> myVector;
}

Это помогает минимизировать точки соприкосновения между объективом-c и c ++.