Godot: Godot에서 C++의 상태

이것은 여러 번 논의되었으며 일반적인 답변은 다음과 같습니다.

1) 코드베이스를 03 이상으로 옮기고 싶지 않습니다. 기능이 가치가 없습니다. GDNative C++의 경우 완벽하게 사용할 수 있습니다.
2) STL/Boost/Etc 사용 의향 없음. 이론적 근거는 항상 동일했습니다: a) Godot 템플릿은 평소 하지 않는 작은 일을 합니다(즉, 원자적 참조 횟수 및 쓰기 시 복사) b) STL은 매우 긴 맹글링된 기호로 인해 거대한 디버그 기호와 디버그 바이너리를 생성합니다.

우리는 모든 것과 같은 방식을 유지합니다.

사적인 대화에 대한 의견이 좀 있었지만
토론 더 공개.

이미 그렇게 많이 논의되고 닫혀 있는지 몰랐습니다.

auto, constexpr 등도 버리나요?

'등록'을 삭제하시겠습니까?

엘 7월 18일 2017년 오후 1시 54분, "후안 리니에츠키" 알림 @github.com
기록:

이것은 여러 번 논의되었으며 일반적인 답변은 다음과 같습니다.

1. 코드베이스를 03 이상으로 옮기고 싶지 않습니다. 기능은 다음과 같습니다.
   그럴 가치가 없어. GDNative C++의 경우 완벽하게 사용할 수 있습니다.
2. STL/Boost/Etc를 사용하고 싶지 않습니다. 근거는 항상
   동일: a) Godot 템플릿은 일반적으로 하지 않는 작은 일을 합니다(즉, 원자
   refcounts 및 copy on write) b) STL은 거대한 디버그 기호를 생성하고 디버그합니다.
   매우 긴 맹글링된 기호로 인한 바이너리

우리는 모든 것과 같은 방식을 유지합니다.

—
스레드를 작성했기 때문에 이 메시지를 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/9694#issuecomment-316041201 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ALQCtipKmepD_1Xw6iRXZ7aGoQlLfiwFks5sPJzqgaJpZM4ObOio
.

스마트 포인터를 사용하는 것이 더 안전하고 이 코드가 NIH 증후군을 앓고 있다고 이 문제를 제기했지만 상위는 업그레이드할 생각이 없으므로 포기하는 것이 좋습니다.

개발자가 새로운 기능을 구현하는 데 투자하는 것을 선호하는 코드를 업그레이드하는 데는 많은 시간이 소요될 것입니다. 나는 어떻게 든 이것을 이해합니다. 엔진 사용자는 "리팩토링"(기술 부채와 같은 것을 이해하지 않고)보다 새로운 기능을 선호합니다.

@Marqin 죄송하지만 스마트 포인터는 다음과 같은 이유로 나쁜 생각입니다.

1) 유일하게 유용한 것은 언급된 것이고, 나머지는 언어에 이미 존재하는 기능에 대한 정신적 자위입니다.
2) 모든 곳에서 스마트 포인터를 사용하는 것은 끔찍한 생각입니다. 메모리 누수를 일으키는 참조 주기가 발생할 위험이 있습니다.
3) 우리는 이미 유사한 Ref<>를 가지고 있으며 참조 카운팅의 작동 방식을 제어할 수 있다는 이점이 있으므로 C#과 같은 언어에 대한 바인딩을 처리하기 위해 고유한 gc

그러니 우리가 변덕스럽게 결정한다고 주장하기 전에 먼저 물어보세요. 우리는 일반적으로 정보에 입각한 결정을 내리고 프로세스를 모든 사람과 공유합니다.

품질을 향상시키고 싶다면 쉽게 할 수 있는 것은 단위 테스트 작성을 시작하는 것입니다.

나머지는 언어에 이미 존재하는 기능에 대한 정신적 자위입니다.

@reduz , 명시적 소유권과 언어에 이미 존재하는 RAII 메모리 해제가 있는 unique_ptr은 어떻습니까?

또한 메모리 관리뿐만 아니라 스레딩도 쉬워집니다(예: lock_guard ).

@RandomShaper 저는 미래의 어느 시점에서 업그레이드하는 것을 반대하지 않습니다. 그러나 많은 유용한 기능이 있음에도 불구하고 최신 C++ 버전은 프로그래머가 덜 명시적인 코드를 작성하게 만드는 경향이 있습니다. 그 결과 일반적으로 다른 사람이 코드를 읽기가 더 어려워집니다(일반적으로 auto 키워드 남용).

고급 기능을 사용하지 않는 다른 이점(예: 예외를 사용하지 않고 rtti를 약간의 비용으로 비활성화할 수 있음)은 컴파일러가 훨씬 더 작은 바이너리를 생성한다는 것입니다.

괜찮아. 나는 당신의 말을 존중합니다. 나는 이것에 대해 토론하는 것이 건강한 일이라는 것을 알게 되었습니다.

나는 몇몇 큰 비디오 게임 회사(Ubisoft, IIRC)가 큰 코드 기반을 현대적인 C++로 마이그레이션했다는 것을 알고 있습니다. 그래서 이것은 Godot에도 완벽하게 적합해야 합니다. 물론 지적했듯이 작업/시간이 필요합니다.

이것이 우리가 할 수 있는 이유:

• 가능한 모든 코드 마이그레이션을 위해 합리적인 하위 집합을 선택하십시오.
• 또는 최소한 새 코드에 대해 "승인됨"으로 합리적인 하위 집합을 선택하십시오.

두 경우 모두 auto 발생하는 것처럼 기능을 남용하지 않도록 코딩 스타일을 정의해야 합니다.

물론 지금은 우선순위가 더 높은 것도 있지만, 3.0이 안정화되거나 미래의 다른 시점이 되면 이미 결정하는 것이 좋을 것입니다.

@Marqin 언급했듯이 Godot는 노드에 대해 자체 메모리 할당 방식을 사용합니다. 이는 새로운 표준 라이브러리에서 제공하는 것보다 더 합리적입니다.

또한 잠금 가드는 사실상 3줄의 코드이며 우리는 이미 C++11+를 사용하지 않고 구현했습니다.

다시 말하지만, "표준" 1) 어떤 것이든 우리가 이미 가지고 있는 것보다 더 좋아야 하고 2) 어쨌든 사용한다면 더 낫다고 가정해야 하는 이유는 무엇입니까? .내 생각에 그것은 흔한 헛소리라고 생각합니다.

다음은 인쇄 기능을 삭제하고 ostream/istream을 사용하는 것입니다. 꽤 멋진 String 클래스를 변경하고 훨씬 더 마비된 std::string 또는 std::wstring으로 교체하시겠습니까?

표준 라이브러리는 모든 용도를 제공하지 않으며 표준 라이브러리이기 때문에 다른 모든 것보다 더 잘 작동하지 않습니다. 그것들은 그것들을 필요로 하는 사람들을 위해 존재하며, 타당한 이유가 있다면 무시하고 자신만의 구현을 작성하는 것이 좋습니다. 우리는 이에 대해 확신하고 있습니다.

@RandomShaper 문제는 다음과 같습니다.

1) 이익보다 비용이 더 많이 든다.
2) C++11+를 작성하는 표준 방법에 대한 많은 인수에 대한 창을 엽니다. 언젠가는 그것들을 가질 가치가 있을 수 있고 이러한 기능을 활용하기 위해 엔진의 많은 부분을 다시 작성하는 것이 언젠가는 유용할 수 있지만 집중해야 할 훨씬 더 중요한 것들이 있다고 생각합니다.
3) 또한 이전에 언급했듯이 새로운 C++ 버전으로 포팅하는 것만큼 멋진 소리가 날 수 있지만 이로 인해 바이너리 크기가 훨씬 커질 수 있습니다. 이러한 경우 바람직하지 않을 수 있습니다.

