Libelektra: 오류에 대한 코드 생성

개인적으로 저는 옵션 1을 선호합니다. 오류 코드는 매우 드물게 변경되어야 하므로 C 코드를 수동으로 작성하고 다른 언어를 동기화 상태로 유지하는 추가 노력을 무시할 수 있습니다. 또한 초기 노력은 자동 생성을 설정하는 것보다 적어야 합니다.

옵션 2가 아닌 이유는 무엇입니까?

콧수염 템플릿은 어떻게든 입력 데이터와 함께 제공되어야 합니다. 빌드 시 컴파일된 사용자 지정 실행 파일을 사용해야 합니다. 이 경우 우리는 C++ 코드에서 std::cout << ... 를 제거할 것이지만 다른 것은 별로 변경되지 않습니다. 다른 옵션은 기본 콧수염 실행 파일을 사용하는 것입니다. 이 실행 파일은 Ruby 스크립트이므로 Ruby를 설치해야 합니다.

또한 kdb gen 는 kdb 먼저 컴파일해야 하므로 재사용 할 수 없습니다. kdberrors.h 합니다.

옵션 3이 아닌 이유는 무엇입니까?

C 코드 생성은 CMake에서 작동할 수 있지만 더 복잡한 언어는 CMake를 사용하는 데 문제가 있을 수 있습니다.

어떤 형태의 코드 생성을 사용하기로 결정했다면 반드시 생성해야 하는 부분만 생성해야 합니다. 예를 들어 현재 kdberrors.h 에는 완전히 정적이며 실제로 어떤 오류가 있는지와 무관한 많은 코드가 포함되어 있습니다. 이 코드는 생성되어서는 안 되며 정적 파일에서 #include 해야 합니다.

또한 안정적인 오류 코드 때문에 옵션 1을 선호합니다. 코드 생성을 추가하면 오류가 발생하기 쉬운 전체 코드에 불필요한 복잡성이 추가됩니다.

@kodebach 옵션 2에 대해 자세히

나는 우리가 옵션 1로 가는 것이 매우 분명하다고 생각합니다. @Piankero 당신이 결정을 써 주시겠습니까?

바인딩의 경우 크게 변경되지 않음을 의미합니다.

다음을 설명하는 바인딩 작성 튜토리얼이 있다면 얼마나 좋을까요?

1. Elektra 바인딩의 어떤 부분이 의미가 있는지(응용 프로그램, 플러그인, 도구 등)
2. CMake에 바인딩을 통합하는 방법(가능하고 유용한 경우)
3. 바인딩의 어떤 부분이 언어마다 다를 수 있고 달라야 하는지. 여기에는 다음이 포함됩니다.
   
   
   
   • 반복자
   
   
   • 기본 유형으로의 변환(문자열, int, ...)
   
   
   • 연산자 오버로딩(사용 가능한 경우)
   
   
   • 기타 프로그래밍 언어 통합(스트림, 해시 코드, ID 등)
   
   
   • kdb 함수에서 오류를 반환했습니다(여기서 이 문제의 내용).
   
   

다른 언어에서 볼 수 있는 다양한 상황에 대해 이 튜토리얼을 확장할 수 있기를 바랍니다. @Piankero 튜토리얼, 특히 오류 처리 섹션(상속을 구현하는 방법, ...) 작성을

튜토리얼: #2875
디자인 결정: #2872