C ++ 게임 개발자가 부스트 라이브러리를 사용하지 않는 이유는 무엇입니까? [닫은]

따라서 C ++ 태그 아래 에서 스택 오버플로 에 대한 질문을 보거나 대답하는 데 시간을 투자하면 거의 모든 사람 이 부스트 라이브러리를 사용 한다는 것을 곧 알 수 있습니다. 어떤 사람들은 당신이 그것을 사용하지 않는다면 "실제"C ++를 쓰지 않는다고 말할 것입니다 (나는 동의하지 않지만 요점은 아닙니다).

그러나 C ++을 사용하고 부스트를 사용 하지 않는 게임 산업이 있습니다 . 왜 그런지 궁금해 할 수는 없습니다. 나는 취미로 게임 (지금)을 작성하기 때문에 부스트를 사용하지 않고, 그 취미의 일부는 내가 할 수 없을 때 기성품 라이브러리를 사용할 수있을 때 필요한 것을 구현하고 있습니다. 그러나 그것은 단지 나입니다.

게임 개발자가 일반적으로 부스트 라이브러리를 사용하지 않는 이유는 무엇입니까? 성능 또는 메모리 문제입니까? 스타일? 다른 것?

스택 오버플로에서이를 묻려고했지만 여기에서 질문이 더 잘된다고 생각했습니다.

편집하다 :

나는 모든 게임 프로그래머를위한 말할 수없는 내가 모든 게임 프로젝트를 보지 못했다, 그래서 게임 개발자는 말할 수 없다 실현 결코 부스트를 사용하지; 이것은 단순히 내 경험입니다.

내 질문을 편집하여 물어볼 수도 있습니다. 부스트를 사용하는 이유는 무엇입니까?

일부 개발자는 그렇지 않으며 일부 개발자는 그렇지 않습니다 (게임 및 다른 곳에서). 해당 개발자의 요구 / 요구 사항 및 기존 기술을 활용해야합니다.

C ++의 표준 라이브러리는 종종 같은 대우를 받고 사람들은 종종 당신이 그것에 대해 궁금해하는 것과 같은 것을 궁금해합니다 . 예를 들어, 대부분의 이유는 비슷합니다.

• 개발자는 표준 라이브러리 또는 Boost가 제공하는 것과 동일한 서비스를 제공하는 사내 기능 라이브러리를 이미 보유하고있을 수 있습니다. 이러한 사내 라이브러리는 표준 라이브러리의 구현 지원이 약했다 및 부스트는 기본적으로 존재하지 않는 때 자주, 오래 전에 쓴, 그래서 그들은 더 또는 덜 된 한 기록 될 수 있습니다. 이 시나리오에서는 일반적으로 사내 기능에서 전환 할 가치가 없습니다. 많은 코드를 불안정하게하고 거의 이점을 제공하지 않는 주요 이식 작업이 될 것입니다.

• 개발자는 Boost에서 사용하는 고급 C ++ 기술에 대한 컴파일러 지원이 제대로 지원되지 않는 플랫폼에서 작업 중일 수 있으므로 Boost 코드가 전혀 컴파일되지 않거나 성능이 저하됩니다. 요즘에는 훨씬 덜하지만 표준 라이브러리에도 적용됩니다.

• Boost와 언어의 표준 라이브러리는 일반적인 용도이며, 대부분의 응용 프로그램에는 적합하고 훌륭하지만 개발자는 더 특수한 컨테이너로 더 잘 해결할 수있는 특정 요구 사항이있을 수 있습니다.

나는 분명히 다른 이유가 있지만 위의 두 가지 이유가 있다고 생각합니다. 부스트, 표준 라이브러리 또는 "여기서 발명하지 않음"증후군으로 분류되는 여러 가지 이유를 피해야하는 많은 이유가 있기 때문에주의를 기울여야 합니다. 이는 실제 이유에 근거가없는 이유 일 수 있습니다.