현재로서는 심각하게 가치가 없습니다. 몇 년 후에 다시 논의할 수 있습니다.

내가 생각하는 것이 합리적이라고 생각하는 것은 Godot가 --std=c++17과 같은 옵션으로 컴파일되도록 하는 것입니다. 그래서 필요하다면 현대 C++로 작성된 라이브러리를 쉽게 가져올 수 있습니다. 예를 들어, https://github.com/godotengine/godot/issues/9691 코드베이스에서 register 키워드 제거에 투표하겠습니다.

어떻게 든 관련이 있지만 gcc-6.3이 지원되지 않는다는 글을 읽은 기억이 있습니다(google
https://github.com/godotengine/godot/issues/7703에 있다고 말합니다. gcc-6.3이 내 배포판(debian stable)의 기본 컴파일러이기 때문에 귀찮습니다. 아무도 그것을 확인할 수 있습니까? 왜 그런데?

@efornara 일부 타사 라이브러리에는 이미 최신 C++ 버전이 필요하며 Scons가 복제된 빌드 환경에서 이를 처리하기 때문에 괜찮습니다. 어떻게 작동하는지 보려면 etc2comp thridparty 코드를 확인하십시오.

@karroffel 감사합니다, 나는 그것을 몰랐습니다.

그러면 좋은 기능이 될 수 있지만 라이브러리를 가져오는 데는 필요하지 않습니다.

그건 그렇고, 누군가 비슷한 작업을 수행해야 하고 이 게시물을 찾은 경우 관련 파일은 https://github.com/godotengine/godot/blob/master/modules/etc/SCsub 입니다. grep을 사용하여 찾았으며 현재 이것이 필요한 유일한 장소인 것 같습니다.

C++11을 C++11이 아닌 코드와 연결하는 것은 안전하지 않습니다. - http://gcc.gnu.org/wiki/Cxx11AbiCompatibility

@Marqin 링크를 잘못 이해하지 않는 한 이것은 실제로 Godot가 표준 라이브러리의 구성 요소를 사용하기 시작하지만 대신 사용자 정의 구성 요소를 사용하는 경우를 지원하는 것 같습니다.

C++98 언어는 C++11 언어와 ABI 호환되지만 표준 라이브러리의 여러 위치에서 호환성이 중단됩니다.

언어를 혼합하는 것은 상당히 안전해 보이지만(나도 인정하고 앞으로 작동하지 않을 수도 있음) 쌍, 벡터, 목록 등과 같은 것을 혼합하는 것은 문제를 일으키는 것으로 알려져 있습니다.

@efornara 이 링크는 C++11을 사용하는 일부 타사 라이브러리를 C++03을 사용하는 Godot와 연결하는 것입니다.

@Marqin 예, 하지만 링크를 이해하는 방식은 할 수 있다는 것입니다. 예를 들어 여러분이 할 수 없는 것은 std::list<>를 Godot에서 타사 라이브러리로 전달하는 것입니다.

@reduz Godot의 내부 Ref<> 문서는 어디에서 찾을 수 있나요? Godot 내부 컨테이너가 STL의 컨테이너와 어떻게 다른지에 대한 문서는 어디에서 찾을 수 있나요?

@Marqin 컨테이너의 경우 많지 않습니다.
http://docs.godotengine.org/en/stable/development/cpp/core_types.html#containers
Ref<>의 경우에는 없다는 것을 깨달았습니다. 아마 추가되어야 할 것입니다.
이러한 것들을 추가하기 위해 문서를 개선하는 방법에 대한 제안은 매우 환영합니다.

개인적으로 나는 새로운 C++ 표준이 아주 훌륭하다고 생각하지만, 너무 적은 이득을 위해 너무 많은 노력이 필요할 것이기 때문에 Godot 내부 리팩토링을 제안하지 않을 것입니다.

또한 이전 버전과의 호환성 중 하나는 바로 이러한 이유로 C++의 특징 중 하나입니다. 하지만 여전히 새로운 Godot 기능과 GDNative에 사용할 수 있기를 바랍니다.
저는 이러한 이유로 Godot가 최신 C++ 지원으로 컴파일되는 것을 선호합니다.

@reduz C++11/14/17을 사용하면 덜 명시적인 코드를 작성할 수 있습니다. 힘든 일이지만 C++ 초보자에게는 단점이지만 C++ 고급 사용자에게는 좋은 점입니다.
"자동"에 관해서는 개인적으로 고급 사용자에게도 좋다고 생각합니다. 꼭 필요하지 않은 경우에도 유형을 계속해서 입력하는 것을 피할 수 있을 뿐만 아니라 일부 버그를 입력하는 것도 피할 수 있습니다.

참고로 저는 최근 마스터(godot3)를 다음과 같이 컴파일했습니다.

scons platform=x11 target=debug tools=yes builtin_openssl=true CCFLAGS=-std=c++17

데비안 스트레치(gcc-6.3)에서. 성가시게도 이 옵션은 C 파일을 컴파일할 때도 설정되므로 활성화하면 경고가 쏟아지지만 그 외에는 모두 순조롭게 진행되었습니다. register 키워드조차도 문제를 일으키지 않는 것 같습니다.

공식 빌드가 이런 식으로 컴파일되도록 제안하는 것까지는 아니지만 프로젝트에 필요한 경우 옵션이 있다는 것을 아는 것이 좋습니다. 내가 제안하고 싶은 것은 이것을 깨는 모든 변경 사항은 회귀로 취급된다는 것입니다.

편집: 일부 오타를 수정하여 경고에 대한 설명을 더 명확하게 했습니다.

귀찮게도 C 파일을 컴파일할 때도 옵션이 설정됩니다.

CPPFLAGS 으로 시도하셨습니까?

@Hinsbart 아니요,하지 않았습니다. 방법이 있을지도 모르지만 저는 scons를 잘 모르기 때문에 땜질없이 가능하다고 생각한대로갔습니다.

$ scons platform=x11 builtin_openssl=true -h | grep FLAGS
CCFLAGS: Custom flags for the C and C++ compilers
CFLAGS: Custom flags for the C compiler
LINKFLAGS: Custom flags for the linker

편집: 그건 그렇고, 나는 그것이 Godot 빌드 시스템에서 어떻게 사용되는지 모르지만 CPPFLAGS 는 전처리기 옵션을 생각하게 만들 것입니다. 개인적으로 저는 항상 C++에 CXXFLAGS 를 사용해 왔습니다.

CPPFLAGS를 사용해 보셨습니까?

CPPFLAGS 는 전처리기를 사용하는 모든 언어에 영향을 미치므로 C와 C++가 모두 포함됩니다.

@m4nu3lf GDNative 에서 원하는 C++ 형식을 사용할 수 있습니다.

내 경험상 코드를 삭제할 수 있는 모든 기회가 좋은 기회입니다.

아마도 우리는 어떤 파일이 삭제되고 C++11 변종으로 대체될 수 있는지 문서화하는 일종의 위키 페이지를 설정할 수 있을 것입니다. 여기에는 스레딩 프리미티브 등이 포함될 수 있습니다.

변경을 위한 변경은 좋지 않습니다 (속담 koolaid). 그러나 이 경우 LLVM 프로젝트 및 기타 많은 FOSS 프로젝트는 보다 명확한 구문 패턴, 즉 새로운 for-iterator 표기법을 선호하는 방향으로 나아갔습니다. (솔직히 말해서) 가능한 한 적은 플랫폼 특정 코드를 유지하는 것이 게임 엔진에 이상적이기 때문에 문제의 분리를 각 언어 런타임에 오프로딩합니다.

당신이 작성하게 될 최고의 코드는 당신이 쓰지 않은 코드입니다. :)

