我终于有一个非常基本版本的图形搜索器通过CLI工作，但我发现自己处于需要重构所有代码的位置。因为我在mac上进行这个编程，所以我在考虑使用Cocoa作为GUI，然后将我的C ++函数作为workhorses使用。这只是一个临时修复，因为最终我希望能够在linux盒/集群上运行我的所有代码。 Here是我关于实现的最后一个问题，我确实让它在boost中工作，滚动我自己的图形函数（现在）。
所以这就是我的想法：为图表本身构建C ++类，并为我想要计算的数量单独设置函数或方法。 This是我能找到的最新描述，它涉及混合Objective-C和C ++。但我想知道：
是否会优化在Xcode中编译我的C ++代码？重点是我希望C ++代码能够针对快速内存访问，多线程进行全面优化，并且可以访问boost库。然后，我可以将C ++类封装在一个包装ObjectiveC类中。要做到这一点，我基本上有2个类，对吗？ C ++类包含.h和.cpp文件并包含boost库，然后是带有.h和.mm文件的ObjC类包装器，其中.h不包含对C ++类的任何引用，我使用include in .mm文件。然后我可以使用我正常的MVC设计和Objective C的GUI实现。只要我给dealloc命令提供核心C ++类的能力，我不必担心内存管理？ ARC是否也适用于C ++，它是否能让OSX能够内存管理和清理我的C ++代码？
我怀疑如果我想要线程化，我会选择增强线程，因为GCD的编码会使它特定于平台（尽管现在，它只会运行）。我认为现在，我将远离核心数据，因为我只是通过解析文本文件来创建我的图形。
答案 0 :(得分：5)
是否会优化在Xcode中编译我的C ++代码？
编译代码不是Xcode，而是编译器（GCC或clang），如果您使用适当的编译器标志请求它，它将优化您的代码。我不知道混合使用C ++和Objective-C会使编译器不能优化...
只要我给dealloc命令提供核心C ++类的能力，我就不用担心内存管理了吗？
具体？您仍然必须正常管理C ++和Objective-C对象的内存。
ARC也适用于C ++吗？
不，它没有，这是一个Objective-C功能。 C ++甚至没有引用计数（我希望它有......）。
答案 1 :(得分：1)
我同意H2CO3所说的一切（除了关于引用计数的挑剔）。
还想注意Daniel Sefton created a nice article on how to compile Boost的OSX和iOS：
另外，是的，-dealloc是删除C ++对象的好地方。
<强>线程：
线程的其他选项是：
我个人使用Poco。
答案 2 :(得分：1)
是否会优化在Xcode中编译我的C ++代码？
是
要做到这一点，我基本上会有2个班，对吗？ C ++类包含.h和.cpp文件并包含boost库，然后是带有.h和.mm文件的ObjC类包装器，其中.h不包含对C ++类的任何引用，我使用include in .mm文件。
正确。
只要我给dealloc命令提供核心C ++类的能力，我就不用担心内存管理了吗？
是的，你的C ++对象＆＃39;当您声明C ++ ivar时，将在ObjC对象的生命周期中的适当位置调用默认构造函数和析构函数。
与普通的C ++一样，您只需使用值或智能指针而不是C ++ ivars的原始指针，并对该对象的生命周期进行一些额外的干预。如果ARC被打乱，编译器将不会对您的C ++类型应用ObjC引用计数（毕竟，C ++对象不是严格引用计数）。
ARC是否也适用于C ++，它是否能让OSX能够内存管理和清理我的C ++代码？
ARC仅适用于ObjC类型。它对C ++甚至C类型/分配都没有任何作用。只需使用智能指针或一些适当的C ++替代品（即std::vector）作为C ++和C分配/类型。如果您发现自己需要经常在C ++中编写delete，delete[]或free，那么您并没有正确使用智能指针 - 它们几乎就像ARC一样简单，只是提供更多的灵活性
您可能还想查看CLANG_WARN_OBJCPP_ARC_ABI。
ARC的另一个不同之处在于，当一个程序被编译为ObjC ++时，本地强ObjC引用在从抛出异常中展开时将是-release d（不是编译为ObjC + ARC时的情况）。