또한 대형 스튜디오의 요구는 일반적으로 개별 개발자의 요구와 매우 다르다는 것을 기억하십시오. 예를 들어, 개별 개발자는 유지 관리를 위해 떠 다니는 레거시 코드가 적을 것이므로 자체 개발 한 Boost 버전 또는 표준 라이브러리 기능에서 이식하는 것은 시간이 걸리지 않으며 개발자가 유지 관리하지 않아도됩니다. 미래에 그 코드를 광범위하게 사용하여 첫 번째 글 머리 기호를 무효화합니다.

결국, 원하는 목표와 비교하여 요구 사항과 시간 투자를 평가하고 요구 사항에 가장 적합한 옵션을 결정하는 것입니다. Boost 또는 표준 라이브러리를 사용하지 않는 개발자는 일반적으로 그렇게하고 그 결론에 도달했습니다. 아마도 그렇지 않을 것입니다.

몇 년 후이 질문으로 돌아 오는 편집
점점 더 많은 부스트 ​​라이브러리를 계속 사용하면서이 설명을 업데이트하여 제품 설명이 원하는 기능과 일치 할 때 부스트를 사용해야하는 이유에 대한 확실한 사례를 제시 할 것이라고 생각했습니다. 이것은 심지어 혐오 자들에게 확신을 줄 것이다. openSSL을 다운로드하여 클라이언트 및 서버 응용 프로그램을 작성하십시오. 이제 모든 플랫폼에서 작동하도록하십시오. 그런 다음 boost :: asio :: ssl을 다운로드하여 사용하여 동일한 응용 프로그램을 만드십시오. 부스트가 깨끗하고 잘 최적화 된 동료 검토, 크로스 플랫폼 코드를 찾는 데 적합한 장소라고 확신하지 못하는 경우이 간단한 연습을 통해 변환 할 수 있습니다.

TL; dr 버전 :

제 생각에는 부스트를 사용하는 많은 인디 또는 중소 규모 개발 회사를 보지 못합니다. 왜냐하면 길들이기가 쉽지 않은 대규모의 강력한 야생 짐승이며 방법을 배우려고 할 때 기본적으로 혼자 있습니다. 그것을 사용하십시오. 문서가 몇 가지 방법으로 부족하고 (긴 버전 참조) 프로젝트 주변의 "커뮤니티"가 누락되었거나 흩어져 있거나 비활성 (다른 프로젝트와 비교) 인 것 같습니다.

Very Long Winded Version :

이미 받아 들여진 답변이 있다는 것을 알고 있지만 실제로 거의 모든 프로젝트에서 부스트를 사용하는 사람은 답변을 게시 할 것이라고 생각했습니다.

나는 처음에 부스트를 시작했을 때를 기억하며 솔직히 나는 무슨 일이 일어나고 있는지 전혀 알지 못했습니다. Boost는 전혀 잘 문서화되어 있지 않습니다. 사람들은 예제 코드와 주석 등의 스 니펫이 너무 많기 때문에 확실하지 않다고 생각할 수도 있지만 매우 춥고 모호하며 탐색하기가 어렵습니다.

또한 프로젝트 주변에서 "커뮤니티"를 찾은 것처럼 느껴지는 곳을 찾기가 어려워 보입니다. 사실 공동체는 존재하지 않거나 유목민처럼 보입니다. 불행히도 그들의 메일 링리스트조차도 많은 거머리 사이트에 의해 트롤되어 있어이 토끼 구멍을 내려갈 수 있습니다. 항상 시작한 곳으로 돌아갑니다.

이 두 가지 요소로 인해 부스트 라이브러리를 사용하는 법을 배우는 것은 어려운 작업입니다. 부스트를 사용하는 기술이 지나치게 복잡하지 않더라도 거대한 라이브러리 세트이며 무장 한 모든 코드 조각과 인터넷의 가장 어두운 구석에있는 메일 링리스트의 흩어져있는 조각입니다. ... 잘 생각합니다.

버전 1.45 주위에서 부스트를 겪었고 현재 버전 1.52 / 1.53에서만 프로덕션 환경에서 사용하기에 충분히 편안합니다. 라이브러리를 구축하고 기능을 구성하는 방법과 같은 간단한 것들조차도 라이브러리를 구축하고 기능을 구현하는 방법은 사용자 정의 가능한 방식으로 인해 컴파일 타임에 환경 설정에 따라 크게 다를 수 있기 때문에 익숙하고 기억해야 할 것들이 너무 많습니다. 아르.