호기심으로 인해 이전 C++ 및 최신 C++로 컴파일되는 코드를 작성할 수 있습니까? C++ 버전 간에 중요한 주요 변경 사항이 있습니까?

호기심으로 인해 이전 C++ 및 최신 C++로 컴파일되는 코드를 작성할 수 있습니까? C++ 버전 간에 중요한 주요 변경 사항이 있습니까?

최신 C++는 99.99...%의 경우에서 이전 C++와 역호환됩니다. .

그러나 최신 C++에는 중요한 기능이 있으며 이전 C++ 버전에서는 분명히 작동하지 않으며 이러한 기능은 가변 매크로 및 auto 및 람다와 같은 사용성 기능뿐만 아니라 move 와 같은 효율성 기능도 있습니다.

이제 Visual Studio도 최신 C++17을 지원한다는 점을 고려하면 최신 버전을 사용하지 않을 이유가 없습니다.

댓글을 달고 싶었습니다. 나는 auto_ptr을 사용하는 third_party 물건 중 하나라는 유일한 문제가 있는 C++17 플래그로 Godot를 컴파일할 수 있었습니다.

문제는 C++17에서 컴파일되지 않는다는 것이 아니라, 문제는 C++17 기능을 사용하려는 사람들, 또는 더 나쁜 것은 이러한 기능을 사용하여 PR을 시작하는 것입니다... 프로젝트가 c에 있다는 것을 발견하기 위해서만 ++03.

람다가 없다는 것은 여기서 볼 수 없는 거대한 문제입니다.
여러 번, Godot는 데이터의 임시 목록을 저장한 다음 이를 반복해야 합니다.
이러한 모든 경우에 "for_each" 또는 자체적으로 반복되는 유사한 구조로 수행할 수 있으며, 인라인/최적화되는 람다 덕분에 엄청난 양의 코드 단순화, 메모리 사용량 감소 및 성능 향상이 가능합니다. (그리고 이것은 모든 곳에서 사용되는 C++11입니다). 연결된 목록의 모든 일반 루프에 대해 정확히 똑같은 것입니다.

또한 이동 연산자는 더 나은 데이터 구조를 허용하여 현재의 절대적으로 좋지 않은 구조를 더 최적화된 일부로 대체할 수 있습니다.

문자열 데이터 유형(예: "mystring"_hs) 또는 이와 유사한 것은 해시된 문자열을 코드의 모든 곳에 퍼뜨리는 좋은 방법을 제공하여 문자열 검사(스크립트 및 이벤트 코드에서 매우 일반적임)를 훨씬 더 빠르게 만듭니다.

std::thread가 사용되지 않더라도(제 생각에는 상당히 끔찍한 추상화라고 생각합니다), std atomics 라이브러리는 놀랍고 매우 유용합니다. std::원자그리고 좋아하는 것.

그리고 사람들이 현대 라이브러리를 쉽게 통합할 수 없을 때 사람들에게 C++03을 강요하는 것이 프로젝트 자체에 얼마나 큰 타격을 주는지 이야기조차 하지 말자. 왜냐하면 Godot는 그런 오래된 버전의 C++에서 포기되지 않은 유일한 오픈 소스 C++ 프로젝트이기 때문입니다( 내가 아는 한)

개인적으로, 저는 보수적이고 절대적인 최신 C++ 표준을 따르지 않는다는 데 동의하지만, C++14의 일부 검증된 기능이 있는 C++11과 같은 것이 가장 잘 작동하고 Godot를 크게 개선할 것이라고 생각합니다. C++11-14는 ps4, xbox, 스위치, pc, 저가형 PC, Android, IOS 및 HTML5 웹 어셈블리로 포팅되는 Unreal Engine에 충분합니다. 나는 훨씬 적은 양의 플랫폼을 지원하는데 Godot가 스스로를 제한해야 하는 이유를 모르겠습니다.

문자열 데이터 유형(예: "mystring"_hs) 또는 이와 유사한 것은 해시된 문자열을 코드의 모든 곳에 퍼뜨리는 좋은 방법을 제공하여 문자열 검사(스크립트 및 이벤트 코드에서 매우 일반적임)를 훨씬 더 빠르게 만듭니다.

또한 스위치와 같은 용도로 사용할 수 있습니다. 몇 년 전에 플라이웨이트 문자열 구현을 대체하기 위해 Atom 유형을 만든 것처럼:
https://github.com/OvermindDL1/OverECS/blob/master/StringAtom.hpp

32비트(최대 5자 또는 테이블을 약간 다시 코딩하는 경우 6자)와 64비트 버전(긴밀한 인코딩 선택 여부에 따라 최대 10 또는 12자)이 있습니다. 완전히 되돌릴 수 있으며 컴파일 타임에 또는 런타임에 양방향으로 동적으로 발생하며 스위치 등에서 완전히 사용할 수 있습니다. 등... 해당 파일의 사용 예:

switch(blah) {
  case "UPDATE"_atom64: ... pass
  case "PHYSUPDATE"_atom64: ... pass
  ...
}

LUA 코드와 상호 작용할 때 방금 문자열을 사용하고 경계에서 변환을 수행했습니다. 그 파일은 "최신" 버전이 아닙니다. 정수에서 문자열로 돌아갈 때 메모리 할당 없이 변환을 수행하는 함수를 추가했습니다(컴파일 시간에 실행되기 때문에 문자열->정수에 관계없이 할당이 없음). . Atom64/Atom32/모든 유형을 표시할 때 인코딩을 반대로 하는 Visual Studio 또는 GDB 필터를 만드는 것은 간단합니다.

그러나 이와 같은 것들은 특히 성능에 민감한 코드에서 그리고 코드를 읽기 쉽게 만드는 데 매우 유용하며, 이것은 새로운 것이 아니라 C++11만 필요했습니다.

최소한 C++14가 Godot 표준이 되어야 한다고 말하고 싶습니다. C++17은 좋을 수 있지만(일부 새 코드에서 일부 매우 유용한 성능 향상), C++14는 현재 보편적인 최소 사양입니다. 그러나 물론 gcc/clang/VisualStudio 및 기타 모든 것이 이제 C++17을 잘 지원하므로(그리고 C++20의 큰 덩어리까지도) C++17도 좋아 보입니다. 나는 아마도 '경우에 따라'를 위해 C++14를 선택할 것입니다.

@OvermindDL1 그 Atom 물건은 굉장합니다. 좋아합니다. 그것은 확실히 그 정확한 일을 꽤 많이 하는 Godot와 정말 잘 맞을 것입니다.

그 Atom 물건은 굉장합니다. 사랑합니다. 그것은 확실히 그 정확한 일을 꽤 많이 하는 Godot와 정말 잘 맞을 것입니다.

@vblanco20-1 Godot가 원하면 코드를 자유롭게 흡수할 수 있습니다. 이전 C++ 엔진에서 오랫동안 사용되어 왔습니다. 작은 이벤트 태그, 사물의 '키'로 사용하는 짧은 문자열에 매우 유용했으며 Lua/LuaJit에서 앞뒤로 쉽게 이동할 수 있었고 디버거 필터가 큰 도움이 되었습니다.

람다가 없다는 것은 여기서 볼 수 없는 거대한 문제입니다.

람다가 대부분의 경우 코드를 읽기 어렵게 만든다고 생각하는 사람은 나뿐입니까?

@Faless : 아니요, 당신이 유일한 사람은 아닙니다. 나는 람다가 읽기 어려운 것이 Akien이 C++ 버전을 올리지 않은 이유 중 하나라고 생각합니다.

