게임 개발자가 C / C ++를 선호하는 이유는 무엇입니까?


14

어떤 사람들은 개발자에게 더 많은 제어를 제공한다고 말하지만 Java와 같이 제어 할 수없는 C ++을 통해 정확하게 제어 할 수있는 것은 무엇입니까?

답변:


21

Java는 가상 머신에서 실행되는 반면 C ++은 하드웨어에서 직접 실행됩니다. 이것이 의미하는 바는 메모리가 어디로 가고 C ++에서 메모리로 무엇을하는지 더 잘 제어 할 수 있다는 것입니다.

Java는 가비지 수집 언어입니다. 메모리를 직접 제어 할 수 없습니다. 새로운 메모리 청크를 할당 할 수 있지만 삭제 시점을 (미세) 제어 할 수는 없습니다. 가비지 수집기는 매 x 프레임마다 할당 한 모든 메모리 조각을 확인하여 가비지인지 여전히 사용 중인지 확인합니다.

게임의 경우 이것은 비참 할 수 있습니다. 가비지 컬렉터가 몇 프레임마다 나올 때마다 사용중인 모든 할당 을 확인 하여 여전히 사용되고 있는지 확인하십시오. 속도 저하에 대해 이야기하십시오!

둘째, 우리가 사용하는 대부분의 라이브러리는 C로 작성되었거나 C ++로 작성되었습니다. 나는 Scaleform, Havok 물리 엔진, PhysX, SpeedTree 등에 대해 이야기하고 있습니다. 모든 전문 패키지는 업계에서 광범위하게 사용됩니다. 다른 언어가 왕이되고 싶다면 언어를 더 잘 지원하십시오.

내 개인적인 견해는 Java가 데스크톱 응용 프로그램 및 응용 프로그램에는 좋지만 게임에는 좋지 않다는 것입니다. Java에는 개발자를위한 멋진 도구가 많이 있으며 이론적으로 Java Virtual Machine이 구현 된 모든 플랫폼에서 실행될 수 있지만 메모리에 대한 제어 가 필요 하기 때문에 여전히 C ++을 선호 합니다. 특히 이국적인 데이터 구조 (빨간색 검은 색 트리, 이중 연결 목록 등)로 작업을 시작할 때 모든 메모리 할당에 대한 개요를 잘 유지하는 데 도움이됩니다.

나는 말하지 않습니다 : Java를 사용하지 마십시오. 나는 말하고 있습니다 : 왜 당신이 Java를 사용하고 있는지 생각하십시오. Minecraft는 Java로 제작되었으므로 Java로 게임을 제작할 수 있습니다. 그러나 그것이 더 좋은 게임 이었을까요? C ++로 제작 되었습니까? 글쎄, 그것은 큰 세 가지 (Windows, MacOS, Linux)에서 실행하는 것이 너무 저렴하지는 않았지만 개발에도 많은 플랫폼 관련 버그, Java가 부드럽게 할 수없는 버그가 발생했습니다. 위에.

프로그래머를위한 수많은 C ++ 프레임 워크가 있습니다. 특히 업계에서 경력을 쌓고 싶을 때 배우지 말아야 할 변명의 여지가 없습니다.


1
단순한 선택이지만 대부분의 운영 환경에서 기본 코드는 가상 머신에서 실행됩니다. Java는 가상 머신 내부의 가상 머신에서 실행됩니다.
Skyler Saleh

1
@ RTS : 그것은 당신이 얻는 것이라면 op-> micro-op translation을 가상 머신이라고 부르는 약간의 스트레칭입니다.

아니요, 안전한 멀티 태스킹을 위해 모든 운영 체제에서 모든 응용 프로그램을 사용하는 가상 시스템에 대해 이야기했습니다. 이는 micro-ops (RISC)가없는 아키텍처에서 실행되는 OS에서 발생합니다. 여기에는 가상 메모리, 소프트웨어 인터럽트, 동시 하드웨어 액세스 시스템, 운영 체제 스케줄러 및 레지스터 파일 처리가 포함됩니다.
Skyler Saleh

@RTS 작업 격리가 실제로 VM의 자격을 갖추고 있는지 확실하지 않습니다. 일부 보호 기능이 내장 된 RM (Real Machine)입니다. 페치 / 실행 사이에는 명확한 명령어 추상화 계층이 없습니다. 컴파일러와 링커는 필요에 따라 재배치 가능 코드를 생성합니다. CPU는이 부분에 대한 하드웨어 지원을 제공하여 "가상"측면을 제거합니다.
3Dave

2

짧은 대답 : C ++는 네이티브 코드로 컴파일되므로 런타임 또는 VM이 ​​아닌 개발자의 성능에 달려 있습니다.

긴 대답 :

"빠른"C ++는 C ++과 아무 관련이 없습니다. 현재 여러 플랫폼에 대한 독립형 기본 코드를 생성하는 도구가 지원하는 언어는 거의 없습니다.

과거에는 C, C ++, BASIC / 2, Delphi 등을 사용하여 효율적이고 독립적 인 실행 파일을 얻을 수있었습니다. 언어 선택은 개인적 취향과 시장력의 문제였습니다.

요즘 "C ++가 더 빠르다"는 가정은 본질적으로 자체 이행 예언이지만, LLVM은 파서 무언에 들어가는 모든 것을 이전과 같이 바꾸는 데 좋은 위치에 있습니다.

Borland는 다음과 같이 옳았습니다. 여러 언어가 구문 분석되고, 먼저 최적화가 적용된 다음, 공통 백엔드 컴파일러 및 링커로 전달되었습니다. 효과적으로 LLVM의 주요 성과 중 하나입니다.

Java는 JVM없이 구현하기가 매우 어려운 방식으로 구성됩니다. 이상하게도 C #은 일반적으로 Java와 거의 동일하다고 가정하고 이미 iOS를 포함한 여러 플랫폼에서 네이티브 코드로 컴파일됩니다.

내 크리스마스 목록의 상단? 돌아가서 속성, 실제 예외 처리 및 실제 작업 다형성을 C ++에 추가하고 파서가 스스로 알아낼 수있는 "위쪽 화살표 구문 쓰레기를 제거하는 타임머신. 나는 그 10 년 동안 전처리기를 썼다. 멍청하기 때문에


간접 회원 액세스를 의미합니까 (h-> x에서와 같이)? 제거하면 핸들과 스마트 포인터 유형이 덜 유용합니다. 원시 포인터로만 변경한다고 주장하면 언어의 일관성이 떨어집니다.
Lars Viklund

1
C ++의 다형성에서 작동하지 않는 것은 무엇입니까?
Casey

@LarsViklund 그래, 그게 내 뜻이야. 그러나 주소, 역 참조 및 멤버 연산자 (&, *, ::,-> ...)는 모두 다른 의미를 갖지만 대부분의 경우 컨텍스트에서 drsjted 결과를 유추 할 수 있습니다. 다른 언어에서와 마찬가지로 상황을 미리 단순화했을 수 있습니다. 사소한 문제이지만 코드 복잡성을 증가시켜 시간과 비용이 많이들 수 있습니다.
3Dave
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.