그러나 , 실수를하지 않습니다 당신이 부스트를 지배 할 수있게되면, 당신은 빠른 속도로 고체, 크로스 플랫폼 프로그램을 구축하기위한 강력한 무기를 획득했습니다. 그냥 가지고 boost::asio예를 들어. 단 몇 백 줄만으로도 강력하고 확장 가능하며 견고한 크로스 플랫폼 비동기식 웹 서버를 작성할 수 있습니다. 몇 년 동안 여러 클라이언트, 서버, 프록시 등을 작성했지만 아직 실패하지 않은 코드는 수백 줄에 불과하며 몇 분 안에 플랫폼에서 플랫폼으로 이식 할 수 있습니다.

다른 사람들이 지적했듯이 대기업은 일반적으로 레거시 물건에 갇혀 있거나 내가 완전히 이해하는 자신의 롤을 좋아합니다. 또한 개발자 리드 및 / 또는 프로젝트 관리자가 부스트 사용이 "너무 커서"금지 된 곳에서 내가들은 적이 있고 어리석은 일도 있습니다. 내 생각에 그들은 부스트가 하나의 단일 라이브러리라고 생각하거나 BCP에 대해 들어 본 적이 없다고 생각합니다 .

왜 부스트를 사용하기로 선택했는지

나는 당신이 당신의 질문에 암시하는 것처럼 "the"C ++ 라이브러리이기 때문에 그것을 사용한다고 말하고 싶습니다. Boost는 C ++ 세계에서 결국 사용해야 할 스위스 군용 칼로 간주됩니다. 따라서 아이디어가 필요한 경우 성능이 뛰어나고 휴대 성이 뛰어난 버전이 필요합니다. 대기업은 향상에 기여하고 , 인상적인 이력서를 가진 고도로 교육받은 사람들이 기여하고 유지하며 , 새로운 C ++ 표준이 개발 될 때 사람들은 일반적으로 ISO 표준 C ++가 될 부분을 부스트하려고합니다.

따라서 기존 라이브러리가있을 수있는 기능을 추가 해야하는 경우 가장 잘 보이며, 휴대용이며, 지원되고 유지 관리된다는 점에서 매우 안전하기 때문에 처음으로 살펴볼 부분은 부스트입니다. 매우 긴 시간과 버그가 발견되고 처리 될 것입니다. 오픈 소스 세계에서는 이러한 자질을 얻기가 매우 어려울 수 있습니다.

우리는 예전 직장에서 약간의 부스트를 사용했습니다. 주로 피하고 사용을 제한하는 주된 이유는 다음과 같습니다.