람다는 작은 인라인 함수일 뿐입니다. 나는 당신이 그들에 대해 "읽기 어렵다"고 말하는 것을 모릅니다. 그러나 그들은 비교 함수를 보내는 Sort 알고리즘이나 나머지 std 알고리즘 라이브러리와 같은 것을 허용합니다. 또한 임시 배열(octree 및 기타 시스템의 소스 코드에서 여러 번 발생)이 필요 없기 때문에 메모리를 절약하고 성능을 크게 향상시킬 수 있습니다.

그리고 std 알고리즘 라이브러리를 사용하면 병렬 for, 병렬 정렬 및 병렬 누적을 통해 얻을 수 있는 프로그램을 다중 스레드하는 가장 쉬운 방법입니다.

사람들이 코드 품질, 성능 및 재사용성을 크게 향상시킬 수 있을 때 이를 "이상하다"고 쓰는 것은 절대적으로 수치스러운 일입니다.

내가 이미 구현한 실제 예:

//old linked list iteration
while (scenario->instances.first()) {
            instance_set_scenario(scenario->instances.first()->self()->self, RID());
        }
//new (just abstracts above)
scenario->instances.for_each([]( RID& item  ){
    instance_set_scenario(item, RID());
});

또 이런 경우가 너무 많이 반복되어

//old. Note the 1024 array, wich is hard size, and is wasting memory

int culled = 0;
Instance *cull[1024];
culled = scenario->octree.cull_aabb(p_aabb, cull, 1024);
for (int i = 0; i < culled; i++) {

    Instance *instance = cull[i];
    ERR_CONTINUE(!instance);
    if (instance->object_ID == 0)
        continue;

    instances.push_back(instance->object_ID);
}

//NEW. not implemented yet. 0 memory usage, can be inlined, and doesnt have a maximum size. 
//Its also shorter and will be faster in absolutely every case compared to old version.

scenario->octree.for_each_inside_aabb(p_aabb, [](Instance* instance){       
    ERR_CONTINUE(!instance);
    if (instance->object_ID == 0)
        continue;
    instances.push_back(instance->object_ID);
});

내가 이미 구현한 실제 예:

여기에서 얻는 이득이 무엇인지 확실하지 않습니다 ...

사람들이 코드 품질, 성능 및 재사용성을 크게 향상시킬 수 있을 때 이를 "이상하다"고 쓰는 것은 절대적으로 수치스러운 일입니다.

@vblanco20-1 글쎄, 나는 나 자신을 설명하려고 노력할 것이다.
사람들은 일반적으로 다음과 같이 작성합니다.

my_arr.push(
    [par1, par2, par3]{
      somefunc(par1, par2, par3);
    }
);

그런 다음 다른 장소에서:

func = my_arr.front();
func();

읽을 때 어떤 기능이 실행되는지, 무엇을 찾아야 하는지에 대한 단서가 없습니다. 동일한 파일에 있으면 괜찮을 수 있지만 해당 배열을 여러 파일에 전달하면 전체 코드를 읽을 수 없게 됩니다.

@Falless 귀하의 예는 람다로 할 수 있는 최악의 예입니다(그런 종류의 사용은 확실히 금지되어야 합니다).

"시간에 따라" 람다를 사용하는 것은 할당해야 하기 때문에 좋은 사용이 아니며 캡처된 변수가 람다를 실행할 때까지 유효하지 않을 수 있기 때문에 큰 위험이 됩니다(예: 포인터를 누른 다음 람다를 호출하기 전에 개체를 삭제하면 캡처된 포인터가 매달려 있습니다). 저는 람다를 "즉시" 사용하는 데이터 구조 및 알고리즘과 함께 사용하기 위해 람다를 방어하는 것뿐입니다.

