C#과 C++ (또는 관리되는 언어와 관리되지 않는 언어) 사이의 통신은 엉덩이의 통증이며 사용하지 않는 것이 좋은 이유가없는 한 피해야합니다.
통신의 경우 파이프, WCF, COM, P/Invoke 및 기타 사용자 정의 상업 옵션을 사용할 수 있습니다. 그물을 검색 할 수 있습니다. 우리가 작업 한 엔진에서 우리는 익명의 MemoryStream을 여러 프로세스에서 공유합니다.
하지만 항상 문제가되는 것은 C++의 모든 구조적 변경에 대해 C#에 반영해야한다는 것입니다. param을 변경하는 경우처럼 메소드가 취하거나 struct의 정의를 취합니다. 자동으로 C#을 C++로 항상 최신 상태로 유지할 수있는 솔루션이 있지만 비용이 많이 들고 구현하기가 무거워요.
이제 왜 신경 써야하지 않습니까? 사실, 당신은 C++이 아닌 다른 곳에서 하이 엔드 상용 엔진을 발견하지 못할 것입니다. 언리얼? C++. 출처? C++. 크라이시스? C++. C++은 관리되는 언어에서 제공 할 수없는 성능을 제공하기 때문에. 또한 객체를 생성하고 지우는 방법에 대한 메모리 및 마이크로 제어를 직접 제어 할 수 있습니다.
왜 신경 쓰지 않아야하나요? Assassin 's Creed, Half-Life 또는 Skyrim의 크기 나 범위를 트리플 A 게임에 제공하려는 계획이 없으면 XNA Framework에서 C#을 사용하면 많은 공간과 성능이 제공됩니다. 당신이 필요로하는 것보다 훨씬 더. 실제로 성능 문제가있는 경우 관리 언어가 문제가되지 않을 가능성이 높으며 수행 할 코드에 여전히 많은 최적화가 있어야합니다. 기회가 C#에서 성능 문제가 있다면, 당신도 C + +에서 그들을 것입니다.
또한 XNA는 Windows, Xbox 및 다른 Microsoft 휴대용 장치에서 출하 할 수있는 기능을 제공합니다. 게다가 DirectX를 사용하면 어쨌든 해당 플랫폼으로 제한됩니다.
[COM 개체] (http://www.csharphelp.com/2006/08/building-com-objects-in-c/)를 찾으십니까? –
엔진이 C++로되어 있어야하는 이유를 알려주십시오.일반 C++은 .NET Framework의 일부가 아닙니다. 관리되는 C++을 참조하면 C#과 동일하지만 C++ 구문을 사용합니다. – LightStriker
편집기에서 게임 엔진에 직접 객체를 전달할 필요는 없다고 생각합니다. 대신 편집기에서 만든 객체를 파일에 저장 한 다음 C++ 코드에서 객체를 읽을 수 있어야합니다. 이를 위해서는 JSON 또는 XML이 유용해야합니다. – piokuc