Используем Objective-C в C++ без проблем

А разве существуют какие-либо проблемы с использованием Objective-C++ совместно с C++ кодом? Насколько мне известно, таких проблем никогда не было.

Новый день, новая статья на тему iOS/macos разработки, вызывающая вопросы.

Называется "Используем Objective-C в C++ без проблем". Хотя, по моим ощущениям, у автора есть пробелы и в одном, и в другом.

Всё началось с Принтера:

class Printer {
public:
    Printer(const std::string&);
    void Print() const;
};

На этом этапе я уже начал подозревать, что С++ сейчас будет такой себе. Я тоже далеко не эксперт, но некоторые вещи вроде понимаю.

Лирическое отступление о C++.

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

Мысль о том, что глядя на сигнатуру функции в С++ часто можно сразу представить себе реализацию, можно понять что функция делает. И говоря "сигнатура" имеется в виду именно список агрументов и возвращаемое значение, на название можно даже не смотреть.

Примеры:

// функция только читает из x
void f(const T& x);

// функция записывает в x по ссылке.
// не _может_, а именно так или иначе _записывает_ в x.
// иначе какого чёрта это не const ссылка?
void f(T& x); 

// функция использует копию x
void f(T x);

// функция хочет "поглотить" x, например сохранить куда-то.
// можно сделать move
void f(T&& x)

Так вот. Глядя на интерфейс Printer, можно сразу догадаться, что наверное Print() будет печатать то, что было передано в конструкторе. Но конструктор говорит о том, что он собирается только читать из аргумента. Хотя на самом деле, он хочет взять аргумент и положить себе в поле. В итоге произойдёт копирование, которого можно было избежать. Но дело даже не в копировании, а в запутывающем интерфейсе. Он говорит "я буду только читать", а на деле происходит что-то другое.

Одна лишь эта "мелочь" уже подрывает моё доверие к статье о C++.

Потом пошёл ObjectiveC.

template<typename T>
auto unique_void(T * ptr) -> unique_void_ptr{
    return unique_void_ptr(ptr, [](void const * data) {
            [(id)data dealloc];
    });
}

Здесь я тоже склонен заявить, что автор совершенно не разбирается в управлении памятью в ObjectiveC.

unique_void функция создаст новый указатель и позаботится о том чтобы память потом почистилась.

Каким образом почистилась? Если подразумевается вызов free() на указателе на ObjectiveC объект, то я нахожу это плохой идеей. Жизненный цикл ObjectiveC объектов управляется счётчиком ссылок. Что будет, если указателем на PrinterImpl владеет кто-то ещё? unique_void() просто уничтожит этот принтер, а другие пользователи получат мусор, хотя имели сильную ссылку. Более того, unique_void счётчика ссылок не увеличивает, но умеет "убивать". Что если бы это была среда с автоматическим подсчётом ссылок? Тогда PrinterImpl сразу умер бы, так как никто не держит сильной ссылки на него, и позже этот умный указатель попытался бы освободить мусор. Потом этот прямой вызов dealloc. Почему было просто не сделать retain перед созданием unique_ptr, а вместо dealloc не вызывать release? Тогда и память точно освободится правильно (может там далеко не только free() происходит), и заодно она не освободится тогда, когда этого делать не стоит (когда счётчик ещё не дошёл до нуля).

По моим ощущениям, тут скрестились две неграмотности, и велика вероятность получить неграмотность в квадрате как результат.

ps.

затрагивать неизвестные для меня области программирования

Как я и думал, если включить ARC, то жизнь немного упрощается. Вот мой пример:

PrinterImpl – ObjC принтер.

// PrinterImpl.h

#import <Foundation/Foundation.h>

@interface PrinterImpl: NSObject
@property (nonatomic, strong) NSString *message;

- (instancetype)initWithMessage:(NSString *)message;
+ (instancetype)printerWithMessage:(NSString *)message;

- (void)print;
@end

#import "PrinterImpl.h"

@implementation PrinterImpl

- (void)dealloc {
  NSLog(@"PrinterImpl dealloc");
}

- (instancetype)initWithMessage:(NSString *)message {
  self = [super init];
  if (self) {
    _message = message;
  }
  return self;
}

+ (instancetype)printerWithMessage:(NSString *)message {
  return [[self alloc] initWithMessage:message];
}

- (void)print {
  NSLog(@"message: %@", self.message);
}

@end