for_each 예에서 for_each는 내부 데이터 구조의 변경에 영향을 받지 않으며(예: 변수를 약간 재정렬하는 경우) 더 많은 "불투명한" 데이터 구조를 허용합니다(이를 통해 개발자는 " 어떤 것이 더 잘 작동하는지 테스트하기 위해 한 데이터 구조에서 다른 데이터 구조로 변경합니다. 이를 수용함으로써 "사용" 계층을 사용하기 쉽게 유지하면서 불투명하게 작동하는 훨씬 더 복잡한 데이터 구조를 구현할 수 있습니다.

또한 상용구를 줄이고 코드가 실제로 수행하는 작업(연결 목록 반복)을 보다 "명확하게" 만듭니다. " first()->self()->self "를 제거하는 것 자체가 개선입니다.

메모리에 있는 순서대로 노드를 반복하는 "unordered_for_each"와 같은 것을 가질 수 있으므로 이것의 이점은 실제로 더 많이 사용할수록 누적된다는 점을 명심하십시오(할당자를 통해 또는 연결 목록이 맨 위에 저장된 경우 배열) 또는 "reverse_for_each". "찾기" 또는 "정렬"과 같은 것조차도. (최소한 C++20 범위가 병합될 때까지는 std::algorithms를 그다지 권장하지 않습니다. 데이터 구조의 일부로 자체 알고리즘을 구현하는 것이 사용하는 것이 훨씬 좋습니다)

Lambda는 기본적으로 Epic Games가 Sort, Partition, Filter, RemoveAll, Find 등과 같은 자체 알고리즘 라이브러리와 함께 C++11에서 언리얼 엔진으로 허용한 첫 번째 것이었습니다. 그 이후로 둘 다 소스 코드에서 꽤 자주 사용되었습니다. 엔진 코드 및 게임 플레이 코드에서

쿨, 적어도 우리는 람바가 성배가 아니라는 데 동의합니다.
우리는 이미 그것을 사용하지 않는 방법에 대한 하나의 규칙을 정의했습니다.

공연에 대해 더 연구하겠습니다.

2018년 12월 8일 토요일 17:06 vblanco20-1 < 알림 @github.com 작성:

@Faless https://github.com/Faless 귀하의 예는
람다로 할 수 있는 최악의 경우(그리고 그런 종류의 사용법은 확실히
금지).

"시간에 따라" 람다를 사용하는 것은 좋은 사용이 아닙니다.
할당하고 캡처된 변수로 큰 위험이 됩니다.
람다를 실행할 때까지 유효하지 않게 됩니다(예:
포인터를 캡처한 다음 람다를 호출하기 전에 개체를 삭제합니다.
캡처된 포인터가 매달려 있음). 나는 단지 람다를 옹호할 뿐이다.
데이터 구조 및 알고리즘과 함께 사용, 사용 위치
"곧".

for_each 예에서 for_each는 내부의 변경 사항에 영향을 받지 않습니다.
데이터 구조(예: 변수를 약간 재정렬하는 경우),
더 많은 "불투명한" 데이터 구조(개발자가
어떤 데이터 구조를 테스트하기 위해 한 데이터 구조에서 다른 데이터 구조로 "쉽게" 변경
더 잘 작동할 수 있습니다. 이를 수용하면 훨씬 더 많은 것을 구현할 수 있습니다.
"사용"을 유지하면서 불투명하게 작동하는 복잡한 데이터 구조
사용하기 쉬운 레이어.

또한 상용구를 줄이고 코드가 무엇인지 더 "명확하게" 만듭니다.
실제로 수행(연결 목록 반복). "를 없애기만 하면
first()->self()->self "는 자체적으로 개선된 것입니다.

이것의 이점은 실제로 더 많이 사용할수록 누적된다는 점을 명심하십시오.
반복되는 "unordered_for_each"와 같은 것을 가질 수 있습니다.
메모리에 있는 순서대로 노드를 할당합니다(할당자를 통해 또는
연결 목록은 배열의 맨 위에 저장됨) 또는 "reverse_for_each"입니다. 심지어 물건
"찾기" 또는 "정렬"처럼. (나는 std::algorithms를 그다지 추천하지 않는다.
Ranges가 병합될 때 C++20까지는 최소한. 자신의 알고리즘 구현
데이터 구조의 일부로 사용하는 것이 훨씬 좋습니다)

Lambda는 기본적으로 Epic Games가 C++11에서 처음으로 허용한 것입니다.
Sort와 같은 자체 알고리즘 라이브러리와 함께 언리얼 엔진,
Partition, Filter, RemoveAll, Find 등 그 이후로는 꽤 자주 사용됩니다.
엔진 코드와 게임 플레이 코드 모두에서 소스 코드에 사용

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/9694#issuecomment-445474001 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABnBbvBTxThAh0v8AfFCdGsSv2HFnEz6ks5u2_GKgaJpZM4ObOio
.

코드베이스의 유지 관리성을 향상시키는 C++11 기능:

• override 및 final
• 범위 기반 for 루프
• nullptr
• 강력한 형식의 열거형
• explicit 키워드

삶의 질을 향상시키는 C++11 기능:

• 오른쪽 꺾쇠 괄호( Vector<Vector> > 없음)

[[nodiscard]] (C++17 ?) 여기를 참조 하십시오

새로운 것을 사용하거나 사용할 수 있는 기능이 1~2개 있다고 해서 최신 버전을 채택해야 하는 것은 아니라고 생각합니다. 이점이 가치가 없기 때문에 C++11 이외의 것을 사용하는 것을 제안하지 않습니다.
C++이 발전함에 따라 stl은 점점 더 커지고 전처리기 단계에서 프로젝트에 수백 줄이 추가됩니다. 대부분의 경우 성능에 상당한 영향을 미칩니다.

대부분의 경우 성능에 상당한 영향을 미칩니다.

절대 안됩니다? 실행되지 않는 코드는 컴파일러 버그가 없는 한 성능에 영향을 미치지 않아야 하며 릴리스에서는 최종 바이너리에 전혀 포함되어서는 안 됩니다. 많은 경우에 적절한 이동 의미를 갖는 것만으로도 일부 영역에서는 성능이 크게 향상되며 이전 예에서는 업데이트된 지시문이 다른 기능 중에서 성능 향상을 가질 수도 있습니다.

@OvermindDL1 예, 이론상 그래야 합니다.
이것을 확인하십시오 : https://twitter.com/zeuxcg/status/1085781851568914432
나는 최근에 소셜 미디어에서 이와 같은 다양한 사례를 보았습니다. 그것은 "제로 비용 추상화"가 되어야 하는 것처럼 아닙니다.

@lupoDharkael 그 트위터 스레드(마침내 로드되고 나면 거룩한 와우 트위터는 끔찍한 인터페이스입니다... 저는 그것을 계속 잊고 있습니다...) libstdc++의 math.h가 C++17 모드에서 더 크기 때문에 컴파일 시간 속도에 대해서만 이야기합니다(여기서 libc++에는 해당 문제가 없음) 더 나은 런타임 속도를 위한 더 많은 오버로드 및 기능으로 인해 Math.h를 가져오는 모든 컴파일은 최신 stdlib 대신 특정 이전 stdlib를 사용하는 경우 컴파일 시간이 약 300ms 증가합니다. 그것은 런타임 성능에 대해 아무 것도 언급하지 않습니다(사용된 기능에 따라 더 높은 C++ 모드에서만 더 빠른 것을 보았고 최악의 경우 동일한 속도). It's not as "zero cost abstractions" as it should. 에 관해서는 아직 당신이 무엇을 언급하고 있는지 잘 모르겠습니까? 이전 stdlib에서 math.h로 컴파일할 때 컴파일 시간이 약 300ms 증가하기 때문에 링크한 스레드가 그와 아무 관련이 없는 것처럼 보이므로 런타임 성능 문제에 대한 실제 보고서에 대한 링크가 있습니까? 어쨌든 컴파일된 개체의 컴파일 시간이 300ms 증가하는 문제가 있는지 확실하지 않습니까?

그것에 대해 더 조사하겠습니다.
비용에 이유가 있다는 것을 이해하지만 컴파일 시간이 길어지는 것은 실제로 저에게 반기능입니다. 나는 랩탑만 가지고 있고 엔진에 대한 기능 작업에는 시간이 걸립니다. 모든 변경 후에 컴파일+링크 프로세스를 기다려야 하는 시간이 있기 때문입니다. 새로운 버전을 사용하기 위해 정당한 이점 없이 더 많이 늘리는 것은 좋은 생각이 아닙니다.

나는 랩탑만 가지고 있고 엔진에 대한 기능 작업에는 시간이 걸립니다. 모든 변경 후에 컴파일+링크 프로세스를 기다려야 하는 시간이 있기 때문입니다.

ccache가 설치되어 있으면 증분 빌드 프로세스에서 링크에 많은 시간이 소요됩니다. 링크에 ld gold 를 사용하여 1초 정도 시간을 단축할 수 있으며 lld 로 전환하여 더 최적화할 수 있습니다.

오 확실히, 백업 빌더로서 ccache와 ninja 모두에 대해 충분히 좋다고 말할 수는 없습니다(예를 들어 cmake를 사용하는 경우). 둘 다 시간 을 많이 절약합니다!

게다가 Unity 빌드는 놀라울 정도로 놀랍습니다. 여기에서 프로젝트의 모든 cpp 파일을 포함하는 새 unity.cpp 정도의 파일을 만들 수 있지만 실제로는 일반적으로 '모듈'당 unity cpp 파일이 있습니다. 따라서 컴파일 시간에 추가 메모리를 사용하는 대신 훨씬 빠르게 컴파일하고 링크할 수 있습니다. 증분 재구축에는 덜 유용하고 릴리스 빌드에는 더 유용합니다.

더미에 하나를 추가하려면:
static_assert

예를 들어 SpatialMaterial::MaterialKey 합집합은 구조체의 크기가 uint64_t와 같다고 가정하지만 내가 말할 수 있는 한 어디에서도 주장되지 않습니다.

거기에 static_assert(sizeof(MaterialKey) == sizeof(uint64_t)) 를 치고 싶었지만 할 수 없었습니다.

다른 하나는 수동 상용구를 너무 많이 작성하지 않고 불필요한 참조 계산을 사용하지 않고 파괴 시 적절한 정리를 보장하기 위해 unique_ptr을 사용하는 것입니다.

Godot와 코드베이스를 처음 접하는 사람으로서 제 2센트(또는 20센트)를 제공하고 싶습니다. 저는 현재 _Battle for Wesnoth_를 Godot로 이식하는 작업을 감독하고 작업 중입니다. 이제 프론트 엔드(에디터와 GDScript API)가 훌륭합니다! 몇 가지 거친 부분 외에도 지금까지는 좋은 속도로 진행할 수 있었습니다. 그러나 우리(팀)도 언젠가는 백엔드(엔진)에 대한 패치를 제공할 것이라고 상상했습니다. 이를 위해 이번 주 초에 git repo를 복제하고 C++에서 여기저기 파고들기 시작했습니다. 솔직히 말해서... 저는 약간 실망했습니다.

저는 Wesnoth의 오래된 사용자 정의 엔진의 형태로 대규모 C++ 코드베이스를 관리한 경험이 있습니다. 역시 C++03으로 시작했지만 C++11 이상 기능을 사용하도록 현대화되었으며 이제 C++14와 호환됩니다. 나는 그 현대화 노력을 주도했고(종종 너무 열성적으로) 우리 코드베이스를 훨씬 더 읽기 쉽고 작업하기 쉽게 만들었다고 생각합니다. 물론 저는 순수한 C++03 코드베이스로 광범위하게 작업한 적이 없습니다. 최신 C++ 기능을 사용하여 C++를 배웠습니다. 하지만 auto , range-for 및 lambdas와 같은 것들이 코드를 덜 읽기 쉽게 만든다는 생각은 정말... 매우 이상합니다.

auto 를 남용하고 남용하는 것이 확실히 가능하지만 합법적인 용도도 많이 있습니다. Wesnoth 코드베이스를 업데이트할 때 auto 를 배포한 가장 일반적인 장소 중 하나는 반복자를 사용하는 for 루프였습니다. 이전에는 다음과 같은 항목이 있었습니다.

for(std::vector<T>::iterator foo = container.begin(); foo != container.end(); ++foo) {}

어느 것이 지저분해! 실제로 iterator가 필요한 경우에는 다음과 같이 했습니다.

for(auto foo = container.begin(); foo != container.end(); ++foo) {}

예, 이제 명시적 반복기 유형을 모르지만 거의 알 필요 가 없습니다. 나는 컨테이너가 일부 파일을 선언하면 더 어려워진다는 게시물을 여기에서 읽었지만 실제로 현대 코드 편집기와 인텔리센스를 사용하면 그다지 문제가 되지 않습니다.

대부분의 경우 다음과 같이 range-for로 전환합니다.

for(const auto& foo : container) {}

타이핑도 훨씬 빠르고 간결합니다. 루프 내에서 반복자를 역참조하거나 인덱스를 추적하는 것에 대해 걱정할 필요가 없습니다. 그리고 당신이 전체 컨테이너를 반복하고 있다는 것이 매우 분명합니다. 반복자를 사용하면 코드에 익숙하지 않은 사람들은 루프가 처음부터 끝까지 실제로 진행되는지 다시 확인해야 합니다.

여기에서 range-for 루프에서 auto 를 사용하면 추가 이점이 있습니다. 컨테이너 유형을 변경하는 경우 업데이트를 기억해야 하는 항목이 하나 줄어듭니다! 나는 이러한 것들이 코드를 덜 읽거나 이해하기 어렵게 만든다는 Juan의 주장을 정말로 이해할 수 없습니다. 저에게는 정반대입니다.

그는 Godot의 상태 비디오에서 람다도 언급했습니다. 다시 말하지만, 그것들을 남용하는 것은 확실히 가능하지만 또한 엄청나게 유용한 도구이기도 합니다! 다음은 C++11을 사용하기 전에 Wesnoth의 코드베이스에서 본 일반적인 패러다임입니다.

struct sort_helper {
    operator()(const T& a, const T& B) {
        return a < b;
    }
}

void init() const {
    std::vector<T> foo;
    foo.push_back(T(1));
    foo.push_back(T(2));
    foo.push_back(T(3));

    std::sort(foo.begin(), foo.end(), sort_helper);
}

길고 지저분한 코드 팽창. 다음은 C++11에서 사용한 것입니다.

void init() const {
    std::vector<T> foo {
        T(1),
        T(2),
        T(3),
    };

    std::sort(foo.begin(), foo.end(), [](const T& a, const T& b) { return a < b; });
}

가장 일반적인 경우입니다! 그리고 예, T에 대해 operator< 를 구현할 수도 있고 std::sort 가 기본적으로 이를 사용한다는 것을 알고 있지만 제 요점을 보여줍니다. 다시 말하지만, 아마도 그것은 단지 현대적인 C++로 배우고 거의 독점적으로 작업한 것일 수 있지만, 적절한 경우 auto , range-for 및 lambdas와 같은 도구를 무시하는 것은 발을 헛디딜 수 있다고 생각합니다.

이것은 나를 다음 요점으로 이끕니다. 나는 Godot가 내부적으로 STL 유형 대신에 자체 사용자 정의 유형을 많이 사용한다는 것을 알아차렸습니다. auto 와 같은 코드 가독성에 대한 우려가 있는 경우 STL 유형보다 사용자 정의 코어 유형을 사용하는 것은 절대적으로 손해입니다! 며칠 전에 코드베이스를 검색하다가 다음과 같은 코드를 많이 발견했습니다.

container.push_back(T(args));

이것은 비효율적입니다. push_back (적어도 std::vector 측면에서) const 참조를 사용합니다. 따라서 이 연산자는 불필요한 복사본을 생성합니다. emplace_back 를 사용하도록 패치를 만들고 싶었지만 ... 전체 코드베이스가 사용자 정의 컨테이너 유형을 사용하고 있다는 것을 깨달았습니다 😐

Wesnoth의 설계에 대한 큰 문제 중 하나이자 새 엔진(이 경우 Godot)을 사용하기로 결정한 주요 요인 중 하나는 Wesnoth가 Not Invented Here 증후군을 크게 겪었다는 것입니다. Boost와 같은 라이브러리를 사용하는 동안 렌더링 파이프라인은 사용자 지정이었고 UI 툴킷은 사용자 지정되었으며 데이터/스크립팅 언어는 사용자 지정되었습니다.... 요점을 알 수 있습니다. Godot 포트에서 작업을 시작하기 전에 하드웨어 가속 렌더링을 구현하려고 시도했지만 실패했습니다(이 시점까지 우리는 CPU 기반 표면/스프라이트 렌더링을 사용했습니다. 2019년에는 X_X를 알고 있습니다). SDL의 Texture API에는 셰이더 지원이 없었고 셰이더 지원이 필요했습니다. 결국 나는 가능한 한 자체 렌더러를 구현하는 것이 프로젝트에 불필요한 유지 관리 부담을 줄 것이라고 결정했습니다. 우리는 이미 핵심 개발자가 거의 없었고, Godot와 같은 엔진에 우리가 사용할 수 있는 완벽하게 훌륭하고 잘 관리된 렌더러가 있을 때 OpenGL(또는 OGL을 삭제해야 하는 경우 Vulkan)을 작성할 수 있는 사람을 찾는 것은 불필요한 고통이었습니다. 대신에.

사내에서 모든 것을 구현하는 것이 나쁜 생각이 될 수 있는 좋은 예라고 생각하기 때문에 이 문제를 제기합니다. 예, 표준 라이브러리를 사용하지 않음으로써 바이너리 크기를 약간 줄일 수는 있지만 막대한 유지 관리 부담을 지게 됩니다. 이러한 push_back 호출을 emplace_back 로 변환하는 것은 코드를 더 깨끗하고 성능이 좋게 만들 수 있는 매우 낮은 결과입니다. 그러나 사용자 정의 vector 유형이 있기 때문에 내부 구성을 원하는 경우 누군가 수동으로 구현해야 합니다. 그리고 다른 모든 사용자 정의 유형에서도 마찬가지입니다!

더 큰 문제는 진입장벽이 높아진다는 점이다. C++ STL 유형을 기대하는 Godot 코드베이스를 살펴보았습니다. 이를 찾지 못한다는 것은 나 또는 다른 누군가가 이제 엔진이 제공하는 유형과 각 API와 함께 제공되는 유형을 정확히 알아야 한다는 것을 의미합니다. 내가 원하는 std::map ? 아니요, dictionary 를 사용해야 합니다. 그것은 단지 메인테이너의 삶을 힘들게 만들고 새로운 기여자들의 일을 복잡하게 만듭니다. 그리고 실제로, 한 가지처럼 보이지만 실제로는 다른 코드가... 읽을 수 없는 코드가 아닙니까?

약 1년 전 Wesnoth의 1.14 릴리스 및 Steam 출시를 마감하면서 저는 erase() 를 사용하는 것을 제외하고 기본적으로 std::list 인 사용자 정의 컨테이너 유형을 제거하기 위한 리팩토링 프로젝트에 착수했습니다. 반복자. 다음은 문제의 커밋 원칙 입니다. 제대로 하려면 그 후에 추가 작업이 필요했지만 결과는 훨씬 더 간단하고 이해하기 쉬우며 덜 불투명한 코드였습니다.

결론적으로, 매우 유용한 C++11 기능을 불법화하고 STL 유형보다 사용자 정의 유형을 고수하는 것은 장기적으로 Godot에 방해가 될 것이라고 생각합니다. 리팩토링하는 데 시간이 오래 걸린다는 것을 알고 있지만(저를 믿으세요, 저도 압니다), 현재 상황에서는 결국 catch-22로 끝날 것 같습니다. STL(라거 바이너리 크기 등) 사용의 단점을 피하려고 하면 새로운 C++ 표준에서 더 나은 성능과 깔끔한 ​​코드로 전환하는 것이 점점 더 어려워질 것입니다. 모든 사용자 정의 유형에서 내부 구성을 구현하는 것을 특별히 기대하는 사람은 아무도 없을 것입니다. 😬

여기에서 내 의견이 큰 의미가 없다는 것을 알고 있지만 C++03에서 최신 C++로 이동한 대규모 C++ 코드베이스로 작업한 사람의 관점에서 내 생각을 제공할 것이라고 생각했습니다. 많은 작업이지만 장기적으로 볼 때 그만한 가치가 있다고 생각합니다.

방대한 텍스트월을 용서하세요!

@Vultraz 전적으로 동의합니다.

저는 C++에 대한 (거의) 경험이 없지만 GDNative + C++로 작업한 후 귀하의 견해를 공유합니다.

불과 며칠 전 저는 레딧에 " Godot에 기여하는 것이 C++를 배우는 좋은 방법인가요? " 스레드에 게시했습니다:

나는 그것을 추천하지 않을 것입니다. GDNative 및 C++ 작업에 대한 내 경험에 따르면 휠을 최소한 여러 번 재창조합니다(사용자 지정 컬렉션 및 포인터). 이러한 사용자 정의 클래스는 문서화되지 않았습니다(최소한 GDNative C++ 바인딩/헤더 POV에서 - 내가 마지막으로 시도했을 때 컴파일되지 않은 데모 프로젝트로 이어지는 하나의 가이드를 제외하고 코드 [헤더, 바인딩] 또는 공식 문서에는 문서가 없음) 및 혼란스럽거나 직관적이지 않은 동작이 있습니다(예: Ref가 직관적으로 투명해야 하므로 래핑되는 클래스의 동작을 변경해서는 안 되지만 Ref에서 일부 엔진 클래스를 늦게 래핑하면 임의 충돌이 발생함).

나는 또한 새로운 C++ 기능을 사용하는 대신 IMO 가독성이 낮은 상용구를 선호하는 팬이 아닙니다. 저는 Haskell(및 해당 라이브러리), 간결함, 고급 사용자를 위한 언어 장애를 방지하기 위해 초보자에게 연연하지 않는 것을 좋아합니다.

이러한 결정/가치 때문에 내가 엔진에 기여할 수 있을지 의심스럽습니다. (엔진 개발자가 이러한 결정의 배경이 기여를 장려하기 위한 것이라고 밝혔기 때문에 재미있습니다. 제 경우에는 완전히 반대의 효과가 있었습니다.)

@Vultraz 잘 정리된 글, 잘 읽었습니다. 감사합니다. 그런 관점을 듣는 것이 좋다.

저는 구식 C++ 프로그래머이고 Godot 소스 코드를 이해하는 데 큰 문제가 없었습니다. 잘 구성되어 있고 제 취향에 많이 들어맞습니다. 코드 기반에 대한 기존 경험이 거의 없이 비교적 빠르게 이 엔진의 핵심에 VR 지원을 추가할 수 있었던 것은 이 엔진이 얼마나 읽기 쉽고 이해하기 쉬운지에 대한 증거라고 생각합니다. 어떤 면에서는 구식일 수도 있지만 특정 부품이 얼마나 잘 만들어졌는지에 계속해서 놀랐습니다. 예, 메모리 부족을 줄이고 성능을 높이기 위해 현대화가 필요한 부분이 있지만 전체적으로는 그것에 깊은 인상을 받았습니다.

사람들이 C++의 새로운 구문에 대해 이야기하는 것을 들을 때 종종 나는 그저 낡았다는 느낌을 받고 소란이 무엇인지 정말 궁금합니다. 하지만 좀 더 현대적인 C++를 배우고 Godot에 기여하기로 결정하면 바퀴를 다시 발명하는 것처럼 보이는 것이 이상하다는 것을 이해합니다. 하지만 적어도 나와 같은 사람들에게는 이러한 클래스가 구현되는 것을 보는 데 너무 익숙해서 대부분이 여기에서 구현된 방식에 깊은 인상을 받았습니다. :)

모든 것이 말했듯이 이 문제를 보는 다양한 방법이 있어 재미가 없습니다. 새로운 C++ 구문보다 앞선 Godot의 기원에서 핵심 개발자가 가장 편안하게 느끼는 것, Godot의 크로스 플랫폼 특성과 실행할 수 있는 장치(일부는 공개되지 않음)에 의해 부과된 제한에 이르기까지. 나는 이것에 옳고 그름이 있다고 생각하지 않습니다. 그것은 당신이 익숙하고 어디에서 왔는지, 그리고 Godot가 어떻게 작동하는지 배우는 추가 학습 곡선이 큰 코드를 리팩토링하는 이점보다 더 중요한지에 대한 질문입니다 베이스.

보셨는지 모르겠지만 Juan은 GDC에서 온라인에 게시된 강연을 했습니다: https://www.youtube.com/watch?v=C0szslgA8VY
마지막에 있는 Q&A에서 그는 이에 대한 의사 결정에 대해 약간 이야기합니다.
좋은 시계입니다.

일반 사용자인 GDNative에 대한 위의 반응과 관련하여 GDNative는 특정 요구를 충족하는 최근에 추가된 것으로 핵심 제품이 어떻게 구성되고 구축되는지를 나타내지 않습니다.
모듈을 빌드해 보세요(https://docs.godotengine.org/en/3.1/development/cpp/custom_modules_in_cpp.html). 예, GDNative가 해결하려고 시도하는 문제인 핵심 제품으로 변경 사항을 컴파일해야 합니다. 엔진이 실제로 어떻게 구성되어 있는지 훨씬 더 잘 이해할 수 있습니다. 위에서 포기한 많은 주장은 Godot 자체가 아니라 GDNative의 단점입니다.
저는 정적 모듈을 구축하는 것과 같은 방식으로 모듈을 구축할 수 있는 동적 모듈 솔루션을 원합니다. 언젠가는 가능할 수도 있지만 그때까지는 GDNative로 충분합니다.

@Vultraz @mnn 실제로 STL 컨테이너에 대한 요점을 알 수 있지만 순전히 일부 구현(대부분 MSVC)이 디버그 모드에서 끔찍 하게 느린 성능을 가지고 있기 때문입니다. 그러나 단순히 EA의 STL을 사용하면 좋을 수 있습니다(빠르고 휴대 가능함).

또한: 개인적으로 RAII 가 없다는 것이 가장 고통스러웠습니다. RAII가 C++11에 새로운 것이 아니기 때문에 코드 전체에서 불필요하게 수행되는 수동 정리의 양은 이상합니다.

일반 사용자인 GDNative에 대한 위의 반응과 관련하여 GDNative는 특정 요구를 충족하는 최근에 추가된 것으로 핵심 제품이 어떻게 구성되고 구축되는지를 나타내지 않습니다.

그것은 물론 사실이지만 GDNative는 "스크립트"를 생성하는 데 사용되기 때문에 엔진 자체보다 더 사용자 친화적이어서는 안 됩니다. 엔진?

이러한 결정/가치 때문에 내가 엔진에 기여할 수 있을지 의심스럽습니다. (엔진 개발자가 이러한 결정의 배경이 기여를 장려하기 위한 것이라고 밝혔기 때문에 재미있습니다. 제 경우에는 완전히 반대의 효과가 있었습니다.)

저는 C++ 멍청한 놈(C++에서 일주일에 2일 약 2개월)이므로 이 결정으로 이익을 얻는 대상 인구 통계학적 대상이 되어야 합니다. 나는 기본 기능이 부족한 Godot 컨테이너를 발견했습니다(너무 풍부하지 않은 stl과 비교하여). 컨테이너가 GDNative와 관련이 있다고 생각하지 않지만, 제가 착각할 수 있습니다. 나는 Godot 컨테이너를 사용하는 것이 항상 고통스럽기 때문에 최대한 피하고 있습니다. Ref의 일관되지 않고 예상치 못한 행동은 엔진의 책임이라고 생각했는데, 제 생각이 틀렸습니다.

내 프로그래밍 배경이 아마도 다소 이례적이라는 것을 깨달았습니다. JS/TS에서 전문적으로 일한 년, Scala에서 1년, Haskell에서 더 작은 취미 프로젝트(수천 줄, Haskell이 얼마나 간결한지를 고려하면 실제로 그렇게 작지는 않습니다) - 여러 번 코드를 작성합니다. C++에서는 Haskell에서 최소 5배는 더 짧고 읽기 쉽습니다.) 구식의 지나치게 장황한 기술을 사용하여 낙담하는 유일한 사람인지 궁금합니다.

@mnn , GDNative는 C 기반 모듈을 동적 라이브러리로 생성할 수 있도록 만들어졌으므로 전체 엔진을 다시 컴파일할 필요가 없습니다. 그 위에 C++, python, rust 등으로 전체 엔진을 컴파일할 필요가 없는 모듈을 작성할 수 있도록 여러 언어 바인딩이 생성되었습니다.

이것의 또 다른 목표는 개발자가 모듈 자체를 전달하고 안정적인 엔진 빌드와 함께 사용할 수 있는 모듈을 만들 수 있도록 하는 것이었습니다. 많은 모듈이 아직 유지 관리되지 않아 특정 버전의 엔진에 연결되어 없어졌습니다.

예, 컴파일 및 배포 관점에서 모듈을 만드는 것이 훨씬 쉽고 간단해졌습니다. 그러나 접근 방식 때문에 한계가 있습니다. 이러한 제한 사항 내에서 유지하면 GDNative에서 C++ 코드를 작성하는 것은 간단하게 유지될 수 있습니다. 왜냐하면 모듈을 빌드하는 대상이 간단하기 때문입니다.

이러한 한계에서 벗어나려고 노력하면 골치 아픈 일에 직면하게 됩니다. 내 현재 골칫거리는 OpenGL 로직을 구현하려고 하는 것과 관련이 있습니다. 이 로직은 모두 비주얼 서버 아키텍처 내부에 캡슐화되어 있고 내가 원하는 방식으로 GDNative 내부에서 실제로 사용할 수 없습니다. 그러나 그것은 GDNative로 결코 설계되지 않은 일을 하고 싶은 이유입니다.
설계된 용도로 사용하면 정말 멋진 일을 할 수 있습니다.

또한 GDNative는 더 높은 성능이 필요한 GDScript 코드를 재작성하기 위한 방법이라는 점에 유의하십시오. 결과적으로 GDScript가 액세스할 수 없는 엔진 내부의 어떤 것도 액세스할 수 없습니다(예: OpenGL).

최신 코루틴 지원, 즉 co_await()는 어떻습니까? procgen 관점에서 이것은 거대합니다.

코루틴 지원은 아직 확정되지 않은 C++20 표준의 일부입니다.

저는 현재 3D Spatial Editor를 위한 고급(소스 망치 편집기 생각) 브러시/csg 도구를 작성하고 있는데 자동을 허용하지 않는다는 이 이야기는 저에게 정말 혼란스럽습니다. 때로는 _auto를 사용하는 것조차 명시적일 수 있습니다_. 다음을 고려하세요:

저는 SpatialEditorViewportContainer 안에 있고 상위 계층의 세 항목인 SpatialEditor를 얻고 싶습니다(누군가가 뷰포트 컨테이너에서 SpatialEditor에 액세스하는 더 좋은 방법이 있다고 지적하기 전에 이 코드베이스를 보기 시작했다는 점을 고려하십시오. 어제)

auto sp = Object::cast_to<SpatialEditor>(get_parent()->get_parent()->get_parent());

보시다시피 동적 다운캐스트는 _이미 SP_ 유형을 명시적으로 나타냅니다. auto가 없으면 다음과 같은 중복 정크를 작성해야 합니다.

SpatialEditor sp = Object::cast_to<SpatialEditor>(get_parent()->get_parent()->get_parent());

신의 사랑을 위해 오토 사용을 허락해주세요!

C++ 표준을 사용할 주제: C++20 이상에서 제안된 리플렉션 및 메타 클래스 기능은 다음과 같은 매크로 혼란을 줄이는 데 정말 유용합니다.

GDCLASS(SpatialEditorViewportContainer, Container);

또한 이러한 제한으로 인해 기여하기로 한 결정이 정말 두 번째로 추측된다는 점을 강조하고 싶습니다. 2012년경, 나는 스스로 C++11을 배웠고 이 표준을 사용할 수 없다는 것은 뺨을 때리는 것과 같았습니다. C++11과 C++03은 완전히 다른 언어이며 C++가 배우기 어렵고 읽기 어렵고 쓰기 어렵다는 평판의 대부분은 C++03(또는 98)의 잘못입니다. 최소한 C++11 또는 14를 사용하지 않는 것은 유지보수 및 가독성에 _해로운_ 것입니다. 저는 C++11과 함께 자랐고 프로젝트 리더는 분명히 그렇지 않았습니다(그가 2007년에 Godot에서 작업하기 시작했을 때 저는 12살이었습니다). 그래서 저는 이것이 선호도와 아기 오리 증후군의 경우라고 생각합니다. 나는 C++11을 사용하지 않는 것이 현대 C++을 배우는데 시간을 들인 나 같은 사람들을 희생시키면서 구식(일명 끔찍한) C++에 익숙한 사람들을 위로하기 위한 것이라고 생각합니다.

시간이 지남에 따라 점점 더 많은 주니어 프로그래머가 현대 C++ 11 이상에서 성장하고 프로젝트가 람다가 없는 언어에 영원히 갇혀 있다는 사실을 알게 될 것입니다.

요컨대: C++11 또는 흉상!

분명히 말씀드리자면, 저는 STL의 사용을 옹호하지 않습니다. 자신의 컨테이너를 굴리는 것은 괜찮지만 람다 및 자동과 같은 기능을 거부하는 것은 무의미해 보입니다.

여기서 더 논의하는 것은 무의미하므로 지금은 반향실을 닫겠습니다. 우리는 이미 몇 달 전에 C++11 및/또는 일부 이후 버전의 기능을 사용할 계획에 대해 논의했습니다.

우리는 @hpvb 가 우리의 합의에 따라 그가 작성하고 있는 지침을 마무리할 시간을 갖기를 기다리고 있으며, 그런 다음 게시되면 해당 지침에 대해 더 논의할 수 있습니다. 그때까지는 이것은 건설적이지 않습니다.