• 컴파일 시간-일부는 컴파일 속도가 느리고 결국 헤더에 #include가 포함되는 것을 꺼려합니다.
• 복잡성-대부분의 게임 개발자에게 잘 알려져 있지 않으므로 읽을 수없는 코드를 만듭니다.
• 성능-일부 개념은 기본적으로 느리게 수행됩니다 (예 : shared_ptr

"더 표준적인"STL에 대해서도 같은 말이 있었다. 이 기사에서는 Electronic Arts의 STL (일부)을 내부적으로 재 작성하여 "보다 일반적인"응용 프로그램 개발과는 다른 게임 개발 요구를 수용하는 EASTL에 대해 설명합니다.

따라서 어딘가에 누군가가 게임 개발에 대한 요구를 수용하기 위해 다시 쓰기 (일부)를 향상시키고 있습니다!

누가 부스트를 사용하지 않는다고 말합니까? 부스트를 사용하는 하나 또는 두 개의 C ++ 엔진을 알고 있습니다. 나는 그들과 직접 협력 한 적이 없다. 그러나 그것은 주로 내 경험이 언리얼에 있기 때문입니다.

부스트를 사용하지 않은 이유는 다음과 같습니다.

• 우리는 배포 할 플랫폼에 고유 한 데이터 구조를 롤링하는 것을 좋아합니다.
• 우리는 외부 코드가 외부에서 개발 된 다른 라이브러리에 의존 할 때 프로젝트에서 사용해야하는 비 내부적으로 개발 된 코드의 양을 제한하는 것을 좋아합니다.

일반적인 해결책은 항상 "적합한 것은 아니다".

실제로 도서관에서 일한 사람이 더 잘 주석을 달 수 있다고 확신합니다.

StackOverflow에서 놀고 부스트를 사용하지 않습니다. 아직 언급되지 않은 이유를 추가하겠습니다.

부스트에는 정말 많은 훌륭한 아이디어가 있습니다. 나는 그들이 한 일을보고 새로운 일과 아이디어를 시도하는 것을 좋아합니다. 많은 C ++ 개선을위한 번식지이기 때문에 훌륭합니다.

그러나 부스트는 여러 가지 이유로 매우 다루기 힘든 짐승입니다. 그 이유 중 하나는 거의 모든 컴파일러가 거의 모든 컴파일러에서 호환되기를 원하기 때문입니다. 결과적으로 MPL과 같은 많은 트릭을 사용해야합니다. 예를 들어 (오래 전에) 나는 shared_ptr을 사용하고 싶었습니다. 나는 내 자신의 글을 썼다. 읽을 수있는 50 줄의 코드. (약한 _ptr이나 스레드 안전성이없는 것처럼 더 엄격한 요구 사항)

종종 약간의 부스트가 필요하지만 부스트 전체를 통합하는 것은 번거로운 일이 아닙니다.

편집 :

명확하게 나오지 않은 것처럼 보이기 때문에 분명하다. 내가 사용 않는 타사 라이브러리를 사용합니다. 그러나 대부분의 경우 모든 것이 평등하여 타사 라이브러리 또는 부스트를 통합하면 다른 타사 라이브러리가 더 빠르고 깨끗합니다. 나머지는 "2h"손가락 운동에서 수행됩니다. 빌드를 매우 열심히 보거나 질문을합니다.

우리의 경우 (게임이 아닌), 우리는 부스트 (또는 표준)를 사용하지 않는 좋은 이유가 있습니다. 우리는 10 년 전의 많은 코드를 가지고 있습니다. 노인들에 따르면 std와 boost는 불완전하거나 버그로 가득 차 있거나 우리가 요구하는 고성능을 위해 너무 느리다고합니다. 따라서 일부 기본 클래스는 동일한 개념 (예 : 반복자)을 사용하여 구현되었으며 종종 알고리즘에 최적화되었습니다. 오늘날 세 라이브러리 (우리, 표준 및 부스트)는 모두 매우 유사합니다.

그러나 모든 코드를 이식하고 싶습니까? 실제로는 아닙니다. 다른 많은 회사들도 같은 딜레마에 직면한다고 가정합니다. 테스트되고 작동하는 많은 코드를 다시 작성하거나 std / boost를 사용하지 마십시오.

게임은 일반적으로 범용 적이 지 않기 때문에 게임을 만들 때 개인적으로 부스트 또는 기타 범용 코드를 사용하지 않습니다. 게임을 구현하는 데 필요한 코드 종류는 대개 게임 개발에 따라 다르지만 항상 98 % (무작위 수치)와는 다릅니다. 부스트 또는 다른 lib에서 마지막 몇 비트 코드를 사용할 수는 있지만 여기 저기에 필요한 작은 부분을 작성하는 것이 좋습니다.

참고로, 나는 자신의 코드를 C ++로 작성하는 것이 오히려 재미 있다고 생각한다.

사내 라이브러리의 유산은 요인이 아닙니다 ... 다른 범용 라이브러리에서 부스트를 사용해서는 안되는 주된 이유는 속도와 메모리가 최적화되어 있지 않기 때문입니다. STLPort라는 오픈 소스 버전을 비방하므로 STL 사용을 두려워하지 말고 사용자 지정 할당자를 구현하면 괜찮습니다. 부스트를 사용하지 마십시오.