Его можно отдельно расширить поддержкой std::string:

// PrinterImpl+Cpp.h

#import "PrinterImpl.h"
#import <string>

@interface PrinterImpl(Cpp)
- (instancetype)initWithMessageStdString:(const std::string&)message;
+ (instancetype)printerWithMessageStdString:(const std::string&)message;
@end

// PrinterImpl+Cpp.mm

#import "PrinterImpl+Cpp.h"

@implementation PrinterImpl(Cpp)

- (instancetype)initWithMessageStdString:(const std::string&)message {
  return [self initWithMessage:[[NSString alloc] initWithCString:message.c_str()
                                                        encoding:NSUTF8StringEncoding]];
}

+ (instancetype)printerWithMessageStdString:(const std::string &)message {
  return [[self alloc] initWithMessageStdString:message];
}

@end

Принтер на C++, который использует "двойной impl". Printer::Impl только лишь имеет __strong PrinterImpl *impl_ сильную ссылку на Objective-C объект, жизненный цикл которого будет управляться ARC. т.е. PrinterImpl будет автоматически послан release деструктором Printer::Impl::~Impl.

// Printer.hpp

#pragma once
#include <memory>
#include <string>

class Printer {
public:
  Printer(const std::string& message);
  ~Printer();
  void Print() const;
private:
  class Impl;
  std::string message_;
  std::unique_ptr<Impl> impl_;
};

// Printer.mm

#import "Printer.hpp"
#import "PrinterImpl+Cpp.h"

class Printer::Impl {
public:
  Impl(PrinterImpl* impl): impl_(impl) {}
  __strong PrinterImpl *impl_;
};

Printer::~Printer() = default;

Printer::Printer(const std::string& message):
  message_(message),
  impl_(std::make_unique<Impl>([PrinterImpl printerWithMessageStdString:message]))
{}

void Printer::Print() const {
  [impl_->impl_ print];
}

Убедимся, что соседние файлы могут использовать Printer будучи обычным C++ кодом:

// User.hpp

#pragma once
#include <string>

void MyPrint(const std::string& message);

// User.cpp

#include "User.hpp"
#include "Printer.hpp"

void MyPrint(const std::string& message) {
  Printer(message).Print();
}

И, наконец, main.mm, который неспроста .mm, так как кто-то должен создать Autorelease Pool для Objective-C объектов, чтобы управление их памятью работало корректно. Без создания Autorelease Pool PrinterImpl не удалится. Чтобы убедиться в этом, я добавил -[PrinterImpl dealloc], который печатает сообщение при вызове.

#include "User.hpp"

int main(int argc, const char * argv[]) {
  @autoreleasepool {
    MyPrint("hello world");
  }
  return 0;
}

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

Тут у меня явного ответа нету, скажу лишь что когда я хочу писать на С++ и использовать инструменты которые написаны на Objective-C последнее что я хочу видеть, это миграцию всего проекта на Objective-C++ и замена .cpp на .mm.

Ничего не понятно.

Вот есть проект, 1000 cpp файлов. на -x c++. добавляем 1001 файл, .mm или .cpp, не важно, -x objective-c++, либо весь проект собираем как objective-c++ и используем его фичи только в .mm не важно.

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

У нас в проекте используется чет около 40 фрейморков из Apple SDK, пока вообще не видел проблем с такой схемой.

При этом сам код в mm файлах имеет базовую структуру С++ кода, с плюшками objective-c только там где без вызова сигналов прям уже ваще никак.
Так получаем код который могут сопровождать разработчики которые знают C++, а objc не очень. А ваше решение, ну не знаю. Если вы 1 его и поддерживаете, то вроде как и норм

// P.h

#if defined __APPLE__
@class Impl;
#else
class Impl;
#endif

class P {
  Impl* pimpl;

  void f();
};

// P.mm
#include "ImplObjC.h"
#import <Foundation/Foundation.h>


void P::f() {
  NSString* str = pimpl->UseObjC();
}

// main.cpp
#include "P.h"

int main() {
  P p;
  p.f();
  return 0;
}

Можно просто использовать forward declaration

Интересно было почитать в каментах как уважаемые мной присутствующие здесь программисты с "боями пробились" к тому очевидному факту, который я изложил сразу в первом же комментарии к статье: "проблемы с использованием Objective-C++ совместно с C++" не существует, равно как и не существует проблемы использования Objective-C++ с C и не существует проблемы использования Objective-C с С.